7 Replies Latest reply on May 29, 2006 12:22 PM by menrique

    Interoperability version 4.0.2 -> 3.2.7

    jornik

      Is it possible to call an ejb that is running in a jboss server version 3.2.7 from a jboss server version 4.02? I thought it would be possible just by making the remote interface and the home interface available. It fails on a serialization id conflict on the GUID class.


      The post http://www.jboss.com/index.html?module=bb&op=viewtopic&t=67466 , indicates that there is a problem, but there is no workaround as it seems.

      Any ideas on how to solve this?


      / Jörgen

        • 1. Re: Interoperability version 4.0.2 -> 3.2.7
          jornik

          Here is part of the stacktrace...
          java.rmi.RemoteException: lookup of UserServer failed; nested exception is:
          javax.naming.CommunicationException [Root exception is java.io.InvalidClassException: org.jboss.util.id.GUID; local class incompatible: stream classdesc serialVersionUID = 6926421946503004889, local class serialVersionUID = 3289509836244263718]
          at com.user.server.impl.RetryingUserServer.updateUserServer(RetryingUserServer.java:145)

          • 2. Re: Interoperability version 4.0.2 -> 3.2.7
            rsood72

            I have a similar problem I was wondering if there is any solution to it.

            • 3. Re: Interoperability version 4.0.2 -> 3.2.7
              joshua_hj

              Well,


              I solved the problem by forcing my client app (in JBoss 4) to use the "org.jnp.interfaces.NamingContextFactory" class provided by one of the JBoss3.2.x jar files (jbossall-client.jar will do the trick).

              My app is packed inside a WAR archive, so i just paste the jbossall-client.jar inside WEB-INF/lib and solved the problem


              Hope this helps

              • 4. Re: Interoperability version 4.0.2 -> 3.2.7
                mike.chack

                The root cause of the issue is an incompatibilty of the following object between the various versions of JBOSS, org.jboss.util.id.GUID. This seems to be a big problem. In my case I can't just use the old jar as I also need to reference the local JNDI provider.

                It would be apprediated if someone from JBOSS could comment on this as it seems to be a fairly serious issue or limitation depending upon how one interprets it.

                Thanks

                • 5. Re: Interoperability version 4.0.2 -> 3.2.7
                  starksm64
                  • 6. Re: Interoperability version 4.0.2 -> 3.2.7
                    jornik

                    Well, by replacing the jbossall-client.jar I disable my lookup to my local ejbs, so that is not good enough.

                    I cannot get the JBAS-2718 suggestion to work. I have supplied the suggested switch to both my 4.0.2 server and to my 3.2.7 server without any luck. Any more comments?


                    I have talked to the jboss support "redpill" in sweden and they say that it wont be possible. They say it will work fron 3.2.8 and on. Though I have not been able to test this yet.

                    • 7. Re: Interoperability version 4.0.2 -> 3.2.7
                      menrique

                       

                      "jornik" wrote:
                      Well, by replacing the jbossall-client.jar I disable my lookup to my local ejbs, so that is not good enough.

                      I cannot get the JBAS-2718 suggestion to work. I have supplied the suggested switch to both my 4.0.2 server and to my 3.2.7 server without any luck. Any more comments?


                      I have talked to the jboss support "redpill" in sweden and they say that it wont be possible. They say it will work fron 3.2.8 and on. Though I have not been able to test this yet.


                      I'm using JBoss 3.2.3 and I get the same error when upgrade to 4.0.2/4.0.4 . If I couldn't update both JBoss version because the other is on a partner company server ... how can I solve my problem?

                      Someone suggested to migrate to a webservice client. It's the unique solution??? because is neither possible in my case :(