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
# in a new terminal/tab, or split it
# username: test
# password: 1234
2, configure and start GlassFish 3.1.x:
./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:
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


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.


Standalone Java Client for JBoss AS 7.1.1: Maven and JUnit Edition

In previous post, Standalone Java Client for JBoss AS 7.1.1, I showed a hand-written project of standalone client in JBoss AS 7. In this post, I will rewrite it as a maven project with JUnit and jboss-as-maven-plugin. The result is project jboss-as-7-client at github.

The steps are slightly different than the handwritten edition:

1, start JBoss AS and add users:
./add-user.sh (user name: test, password: 1234)

2, "mvn clean install" will build the project, package and deploy the ejb jar to JBoss AS 7, and run the standalone client test.

3, if the ejb jar is already deployed in JBoss AS, step 2 will forcefully overwrite it. If you want to undeploy the ejb jar, run
mvn jboss-as:undeploy


Standalone Java Client for JBoss AS 7.1.1

In this previous post, I created a sample Java standalone client connecting to JBoss AS 5 & 6. Now let's look at how to do it in JBoss AS 7.1.1.

This sample application consists of a stateless EJB, its remote business interface and a standalone java client that looks up the EJB and invokes its business method.

package test;

public interface ClientIF {
public String clientHello();
package test;
import javax.ejb.*;

public class ClientBean implements ClientIF {
public String clientHello() {
return "In clientHello of " + this;
package test;

import javax.naming.*;

public class Client {
public static void main(String args[]) throws Exception {
ClientIF clientBean = InitialContext.doLookup(args[0]);
System.out.printf("Result from clientBean.clientHello(): %s%n%n",
In addition, you also need to prepare a jndi.properties file, and a jboss-ejb-client.properties file, both should be in the client classpath:
# jndi.properties
# jboss-ejb-client.properties


remote.connection.default.port = 4447


With the above 5 source and config files in place, the project structure looks like this:
While in project root directory, compile and package the ejb jar:
javac -cp $JBOSS_HOME/bin/client/jboss-client.jar test/*java
jar cvf client-ejb.jar test/ClientIF.class test/ClientBean.class
If JBoss AS is not already running, start it in a new terminal, and add the application user referenced in the above jndi.properties (add-user.sh is an interactive script). When prompted, enter user name test and password 1234.
cd $JBOSS_HOME/bin

To deploy the ejb jar, simply copy it to JBoss AS deploy directory:
cp client-ejb.jar $JBOSS_HOME/standalone/deployments/
Finally, run our standalone Java client that looks up and invokes the remote EJB:
java -cp $JBOSS_HOME/bin/client/jboss-client.jar:. test.Client ejb:/client-ejb//ClientBean\!test.ClientIF

May 11, 2012 10:21:16 PM org.xnio.Xnio <clinit>
INFO: XNIO Version 3.0.3.GA
May 11, 2012 10:21:16 PM org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.0.3.GA
May 11, 2012 10:21:16 PM org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version 3.2.3.GA
May 11, 2012 10:21:17 PM org.jboss.ejb.client.EJBClient <clinit>
INFO: JBoss EJB Client version 1.0.5.Final
May 11, 2012 10:21:17 PM org.jboss.ejb.client.remoting.VersionReceiver handleMessage
INFO: Received server version 1 and marshalling strategies [river]
May 11, 2012 10:21:17 PM org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver associate
INFO: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@53f64158, receiver=Remoting connection EJB receiver [connection=Remoting connection <a995a79>,channel=jboss.ejb,nodename=m-2]} on channel Channel ID bc3ed9ca (outbound) of Remoting connection 2e00e753 to localhost/
May 11, 2012 10:21:17 PM org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver handleMessage
WARN: Unsupported message received with header 0xffffffff
Result from clientBean.clientHello(): In clientHello of test.ClientBean@4783165b
The client class does a generic lookup, taking lookup jndi name from application arg. In the above java command line, ejb:/client-ejb//ClientBean!test.ClientIF is the jndi name for our remote EJB. This jndi name is constructed from the ejb module name, bean name, bean distinct name, and its remote business interface. More details are in this JBoss docs page.