The South East Asia SOA Weblog

I had searched high and low for a solution to this. Seems like all the solution examples on Geronimo’s web site were using annotations and everything else I looked at seemed to draw a complete blank. Never being one to give up that easily I decided to hack my way through it. The first trick to be aware of is that like all the other services in Geronimo, the OpenEJB services are installed into the server by means of a resource adapter GBean. This doesn’t matter that much other than that you need to consider this when searching for a solution. So the first thing I did was set up an initial context in my EJB client code (the scenario is Session EJB calls another session EJB using local interface). The following code fragment shows how to set up the initial context call:

Code:

Note that I use “org.openejb.client.LocalInitialContextFactory” as the JNDI context factory class.

The second interesting fact has to do with the way in which OpenEJB exposes JNDI resources. When an EJB is deployed with both local and remote interfaces in most containers the java:comp/env namespace is used to provide access to local interface EJB resources. In Geronimo 2.2 with OpenEJB this definitely does not work at all. What actually happens is that an additional EJB interface is exposed as a “Local” interface. For example if I had deployed an EJB with the following components:

1) FooSessionEJBLocal - local interface
2) FooSessionEJBRemote - remote interface
3) FooSessionEJBBean - the actual session bean

… then OpenEJB will expose FooSessionEJBBean (the remote bean) and another curiously named EJB FooSessionEJBBeanLocal (the local bean). Only the latter can be cast to the FooSessionEJBLocal interface so for example when performing a lookup your code should look like this:

Code:

Note that the lookup is for “FooSessionEJBBeanLocal” and not “FooSessionEJBLocal". Also note that if you try to bind the remote EJB (FooSessionEJBBean) you can do so but that transactional context of using local EJB will not be managed by JTA (this is important if your code is dependent on operations within the context of the current container transaction).

Truth be told I was amazed that nobody on any of the Geronimo mailing lists had figured this out or had posted a workable solution.