JBossMessagingEJB3ClientInvalidClassException

This page is out of date and no longer relevant

 

A client application which sends messages to a JBossMessaging destination and also makes calls to an EJB3 bean, both deployed in AS 4.0.x, will encounter the following exception:

 

javax.naming.CommunicationException RootExceptionIsJava.io.InvalidClassExceptionOrg.jboss.remoting.InvokerLocatorLocalClassIncompatibleStreamClassdescSerialVersionUID2909329895029296248LocalClassSerialVersionUID4977622166779282521   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:723)   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:588)   at javax.naming.InitialContext.lookup(InitialContext.java:351)   at org.jboss.example.jms.ejb3mdb.Sender.example(Sender.java:59)   at org.jboss.example.jms.common.ExampleSupport.run(ExampleSupport.java:137)   at org.jboss.example.jms.ejb3mdb.Sender.main(Sender.java:135) Caused by: java.io.InvalidClassException: org.jboss.remoting.InvokerLocator; local class incompatible: stream classdesc serialVersionUID = -2909329895029296248, local class serialVersionUID = -4977622166779282521   at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:546)   at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552) ...

 

In 4.0.x, EJB3 uses JBossRemoting 1.x whereas JBossMessaging uses 2.x. Such client, which interacts with a messaging destination and an EJB3 bean, needs the remoting client libraries. So, if you load the remoting library located in messaging, calling an EJB3 bean will fail with the exception above. If you load the EJB3 remoting version, located in client/jboss-remoting.jar or client/jbossall-client.jar, and try sending a message to a messaging destination, this will fail with a similar error.

 

There are several ways to get around this issue:

  • If your client application is running withing another AS, you could use scoped deployment so that different parts of your client are loaded with the corresponding remoting libraries.

  • If your client application is running in a standalone application, scoping classes would be more complicated and therefore, we'd recommend that you separate your application in two, so that each contains different libraries in their classpaths.

  • The previous two answers involve separating your application that users might not want/be able to do. Instead, users could re-architect their application using a delegation pattern. Instead of having the client interacting both with the messaging destination and the EJB3 bean, users could just interact with one of them, for example, the EJB3 bean and from within, send the corresponding messsage to the messaging destination. This would limit the client to only neededing EJB3's remoting library.

  • Use the forthcoming JBoss AS 4.2, for which candidate releases are available, where the remoting version for web services and EJB3 has been upgraded to 2.x, avoiding the issue mentioned above. You can install JBossMessaging in 4.2 in the same way as you installed it for 4.0.5.GA.

 

 

Referenced by: