0

I have two Tomcat 6 instances which both call EJBs on a remote JBoss 5 server.

With the same client code deployed on both Tomcats, I get a NullPointerException from the application server when one invokes an EJB method, while on the other it works fine.

Looking through the code with the debugger, it seems like the hash code of the method being invoked is different between the two calls, even though I assume it should be the same. Because the hash code is different, the remote method isn't being found in org.jboss.ejb3.service.ServiceContainer.

What could be leading to the hash code being different between the two invocations? For information, the working Tomcat is on the same machine as the JBoss server, while the failing Tomcat has to connect to JBoss across the network. Both Tomcats' connection configurations are the same.

The solution was the presence of jboss-aspect-jdk50-client_4.2.2.jar in Tomcat's lib directory - removing this file allowed the application to work correctly.

What I still don't understand is why this worked on the local Tomcat instance but not on the remote. I assume that either the classloading order was somehow different, or, more likely, the fact that communication was remote resulted in a different strategy being used.

I'm keeping the question open for a bit just in case someone can provide an explanation to this last bit.

Rich
  • 15,602
  • 15
  • 79
  • 126

1 Answers1

1

Pretty weird. Are all three servers definitely running with the same version of the code?

Tom Anderson
  • 46,189
  • 17
  • 92
  • 133
  • How are the Tomcats connecting to JBoss? Plain old RMI? Some kind of EJB3 client container in Tomcat? – Tom Anderson Jun 22 '11 at 11:25
  • Judging by the Jars that are present (I'm not responsible for the code, I'm just a last resort :)) it's using the JBoss 5 client libraries to connect to a jnp:// URL - the 4.2.2 jar is a stray. – Rich Jun 22 '11 at 12:29
  • For local EJB3s, JBoss uses Javassist to generate the necessary proxies. It's possible that it also does this for remote EJB3s (rather than using vanilla RMI stubs). JBossAOP also uses Javassist, so it's possible that the rogue jar is dragging in some inappropriate version of Javassist somehow, and that is producing proxies with duff method hashes. This is purely speculation, though. – Tom Anderson Jun 22 '11 at 13:04