Friday Dec 11, 2009

Portable Global JNDI names

The introduction of dependency injection in JavaEE5 did reduce the need for doing a JNDI lookup. However, there are times when the users / clients had to rely on the good old JNDI lookup to acquire EJB references. Typical examples of such clients performing lookup of EJBs include (a) a JavaEE component from a different application and (b) a Java SE client.

The problem was such clients had to use “global” jndi name to lookup the target bean. All along the ejb specifications had been silent about portability of such global jndi names. This allowed each vendor to assign a global jndi names to EJBs in a vendor specific way. This meant that the client code that performed a lookup using global JNDI names were inherently non portable across appserver vendor implementations.

For example, the following code (part of a non JavaEE client) assumes that FooBean has been mapped to the global jndi name: "_app1_mod1_FooBean"

public static void main(String[] args)
    throws Exception {

    InitialContext ic = new InitialContext();
    FooBean fooBean = (FooBean)

    //Use fooBean

This code might break if the target bean was deployed to a different JavaEE server.

Portable Global JNDI name in EJB 3.1

EJB 3.1 solves the above problem by mandating that every container must assign (at least one) well defined global JNDI names to EJBs.
The general syntax of a (portable) global JNDI name of an EJB is of the form:


In addition to the above name, if the EJB exposes just a single client view (that is it implements just one interface or the no interface view), the container is also mandated to map the bean to



  1. <aplication-name> defaults to the bundle name (.ear file name) without the bundle extension. This can be overridden in application.xml. Also, <application-name> is applicable only if the bean is packaged inside a .ear file.
  2. <module-name> defaults to bundle name (.war or .jar) without the bundle extension. Again, this can be overridden in ejb-jar.xml.
  3. <bean-name> defaults to the unqualified class name of the bean. However, if @Stateful or @Stateless or @Singleton uses the name attribute, then the value specified there will be used as the bean name.

Example 1:

Assuming that the following classes and interfaces are packaged inside hello.jar and deployed as a stand alone module

package com.acme;
public interface Hello {
    public String sayHello();

package com.acme;
public interface GoodBye {
    public String sayBye();

package com.acme;
public class MyEJB
    implements Hello, GoodBye {

package com.acme;
public class HelloBean {

package com.acme;
public class ShoppingCart

package com.acme;
public class Util { //Not a EJB or Servlet

The following portable jndi names are then made available by the container to the clients:





  1. Since MyEJB implements more than one interface, the global jndi names must include the implemented interface
  2. For HelloBean, the value specified in the name() attribute is used as <bean-name>
  3. Since HelloBean bean exposes a no interface view, the qualified bean class name is used as <fully-qualified-bean-intf-name>
  4. Since ShoppingCart bean exposes a no interface view, the qualified bean class name is used as <fully-qualified-bean-intf-name>
  5. Since, the application is deployed as a standalone module, <app-name> is not used in the global jndi name.

Client code:

InitialContext ic = new InitialContext();
Hello = (Hello) ic.lookup("java:global/hello/MyEJB!com.acme.Hello");
GoodBye = (GoodBye) ic.lookup("java:global/hello/MyEJB!com.acme.GoodBye");

ShoppingCart = (ShoppingCart) ic.lookup("java:global/hello/ShoppingCart");

You can also use the portable jndi names in injection too


private ShoppingCart cart;

More name spaces

In addition to the java:global namespace, the container is also required to make the bean(s) available under two other name spaces:
java:app and java:module

Why do we need these two? In the case of java:global, the name contains a hard coded <app-name> and (or) <module-name>. Assuming, that <app-name> and <module-name> are not specified in .xml, re-packaging the bean and client into a different module breaks the client. For example, if FooBean was originally packaged inside foo.jar, the client that looked up using ic.lookup("java:global/foo/FooBean") will break if FooBean is re-packaged inside module2.jar

Since, most of the time the beans and the clients are colocated in the same application or even within the same module, EJB 3.1 allows accessing these colocated beans in a easier way. The spec defines two more name spaces called java:app and java:module.

java:module allows a component executing within a Java EE application to access a namespace
rooted below the <module-name> portion of the namespace corresponding to its module.

You can think of java:module as the jndi sub-context that is rooted under the "current module" in which the client is located. java:module differs from java:global in the sense that the client can access only those beans that are packaged inside the same module as the client. If a component in module1 has to lookup a component in module2, then it has to use java:global (or java:app).

can think of java:app as the jndi sub-context that is rooted under the "current app" in which the client is located.

The java:app and java:module names are of the form:




In our example, the Util class can access other components as follows:







Running the sample application

  1. Save and unzip
  2. cd portable-jndi-name
  3. mvn install will build the application. The .war file will be under target directory
  4. <v3-install-dir>/bin/asadmin deploy --force=true target/portable-jndi-app.war
  5. Open a browser and access localhost:8080/webejb/Example1Servlet
I will be updating this blog with one more sample app where the EJBs and Servlets are packaged inside a .ear file.

Also, I have used mvn as the build / packing tool.


[1] EJB 3.1 Specification

[2] Ken Saks' note on portable jndi name

Thursday Nov 06, 2008

Singleton EJB support in GlassFish V3 Prelude

The GlassFish Enterprise Server V3 Prelude has been released. To get a sneak preview of some of the EJB 3.1 features in V3 Prelude, you need to install ejb container by following the instructions from my earlier blog

In this blog, I will describe one of the EJB 3.1 features available in V3 Prelude: Singleton EJBs.

One of the frequent problems that ejb developers face is to figure out how to share data between multiple components of an application. Singleton session beans are meant for this purpose. A Singleton EJB is a session bean component that is instantiated once per application. A Singleton session bean is intended to be shared by concurrent requests. In other words, all requests to the singleton will be routed to the single instance of the Singleton bean instance.

Let me demonstrate this by using a simple application. Lets say that we want to count the number of times a HelloServlet was accessed. Though there are other ways to do this, lets use a Singleton bean to accomplish the task. Note that, we can not maintain a counter inside a Stateless session bean as the container might maintain a pool of these stateless bean instances (and each will have their own counters). The Singleton session bean (called CounterBean) keeps a counter. It will have a incrementAndGetHitCount() method that increments the counter and will be called from the SimpleServletServlet.

Defining a Singleton bean

A singleton bean can be defined by using the @Singleton annotation. Note that Singleton beans can have business interfaces and interceptors just like Stateless and Stateful session beans. Also, remember that EJB 3.1 now allows optional interface view. More can be read about optional interface view in my earlier blog.

package com.sun.ejb31.test;

import javax.ejb.Singleton;
public class CounterBean {
    private int hitCount;

    //Note the use of synchronized keyword
    public synchronized int incrementAndGetHitCount() {
        return hitCount++;


Handling concurrency in a Singleton

Since there is only one instance of the Singleton bean, the container routes all the requests (method invocations) to the single instance. This means that concurrent invocations are possible. The EJB 3.1 specification allows two choices to handle concurrency issues:

Container Managed Concurrency (CMC): With Container Managed Concurrency, the container is responsible for controlling concurrent access to the bean instance based on method-level locking metadata. Each business method method can be annotated with either a Read(shared) lock or Write (exclusive) lock Note: GlassFish V3 Prelude supports only BMC.

Bean Managed Concurrency (BMC): With Bean Managed Concurrency demarcation, the container allows full concurrent access to the Singleton bean instance. It is the responsibility of the bean developer to guard its state as necessary against synchronization errors due to concurrent access.

Obtaining a reference to the Singleton bean

Obtaining a reference to a Singleton bean is no different from obtaining a reference to other types of beans. In our example, we will inject a reference to the Singleton bean into our Servlet (though a JNDI lookup would have worked as well too).
package com.sun.ejb31.test;

import javax.ejb.EJB;

public class SimpleServlet extends HttpServlet {
    @EJB CounterBean counterBean;
    protected void processRequest(
        HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
        PrintWriter out = response.getWriter();
        try {
            out.println("<title>Servlet SimpleServlet</title>");  
            out.println("<h1>Number of times this servlet is accessed: "
                    + counterBean.incrementAndGetHitCount());
        } finally { 



How to deploy and run

Assuming that you already have installed the ejb container in V3 Prelude, (if not follow these instructions)

To start the server: java -jar <install_dir>/modules/glassfish.jar

To deploy: <install_dir>/bin/asadmin deploy SimpleCounter.war

To redeploy: <install_dir>/bin/asadmin deploy --force=true SimpleCounter.war

URL to access the servlet: http://localhost:8080/SingletonCounter/SimpleServlet


EJB 3.1 public draft


Source files: and

Monday May 05, 2008

Installing EJB Container in GlassFish V3

The EJB 3.1 Specification has a load of features that simplifies EJB development even further. A couple of EJB 3.1 features have been implemented in GlassFish V3. In this blog I will describe how EJB container can be installed in GlassFish V3.

Installing EJB 3.1 Container module in GlassFish V3 TP2

  1. First download and install GlassFish V3 Technology Preview 2
  2. cd to <V3_install_dir>/bin
  3. run update tool (./updatetool). If you are running it for the first time, it will install the update tool. Rerun it again to run the update tool
    1. From the left panel, pick the Available add-ons
    2. Click the glassfishv3-ejb checkbox and click install
    3. Accept the License agreement by pressing Accept. This will install the ejb-container module
See my other blog for a sneak preview of some of the EJB 3.1 features in GlassFish V3

Mahesh Kannan


« April 2014