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.

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:
cd $JBOSS_HOME
./standalone.sh
./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.

ClientIF.java

package test;

public interface ClientIF {
public String clientHello();
}

ClientBean.java

package test;
import javax.ejb.*;

@Stateless
@Remote
public class ClientBean implements ClientIF {
public String clientHello() {
   return "In clientHello of " + this;
}
}

Client.java

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",
                      clientBean.clientHello());
}
}

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
#
java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
java.naming.factory.url.pkgs=org.jboss.ejb.client.naming
java.naming.provider.url=remote://localhost:4447
java.naming.security.principal=test
java.naming.security.credentials=1234

# jboss-ejb-client.properties
#
endpoint.name=client-endpoint
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false

remote.connections=default

remote.connection.default.host=localhost
remote.connection.default.port = 4447
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

remote.connection.default.username=appuser
remote.connection.default.password=apppassword

With the above 5 source and config files in place, the project structure looks like this:

jboss-ejb/
.........jndi.properties
.........jboss-ejb-client.properties
.........test/
.............ClientIF.java
.............ClientBean.java
.............Client.java

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
./standalone.sh

./add-user.sh

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/127.0.0.1:4447
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.

Thoughts on ThreadLocal

2 main usages of java.lang.ThreadLocal variables:

1. Vertical sharing: sharing and propagation of contextual data through the entire processing cycle. This is similar to http request attributes binding, except for the different scopes. A ThreadLocal variable (e.g., security context, transaction context) can be propagated across different tiers, e.g., from web to local EJB. After the processing is done, care must be taken to clear ThreadLocal variables to avoid context leaking.


2. Horizontal sharing: sharing of objects across repeated and concurrent processing tasks. It offers a third approach for achieving thread safety, besides object locking and unshared instances. No need to clear TheadLocal variables after the current processing is done, since they are intended to be shared throughout the life of the thread.

However, when different class loaders are used among those tasks, the ThreadLocal object previously stored is not visible to the new class loader, and a new binding will be created. So over time, stales entries (instances of ThreadLocal data, and possibly anonymous inner subclass of ThreadLocal) will continue to consume memory. On the bright side, ThreadLocalMap keys use WeakReference and will eventually be cleared when the map approaches its capacity.

Think of ThreadLocal as a container that holds thread-sensitive application data. Therefore, a ThreadLocal variable can be associated with multiple threads. A thread can be associated with multiple ThreadLocal variables.

Thread class maintains a threadLocals Map (ThreadLocal.ThreadLocalMap) to hold all ThreadLocal variables for the current thread. The map key is the ThreadLocal instance, and the value is the actual object for this thread. When you call aThreadLocal.get() to retrieve the current binding, the get() method just asks the current thread to look up in its threadLocals map, using itself (aThreadLocal) as the key.

So the per-thread data is internally stored inside Thread class. Why did they create this ThreadLocal mediator class sitting in the middle? If I were to implement it, my first thought would be to introduce new methods to Thread class, such as setContextData(key, val), getContextData(key) & removeContextData(key).

Here are some reasons I can think of why ThreadLocal was designed this way:

1, Division of labor. Thread as a low-level construct should not be directly manipulated by applications. Application state is better managed by applcation classes.

2, Type safety. ThreadLocal<T> as a generic type is type-safe, and you can declare it to be ThreadLocal<Integer>, ThreadLocal<String>, or ThreadLocal<MyType>.

3, Encapsulation. The recommended practice is to declare a ThreadLocal<T> variable to be

private static final ThreadLocal<MyType> xxx = new ThreadLocal<MyType>();

The applicaton class can choose to completely hide the use of ThreadLocal as an implementation detail, or selectively allow certain operations, e.g., getXXX, setXXX, or removeXXX.