3 Replies Latest reply on Jun 5, 2012 4:11 AM by bosschaert

CXF-DOSGi 1.3 in JBoss 7.1.1?

dawid.loubser May 30, 2012 9:06 AM

I am having a very hard time getting CXF-DOSGi to work in JBoss 7.1.1. This is such a pity, as the service publishing model is quite simple and elegant.

Does anybody have any advice on deploying this?

I have tried both the single-bundle and multi-bundle distribution. The multi-bundle obviously does not work, because there are several duplicate OSGi deployments (such as org.osgi.enterprise-4.2.0.jar, etc). I suspect it would take several hours to hand-pick which of the 52 JARs in the DOSGi multi-bundle distribution to deploy - not really practical.

On the other hand, deployment of the single-bundle distribution fails outright with:

----

15:03:18,064 WARN [org.jboss.modules] (MSC service thread 1-4) Failed to define class org.springframework.osgi.extender.internal.support.NamespacePlugins in Module "deployment.cxf-dosgi-ri-singlebundle-distribution:1.3.1" from Service Module Loader: java.lang.LinkageError: Failed to link org/springframework/osgi/extender/internal/support/NamespacePlugins (Module "deployment.cxf-dosgi-ri-singlebundle-distribution:1.3.1" from Service Module Loader)

at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:396)

at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243)

at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73)

at org.jboss.modules.FilteredLocalLoader.loadClassLocal(FilteredLocalLoader.java:46)

at org.jboss.modules.Module.loadModuleClass(Module.java:517)

at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182)

at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)

at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)

at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)

at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)

at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)

at org.springframework.osgi.extender.internal.support.NamespaceManager.<init>(NamespaceManager.java:83) [NamespaceManager.class:]

at org.springframework.osgi.extender.internal.activator.ContextLoaderListener.start(ContextLoaderListener.java:357) [ContextLoaderListener.class:]

at org.apache.cxf.dosgi.singlebundle.AggregatedActivator.startEmbeddedActivators(AggregatedActivator.java:116) [AggregatedActivator.class:]

at org.apache.cxf.dosgi.singlebundle.AggregatedActivator.start(AggregatedActivator.java:47) [AggregatedActivator.class:]

at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:300)

at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:223)

at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:494)

at org.jboss.as.osgi.deployment.BundleStartTracker$1.processService(BundleStartTracker.java:144)

at org.jboss.as.osgi.deployment.BundleStartTracker$1.transition(BundleStartTracker.java:119)

at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1416)

at org.jboss.msc.service.ServiceControllerImpl.access$2700(ServiceControllerImpl.java:49)

at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:1954)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_26]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_26]

at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_26]

Caused by: java.lang.NoClassDefFoundError: org/xml/sax/EntityResolver

at java.lang.ClassLoader.defineClass1(Native Method) [classes.jar:1.6.0_26]

at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) [classes.jar:1.6.0_26]

at java.lang.ClassLoader.defineClass(ClassLoader.java:615) [classes.jar:1.6.0_26]

at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) [classes.jar:1.6.0_26]

at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:327)

at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:391)

... 25 more

Caused by: java.lang.ClassNotFoundException: org.xml.sax.EntityResolver from [Module "deployment.cxf-dosgi-ri-singlebundle-distribution:1.3.1" from Service Module Loader]

at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)

at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)

at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)

at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)

at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)

at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)

... 31 more

15:03:18,096 ERROR [stderr] (MSC service thread 1-4) java.lang.NoClassDefFoundError: org/springframework/osgi/extender/internal/support/NamespacePlugins

15:03:18,097 ERROR [stderr] (MSC service thread 1-4) at org.springframework.osgi.extender.internal.support.NamespaceManager.<init>(NamespaceManager.java:83)

15:03:18,097 ERROR [stderr] (MSC service thread 1-4) at org.springframework.osgi.extender.internal.activator.ContextLoaderListener.start(ContextLoaderListener.java:357)

15:03:18,098 ERROR [stderr] (MSC service thread 1-4) at org.apache.cxf.dosgi.singlebundle.AggregatedActivator.startEmbeddedActivators(AggregatedActivator.java:116)

15:03:18,099 ERROR [stderr] (MSC service thread 1-4) at org.apache.cxf.dosgi.singlebundle.AggregatedActivator.start(AggregatedActivator.java:47)

15:03:18,099 ERROR [stderr] (MSC service thread 1-4) at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:300)

15:03:18,100 ERROR [stderr] (MSC service thread 1-4) at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:223)

15:03:18,101 ERROR [stderr] (MSC service thread 1-4) at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:494)

15:03:18,102 ERROR [stderr] (MSC service thread 1-4) at org.jboss.as.osgi.deployment.BundleStartTracker$1.processService(BundleStartTracker.java:144)

15:03:18,102 ERROR [stderr] (MSC service thread 1-4) at org.jboss.as.osgi.deployment.BundleStartTracker$1.transition(BundleStartTracker.java:119)

15:03:18,103 ERROR [stderr] (MSC service thread 1-4) at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1416)

15:03:18,103 ERROR [stderr] (MSC service thread 1-4) at org.jboss.msc.service.ServiceControllerImpl.access$2700(ServiceControllerImpl.java:49)

15:03:18,104 ERROR [stderr] (MSC service thread 1-4) at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:1954)

15:03:18,104 ERROR [stderr] (MSC service thread 1-4) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

15:03:18,105 ERROR [stderr] (MSC service thread 1-4) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

15:03:18,105 ERROR [stderr] (MSC service thread 1-4) at java.lang.Thread.run(Thread.java:680)

15:03:18,106 ERROR [stderr] (MSC service thread 1-4) Caused by: java.lang.ClassNotFoundException: org.springframework.osgi.extender.internal.support.NamespacePlugins from [Module "deployment.cxf-dosgi-ri-singlebundle-distribution:1.3.1" from Service Module Loader]

15:03:18,107 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)

15:03:18,107 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)

15:03:18,108 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)

15:03:18,109 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)

15:03:18,109 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)

15:03:18,110 ERROR [stderr] (MSC service thread 1-4) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)

15:03:18,110 ERROR [stderr] (MSC service thread 1-4) ... 15 more

15:03:25,891 ERROR [org.jboss.as.osgi] (MSC service thread 1-4) JBAS011900: Cannot start bundle: cxf-dosgi-ri-singlebundle-distribution:1.3.1: org.osgi.framework.BundleException: Cannot start bundle: cxf-dosgi-ri-singlebundle-distribution:1.3.1

at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:328) [jbosgi-framework-core-1.1.8.Final.jar:1.1.8.Final]

at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:223) [jbosgi-framework-core-1.1.8.Final.jar:1.1.8.Final]

at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:494) [jbosgi-framework-core-1.1.8.Final.jar:1.1.8.Final]

at org.jboss.as.osgi.deployment.BundleStartTracker$1.processService(BundleStartTracker.java:144) [jboss-as-osgi-service-7.1.1.Final.jar:7.1.1.Final]

at org.jboss.as.osgi.deployment.BundleStartTracker$1.transition(BundleStartTracker.java:119) [jboss-as-osgi-service-7.1.1.Final.jar:7.1.1.Final]

at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1416) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

at org.jboss.msc.service.ServiceControllerImpl.access$2700(ServiceControllerImpl.java:49) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:1954) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_26]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_26]

at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_26]

Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.apache.cxf.dosgi.dsw.Activator

at org.apache.cxf.dosgi.singlebundle.DSWActivator.createActivator(DSWActivator.java:45)

at org.apache.cxf.dosgi.singlebundle.DSWActivator.start(DSWActivator.java:34)

at org.apache.cxf.dosgi.singlebundle.AggregatedActivator.startEmbeddedActivators(AggregatedActivator.java:128)

at org.apache.cxf.dosgi.singlebundle.AggregatedActivator.start(AggregatedActivator.java:47)

at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:300) [jbosgi-framework-core-1.1.8.Final.jar:1.1.8.Final]

... 10 more

1. Re: CXF-DOSGi 1.3 in JBoss 7.1.1?

bosschaert May 30, 2012 11:00 AM (in response to dawid.loubser)

Hi Dawid,

I described how to do this with DOSGi 1.2 and AS 7.1. Obviously both have released newer versions in the mean time but this article might help: https://community.jboss.org/thread/174136
Actions
2. Re: CXF-DOSGi 1.3 in JBoss 7.1.1?

dawid.loubser Jun 4, 2012 4:14 AM (in response to bosschaert)

Thank you David - I have seen your post before. I tried (and failed) to get it working last year on JBoss 7.0.x, but I will try with 7.1 this time again when I have a bit of time.

It's unfortunate that it's so massively complicated and fiddly to get this working - it kind of goes against the whole promise of OSGi, no?
One has to literally "hack" JBoss 7.1 to get it working it seems (carefully crafting a module startup order with start levels and such).
What is the inherent cause for the complexity - is it the DOSGi project's fault? It would be a great idea for JBoss to perhaps built their own distributed OSGi implementation, if that is the case.

It's a bit sad that there is no clean and simple way to use JPA or to expose/consume web services in JBoss OSGi at the present - these are the basic building blocks of almost any modern system. We have built a rather large travel integration solution running in JBoss 7 OSGi (early adopters last year), and it's been great moving from JBI to OSGi, but we had to build so much of the services infrastructure ourselves, and will be looking at moving away from JBoss OSGi in the medium term if the situation does not improve with regards to these basic support technologies.

Of course, we had even worse luck with Glassfish! (which we try from time to time)

kind regards,
Dawid
Actions
3. Re: CXF-DOSGi 1.3 in JBoss 7.1.1?

bosschaert Jun 5, 2012 4:11 AM (in response to dawid.loubser)

Dawid Loubser wrote:

It's unfortunate that it's so massively complicated and fiddly to get this working - it kind of goes against the whole promise of OSGi, no?
One has to literally "hack" JBoss 7.1 to get it working it seems (carefully crafting a module startup order with start levels and such).
What is the inherent cause for the complexity - is it the DOSGi project's fault? It would be a great idea for JBoss to perhaps built their own distributed OSGi implementation, if that is the case.

The reason why its a bit fiddly is because some of the bundles that are part of CXF-DOSGi have some ordering requirements. This relates to some dependencies of CXF/DOSGi that weren't written as OSGi bundles but merely wrapped jarfiles (e.g. the JAXB bundles). These bundles only work when started in a particular order. A well-written OSGi bundle wouldn't have such an ordering dependency. Since you strongly feel that it needs to be fixed, I think it would be good to file a bug for this in the CXF-DOSGi bugtracker http://issues.apache.org/jira/browse/DOSGI if you have a moment. Building a separate OSGi Remote Services implementation in JBoss is currently not on the roadmap...

It's a bit sad that there is no clean and simple way to use JPA or to expose/consume web services in JBoss OSGi at the present - these are the basic building blocks of almost any modern system. We have built a rather large travel integration solution running in JBoss 7 OSGi (early adopters last year), and it's been great moving from JBI to OSGi, but we had to build so much of the services infrastructure ourselves, and will be looking at moving away from JBoss OSGi in the medium term if the situation does not improve with regards to these basic support technologies.

Yes, I agree it would be nice to would be nice to have Hibernate-based JPA support in JBoss OSGi. Currently this is tracked with bug https://issues.jboss.org/browse/JBOSGI-260. However AFAIK people have been successful with deploying the Aries OSGi/JPA implementation on JBoss OSGi. It might also be worth looking at EclipseLink, if its implemented without proprietary dependencies on Equinox it should work in JBoss OSGi as wel..
Actions

Go to original post