GlassFish 3.1 to JBoss AS 7.1.1 EJB Invocation

This post demonstrates how to call a remote EJB deployed to JBoss AS 7.1.1 standalone server from an application deployed to GlassFish 3.1.x. It is similar to the standalone Java client connecting to JBoss AS 7.1.1, except that the remote client is running inside another application server product (GlassFish). The complete project is available in github: glassfish-calling-jboss.

The following is some steps and noteworthy points.

1, configure and start JBoss 7.1.1 standalone server (in a new terminal):

cd $JBOSS_HOME/bin
./standalone.sh
# in a new terminal/tab, or split it
# username: test
# password: 1234
./add-user.sh

2, configure and start GlassFish 3.1.x:

cd $$GLASSFISH_HOME/bin
./asadmin start-domain
./asadmin create-jvm-options -Dcom.sun.enterprise.naming.allowJndiLookupFromOSGi=false

cp $JBOSS_HOME/bin/client/jboss-client.jar $GLASSFISH_HOME/domains/domain1/lib/ext/
cp project-root/client-on-glassfish/src/main/resources/jboss-ejb-client.properties $GLASSFISH_HOME/domains/domain1/lib/classes/
./asadmin restart-domain

The com.sun.enterprise.naming.allowJndiLookupFromOSGi option is needed to disable the use of javax.naming.spi.InitialContextFactoryBuilder in GlassFish, which customizes its jndi bootstrapping. Since this configuration is jvm wide, we need to disable it to avoid any interference with JBoss jndi initialization inside GlassFish.

jboss-client.jar is copied to GlassFish domain lib/ext to provide the JBoss client-side ejb and naming funcionality. jboss-ejb-client.properties is also copied to GlassFish domain lib/classes dir so that it share the same classloader as jboss-client.jar.

jboss-ejb-client.properties inside the application should be sufficient. It is also copied in the above step to ensure it is always available to jboss client inside GlassFish. jboss-ejb-client.properties packaged inside the client ejb jar will be loaded by GlassFish application classloader, while jboss client-side runtime classes are loaded by GlassFish common classloader. So jboss client-side may not be able to load jboss-ejb-client.properties, especially if it uses its current classloader for resource loading.

If you see the following error, it means jboss-ejb-client.properties is not loaded:

Tests in error:
invokeClientBean(com.blogspot.javahowto.ClientBeanTestIT):
javax.naming.NameNotFoundException:
ejb:/service-on-jboss/ServiceBean!com.blogspot.javahowto.ServiceIF -- service jboss.naming.context.java.jboss.exported.ejb:.service-on-jboss."ServiceBean!com.blogspot.javahowto.ServiceIF"

3, build and run the project:

cd project-root
mvn clean install

...

-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running com.blogspot.javahowto.ClientBeanTestIT
May 18, 2012 2:00:37 PM com.sun.enterprise.v3.server.CommonClassLoaderServiceImpl findDerbyClient
INFO: Cannot find javadb client jar file, derby jdbc driver will not be available by default.
Look up ClientBean by name java:global/client-on-glassfish/ClientBean, got com.blogspot.javahowto._ClientIF_Wrapper@3735f04a
Result from clientBean.clientHello(): In serviceHello of com.blogspot.javahowto.ServiceBean@3e9c66de

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 14.354 sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

There is no transaction context or security context propagation during the remote invocation. If you need them, another approach is to use IIOP protocol and the interoperable naming service. But that requires EJB on both sides to expose 2.x-style remote home interface even for EJB 3 beans. Topic for another day.