Jboss Interoperability

todolist

My todolist is rather short. However it could not be longer.

I’ve been on this problem for days, so have several colleagues.

If anybody knows what is necessary to make a 4.0.2. jboss do successful rmi with a 4.2.0 jboss.

We keep getting a

ClassNotFoundException: org.jboss.ejb3.stateless.StatelessRemoteProxy

on doing the jndi lookup of our beautiful @RemoteHome interface. We’re of course missing the ejb3 client classes in the old jboss.

The wiki only states that we need to use the “legacy rmi invokers” to make the rmi work. But nobody ever explains anywhere how I make my application use those funky rmi invokers. It is probably so trivial, nobody could imagine, I would not know how to do it. Time and again we find people posting about a problem similar to ours and the thread ends with “oh it works now that I am using the legacy rmi invokers”. Thanks so much.

Update: for now it works in a weird way. We now have a proxy application. Basically the new structure now has three applications:

  • (A) the legacy app: a 2.x application deployed on a 4.0.2 server
  • (B) the proxy: a 2.x style application (no ejb3 annotations) deployed on a 4.2.0 server
  • (C) the new app: an ejb 3 application deployed on a 4.2.0 server

The calls now go like this (A) => (B) => (C). Why does it work? The proxy has no annotations typical for ejb3 whatsoever.  Therefore the ejb3 deployer ignores it and the “normal” deployer is triggered instead which leads to the ProxyFactory producing downward compatible rmi objects. The ejb3 proxy objects that are returned by (C) are in this way eliminated by routing calls from (A) through (B). This is not the most elegant solution and we’re still hoping to find something better. In the long run the server on which (A) runs will have to be upgraded anway which would also be a solution.

It also turned out that we indeed had managed to configure the application to use the legacy rmi invokers by deploying a deployment descriptor for our bean which referenced those invokers. We had just not managed to get to the point where this was relevant before. I’ll post the deployment descriptor tomorrow.