Issue integration Jboss with Spring DM

[sudheerk84]

We use Dm server 1.0.2 in our production server.

We earlier used Jboss 3.2.7 . When we copied jbossallclient.jar(by converting into bundle using bnd ) into the bundles/usr directory and tried using it in our application we got some isses as it was also exposing javax classes which internally is also exposed by bundles inside spring DM.

Hence we took only the required jars like

jbossmq,
jnpserver,
com.springsource.org.jboss.util-2.0.4.GA,
com.springsource.org.jboss.logging-.0.4.GA,
com.springsource.edu.oswego.cs.dl.util.concurrent-1.3.4

and copied them into bundles/usr and it worked fine.

Now we want to upgrade jboss into 4.2.2. What are the corresponding jars we need to take and convert into bundles ?

we tried taking latest version on jnpserver,jbossmq and copied into bundles/usr. But it doesnt work :-(

we get the folowing error . how do we fix these kind of issues . Has anyone tried SPring Dm with jboss ?

   
  javax.naming.CommunicationException: Could not obtain connection to any of these urls: 10.1.39.167:1200,10.1.39.167:1300 [Root exception is javax.naming.CommunicationException: Failed to retrieve stub from server 10.1.39.167:1300 [Root exception is java.io.StreamCorruptedException: unexpected block data]]

        at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1562)

        at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:634)

        at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)

        at javax.naming.InitialContext.lookup(InitialContext.java:392)

        at com.pg.jms.JMSMsgReceiver.reInitialize(JMSMsgReceiver.java:153)

       


       ........

        at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:1009)

        at java.security.AccessController.doPrivileged(Native Method)

        at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1003)

        at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:984)

        at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346)

        at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:265)

        at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:257)

        at com.springsource.server.kernel.core.internal.StandardBundleStarter.start(StandardBundleStarter.java:95)

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

        at java.lang.reflect.Method.invoke(Method.java:597)

        at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)

        at org.springframework.osgi.service.importer.support.internal.aop.ServiceInvoker.doInvoke(ServiceInvoker.java:58)

        at org.springframework.osgi.service.importer.support.internal.aop.ServiceInvoker.invoke(ServiceInvoker.java:62)

        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)

        at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)

        at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)

        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)

        at org.springframework.osgi.service.importer.support.LocalBundleContextAdvice.invoke(LocalBundleContextAdvice.java:59)

        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)

        at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)

        at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)

        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)

        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)

        at $Proxy104.start(Unknown Source)

        at com.springsource.server.deployer.core.module.StandardModule.startBundle(StandardModule.java:447)

        at com.springsource.server.deployer.core.module.StandardModule.deploy(StandardModule.java:303)

        at com.springsource.server.deployer.app.legacy.SingleBundleApplication.deploy(SingleBundleApplication.java:123)

        at com.springsource.server.deployer.core.internal.StandardApplicationDeployer.deploy(StandardApplicationDeployer.java:329)

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

        at java.lang.reflect.Method.invoke(Method.java:597)

        at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)

        at org.springframework.osgi.service.importer.support.internal.aop.ServiceInvoker.doInvoke(ServiceInvoker.java:58)

        at org.springframework.osgi.service.importer.support.internal.aop.ServiceInvoker.invoke(ServiceInvoker.java:62)

        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)

        at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)

        at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)

        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)

        at org.springframework.osgi.service.importer.support.LocalBundleContextAdvice.invoke(LocalBundleContextAdvice.java:59)

        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)

        at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)

        at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)

        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)

        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)

        at $Proxy74.deploy(Unknown Source)

        at com.springsource.server.deployer.hot.HotDeploymentFileSystemListener.deploy(HotDeploymentFileSystemListener.java:190)

        at com.springsource.server.deployer.hot.HotDeploymentFileSystemListener.deployIfNotDeployed(HotDeploymentFileSystemListener.java:201)

        at com.springsource.server.deployer.hot.HotDeploymentFileSystemListener.onChange(HotDeploymentFileSystemListener.java:97)

        at com.springsource.server.io.core.fs.WatchTask.notifyListeners(WatchTask.java:194)

        at com.springsource.server.io.core.fs.WatchTask.notifyInitialState(WatchTask.java:136)

        at com.springsource.server.io.core.fs.WatchTask.run(WatchTask.java:89)

        at java.lang.Thread.run(Thread.java:619)

Caused by: javax.naming.CommunicationException: Failed to retrieve stub from server 10.1.39.167:1300 [Root exception is java.io.StreamCorruptedException: unexpected block data]

        at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:268)

        at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1533)

        ... 68 more

Caused by: java.io.StreamCorruptedException: unexpected block data

        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1343)

        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)

        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)

        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)

        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)

        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)

        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)

        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)

        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)

        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)

        at java.rmi.MarshalledObject.get(MarshalledObject.java:142)

        at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:257)

        ... 69 more

[sudheerk84]

Figured out that the issue, it was because we were not copying the latest version of jboss-allclient jar.

Now we are converting the jboss-allclient.jar(version 4.2.1) into bundle using bundlor. It exports all its packages with version number 4.2.1, so that our application will get these classes.

Will it cause any issue with spring DM server ?

As i see Dm server internally has exports for javax , and also now our jboss-client will also have exports to javax classes.

Is spring Dm jars internally importing all these javax classes with strict version numbers ?

[Glyn Normington]

I doubt that dm Server's imports for any javax packages have a strict version range, but the system bundle and bundles that dm Server installs will have a lower bundle id than your application's bundles, so their exports of javax packages will be preferred when there is any ambiguity.

You should be careful to ensure that your javax imports are wiring to the correct exports and use a tight package version range on the import to get the wiring you need. If you need even tighter control, you can specify bundle symbolic name and/or bundle version range on the javax package imports too.

[sudheerk84]

As earlier mentioned i am using jboss-client.jar which also has javax classes.


we created this jboss-allclient bundle using bundlor with manifest showing exports for all classes with version 4.2.

Since we did not mention any version number for import in our application , we expect it to resolve to the latest version. BUt still we get issues :-(


But when i delete the javax classes inside jboss-client.jar and then convert it into bundle it wrks fine :-(

Still not able to figure out how to solve this

[Glyn Normington]

When a package import is resolved, exports from already resolved bundles are preferred over exports with a higher package version from unresolved bundles. This is OSGi semantics and may explain what you are observing.