Dear all,
I am having currently some trouble with running talend ESB in an offline mode when using the cxf-wsn and cxf-wsn-api features.
BACKGROUND: Since I am developing an application which is going to be deployed within a restricted, corporate network, I am not able to download resources dynamically, on demand from the network. Therefore I was hoping, that I can run talend ESB also in a complete offline mode.
The following describes the test setup, that I prepared:
(1) I've setup a single virtual machine based on Red Hat 4.1.2-52, which is the target platform where the application is going to be deployed.
(2) I opened the tar ball of the talend ESB.
(3) To simulate the closed network, I detached the virtual machine from the network and
(4) started the ESB.
(5) To test the offline installation now, I installed cxf-wsn and cxf-wsn-api features via the command line interface.
Unfortunately I received the following error message:
java.lang.RuntimeException: URL could not be resolved. at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:195) at java.net.URL.openStream(URL.java:1010) at org.apache.karaf.features.internal.FeaturesServiceImpl.installBundleIfNeeded(FeaturesServiceImpl.java:650) at org.apache.karaf.features.internal.FeaturesServiceImpl.doInstallFeature(FeaturesServiceImpl.java:478) at org.apache.karaf.features.internal.FeaturesServiceImpl.doInstallFeature(FeaturesServiceImpl.java:456) at org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:295) at org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:283) at org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:279) at org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:62) at org.apache.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:39) at org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38) at org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35) at org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78) at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:474) at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:400) at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108) at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183) at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120) at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89) at org.apache.karaf.shell.console.jline.Console.run(Console.java:221) at java.lang.Thread.run(Thread.java:662) at org.apache.karaf.shell.ssh.ShellFactoryImpl$ShellImpl$4.doRun(ShellFactoryImpl.java:142) at org.apache.karaf.shell.ssh.ShellFactoryImpl$ShellImpl$4$1.run(ShellFactoryImpl.java:133) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:337) at org.apache.karaf.shell.ssh.ShellFactoryImpl$ShellImpl$4.run(ShellFactoryImpl.java:131) 20:19:53,097 | ERROR | rint Extender: 2 | ntainer.BlueprintContainerImpl$1 293 | 9 - org.apache.aries.blueprint - 0.3.1 | Unable to start blueprint container for bundle sam-server due to unresolved dependencies java.util.concurrent.TimeoutException at org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:287) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662)
It seems that karaf can not resolve the maven coordinates. Than I started figuring out, why it might be that maven URI can not be resolved.
(1) Taking a look into
reviles that there is only the STS service bundled with the CXF component. This seems to be confusing to me, since the CXF sources contain in 2.5.2 also the WSN components as a service and I wonder why I could not find it
(2) On the other hand, when I look into
<TALEND_HOME>/lib/
I can find both libraries:
cxf-services-wsn-api-2.5.2.jar and
cxf-services-wsn-core-2.5.2.jar
Do I actually need to copy those files manually somewhere to make this working? Is there an alternative way to get this working by doing any configurations, e.g. karaf features.xml?
Many thanks and kind regards,
Christoph
Finally I made some progress on the installation topic. As I assumed initially the required libraries
cxf-services-wsn-api-2.5.2.jar
cxf-services-wsn-core-2.5.2.jar
must be copied over to the folder <TALEND_HOME>/container/system/ to be able starting the WSN service in a detached network. Please see below the folder structure for <TALEND_HOME>/container/system/org/apache/cxf/
Christoph,
you are right, in the 5.0.2 the corresponding wsn bundles are missing in the system repository. This is an issue, because our aim is to support operation of the container in off-line mode. The good news is in the upcomming 5.1.0 the required bundles are all included, the bad news is I still see the problem with the ws-addressing schema you described in the log file and wsn-core fails to start. I added a jira for this:
http://jira.talendforge.org/browse/TESB-5524. Later this day I will also file a CXF issue for this problem as like you wrote a local copy of the schema and a corresponding catalog entry is missing in the corresponding bundle.
Regards,
Zsolt
Hi Zsolt,
good news, that you are aware of this issue and thanks for opening the Jira 😉 I have just tried to poke a little around on this issue and did the following:
1) I was adding a new file called "jax-ws-catalog.xml" under the wsn-core feature of the CXF WSN service.
2) Added some redirecting information to the catalog file:
Where the class-path entry points to the wsn-api package containing the spec files.
3) Adjusted the wsn-code component pom.xml to import the wsn-api package
4) Ran a rebuild and tried to change the packages
Unfortunately without success. Some debugging of the startup behavior reviled that the catalog seems not to be resolved. I am still pointing to the "schema4.xsd" if I look into the base field of the OASISCatalogManagerHelper class that tries to resolve the URI at startup.
Did you managed to get any further with this topic?
Many thanks and kind regards,
Christoph
Just had a look into the wsdls and schemas provided with CXF WSN component. At first glance it is not obvious to me why the resolver tries get the ws-addressing scheme from the internet. It is included and referenced from the requiring schemas. Filed an isue for CXF (
https://issues.apache.org/jira/browse/CXF-4240), so someone from the CXF team can also have alook into.
