2 Replies Latest reply on Nov 20, 2004 1:31 PM by mlumsden1

Remote access to session beans using different JBoss 3.0.x v

kenwjennings Sep 19, 2002 2:02 PM

I have a session bean running in JBoss on one box that needs access to methods on a session bean running on JBoss in a remote box. The two beans have entirely different package structures, by the way.

I understand the way to do this is to create a new JNDI context for the remote box (with a different PROVIDER_URL, in other words) and do a lookup in that context. This works fine when the two containers in question are the same version of JBoss. However, when the local box runs JBoss 3.0.2 and the remote box runs JBoss 3.0.1, I get:
"java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: java.io.StreamCorruptedException." I assume this is due to inconsistent versions of the client jars between the two installations.

With JBoss 3 updates coming out as often as they do, and with my beans spread across multiple servers, the requirement to have the same version of JBoss installed globally becomes an upgrade nightmare. Is there a way to allow session beans sitting in one version of JBoss to access beans in a different version of the container?

Thanks,
Ken

1. Re: Remote access to session beans using different JBoss 3.0

juha Sep 23, 2002 7:34 AM (in response to kenwjennings)

no as far as I know
Actions
2. Re: Remote access to session beans using different JBoss 3.0

mlumsden1 Nov 20, 2004 1:31 PM (in response to kenwjennings)

I realize this is an old post but I am having similar difficulties getting a single client application working against two applications deployed on 2 different versions of JBOSS.

My client application has been built and depends on jbossall-client.jar. What I've found is the client app requires the JBoss specific version of jbossall-client.jar at run-time in order to operate properly with the specific JBoss version. Here is the matrix of combinations I've tried with jbossall-client.jar and the client app:

Case Build Runtime JBOSS Result
1 3.0.7 3.0.7 3.0.7 Works
2 3.0.7 3.2.6 3.0.7 Fails
3 3.0.7 3.0.7 3.2.6 Fails
4 3.0.7 3.2.6 3.2.6 Works

5 3.2.6 3.0.7 3.0.7 Works
6 3.2.6 3.2.6 3.0.7 Fails
7 3.2.6 3.0.7 3.2.6 Fails
8 3.2.6 3.2.6 3.2.6 Works

Now, I believe the jbossall-client.jar is responsible for providing implementations for:

-Djava.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
-Djava.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces

I was hoping Case 1 and 3 would work and I'd be good. However, I have not been successful. In general, the Exception encountered is one of the following and depends on which way I'm going:

1) Root cause: javax.naming.CommunicationException [Root exception is java.io.InvalidClassException: org.jboss.proxy.ejb.GenericEJBInterceptor; local class incompatible: stream classdesc serialVersionUID = 3844706474734439975, local class serialVersionUID = 4582256576523491346]

OR

2) Root cause: javax.naming.CommunicationException [Root exception is java.io.InvalidClassException: org.jboss.proxy.ejb.GenericEJBInterceptor; local class incompatible: stream classdesc serialVersionUID = 4582256576523491346, local class serialVersionUID = 3844706474734439975]

So, this boils down to the client application requiring the JBOSS specific version of the jbossall-client.jar in order to communicate to that specific version of JBOSS. Given this, it will be impossible for my application to work. This seems ludicrous.

I've got to believe I'm not the first developer who has needed to work with 2 different versions of the JBOSS server in a single client application.

Thanks in advance for any light that can shed on this matter.
Matt
Actions

Go to original post