5/18/2012

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 system property 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.

6 comments:

wow error 134 said...

hi.........
the post is full of information.i had some errors but now i solve them after reading your blog.Thanks for sharing information.

Dana Peele said...

Thank for this... extremely helpful! If you have a chance, would you please demonstrate the reverse? Ie, how to call a remote EJB deployed to a GlassFish 3.1.x server from an application deployed to JBoss AS 7.1.1 standalone server? Thank you in advance!!!

javahowto said...

I will cover JBoss AS7--> GlassFish 3.x EJB invocation in a future post. Stay tuned.

javahowto said...

JBoss AS7--> GlassFish 3.x EJB invocation will be harder to configure, though the sample app is pretty much the same. It is because the difference in the 2 server's architecture and implementation choices. One will need to configure a glassfish module, sun jdk module, and replace the default orb (jacorb) with the JDK one. I will come back to it next year.

Gergely Papp said...

Hi!

Excellent post, too bad I need a bit different solution. :(

I've been struggling with making a call from JBoss 7.1 AS and JBoss 6.1 EAP to WebSphere for weeks now. I won't say I'm new to IIOP/CORBA but I just can't wrap my head around it.

I found very little on the Internet about this topic, and it is making me go nuts by now.

I would need all the bells and whistles of like identity propagation, transaction context. On standalone clients and in OpenEJB junit container it works flawlessly either using IIOP, or CORBALOC or the WebSphere client jars and IBM ORB implementation. Nothing I do makes it work in JBoss.

Frankly I'm quite pissed, as the call works from a 5 line long JRE class, and doesn't budge on a certified application server.

I've asked tech support for help, but frankly they are even worse off than I am at the moment.

I think the article you promised would get me through the issue, or would you be able to give me any ideas on how to wrap this up?

Thank you in advance!

javahowto said...

If you're a paid JBoss customer, the best bet is to contact JBoss support. Not sure if interop with websphere is covered but I think you have good reason to push it since it worked in non-JBoss environment.

Calling remote EJB from inside JBoss AS 7.x or EAP 6.x is a bit tricky for 2 reasons:

1, how to configure and manage client-side library with JBoss Modules, instead of the conventional hierarchical classloader.

2, there may be subtle differences in JacORB and the orb in the remote side, which is typically Oracle JDK-based orb. This will change once JBoss
AS8 switches to JDK orb.

Another thing to consider is iiop-based interop will be pruned in Java EE 8, though appservers can keep support it in their products. Maybe too early to worry about it as they are struggling to get Java EE 7 out.