Sunday, 8 March 2015

Getting notified when Java EE Application is ready


Within the Java EE ecosystem, you have various options when you want to perform some kind of action when the application is just deployed or server is up and running again.

This text gives a review of them. Or how to get ready when Java EE is up and running.


One of the most known options, probably because it is the easiest option, is the @Startup annotation for the @Singleton EJB bean (since EJB 3.1; December 2009 included in Java EE 6)

Singleton beans can have the indication that they need to be created and initialised when the container is booting up.  This gives us the option to perform some initialisation for the application.

public class StartupEJB {

    public void init() {
        // EJB Ready    }



The oldest option is using the servlet infrastructure.  The ServletContextListener, available since Servlet 2.3; September 2001, allows you to perform the initialisation steps you want.

public class MyServletContextListener implements ServletContextListener {

    public void contextInitialized(ServletContextEvent sce) {
        // Servlet ready    }

    public void contextDestroyed(ServletContextEvent sce) {


The downside of this approach is that you need to register the class in the web.xml configuration file.

What are your options if you want to have a solution with annotations only where you don’t need any configuration in an XML file?

You can annotate a HttpServlet with the @WebServlet annotation where you indicate the loadOnStartup member (Servlet 3.0; december 2009 - Java EE 6)

@WebServlet(loadOnStartup = 2, urlPatterns = "/test")
public class ServletStartup extends HttpServlet {

    public void init(ServletConfig config) throws ServletException {
        // Servlet Ready    }

But why should we create a servlet which we only use for the init method and not for some real functionality.  This is not a real option.

Another options is including DeltaSpike in your application. Or use it because there is a good chance that you can use some other goodies from the CDI framework. They have created a ‘bridge’ between the ServletContextListener and a CDI event.  They register a listener, with the help a a web.xml fragment which can be located within a jar file, and fire a CDI event. (compatible with Servlet 3.0 containers; works with any Java EE 6 application server)

public class DSServletStartup {
    public void onCreate(@Observes @Initialized ServletContext context) {
        // Servlet Ready (DS version)    }

PS. The @Initialised is not the CDI one because it is not available in Java EE 6.

This way, you can have a configuration less way to get notified when the Servlet system is ready.


The CDI specification was the last one of the major 4, who has defined the possibility to get notified of the availability of the system.
Only recently, with the CDI 1.1 version; may 2013 (Java EE 7); you have the possibility to receive a CDI event when the container is ready.

public class CDIStartup {

    public void postConstruct(@Observes @Initialized(ApplicationScoped.class) Object o) {
        // CDI Ready    }


The last framework that I will include in this overview, has again since quite some time the possibility to have some feedback on startup.
You have the system event PostConstructApplicationEvent (together with SystemEventListener JSF 2.0; July 2009)

This listener, with the correct event, must be defined within the faces configuration file (faces-config.xml) to have it executed when JSF system is ready.

    <!-- Application is started -->    <system-event-listener>

public class JsfStartup implements SystemEventListener {
    public void processEvent(SystemEvent systemEvent) throws AbortProcessingException {
        // JSF Ready    }

    public boolean isListenerForSource(Object o) {
        return true;    }

Since it requires some configuration in an XML file, I also created some kind of bridge so that a CDI event is emitted instead.  (see Jerry SystemStartup)


Just out of curiosity, I have created a web application where I coded the 4 feedback mechanism.  And I compared the order in which they occurred  on WildFlay 8.2 and GlassFish 4.1.  The 2 main Java EE 7 application servers available today.


It is no surprise that the order is different on the 2 servers, but only JSF is ready at a different moment. Because there is, to my knowledge, never described in any specification which is the order of initialisation of the different subsystem in the Java EE server.
But it really doesn’t matter, I don’t think there is any useless where you need to rely on the order of the startup.

What initialisation to choose

Whenever the initialisation needs some database access, the EJB is the natural choose because we have transaction support available. In those situations, @Startup is easy to use.

The other way that I use quit often, is the JSF initialisation since a lot of the applications I’m involved in are JSF based.  That is the reason why I created some small utility class to convert the PostConstructApplicationEvent of JSF to a CDI event.

Have fun.

Monday, 2 February 2015

Auditing with JPA EntityListener


A lot of the projects need some kind of audit trail. They want to know who and when the last time a record was changed. Or recently we got a question how you could keep record of who read some data from the database.

Most of the time, there exists a database solution to these answers, but in other cases, it is easier to achieve with the JPA implementation.

This text describes 2 scenarios where you can use JPA to do some auditing on your users with the help of EntityListener.


The JPA EntityListener defines callbacks for the lifecycle of the entity. And as with any callback mechanism of a system, it allows you to extend the system with some generic functionality. 
There are 7 callbacks defined, a before and after for persist, update and remove and one method called after the load is done.
  • PrePersist
  • PostPersist
  • PreUpdate
  • PostUpdate
  • PreRemove
  • PostRemove
  • PostLoad

Keep record of reads

We recently got a request from a client who wanted to know which user at what time has read some data from specific tables.  
One of the lifecycle callbacks is the javax.persistence.PostLoad.  It gets called when JPA has read the record from the database and after it has been added to the context. 
As we wanted to separate the code for this auditing requirement from the Entity code, we placed the annotation @PostLoad in a callback listener class.  Something like the following code.

public class Audit {

    @PostLoad    public void auditUsage(GenericEntity entity) {


The GenericEntity is an abstract class (see further on why it is not an interface) that all of our Entity classes implements.  It contains, among others, a method getId() to retrieve the value of the Id field (primary key).

This Audit class is then defined on the entities we need to track with the use of the @EntityListener annotation.

@Table(name = "t_user")
public class Employee extends GenericEntity implements Serializable {

Our first idea was to separate the write of the audit information from the Audit class itself.  A loose coupling could be achieved by using the CDI event mechanism.

But it turns out the CDI injection is not available in callback listener classes. The spec (JSR 338) specifies that CDI injection must be available, but both GlassFish and WildFly have issues with it.

But ‘injection’ of the EntityManager is possible and thus we can persist the information to the database from within the Audit class.

@PersistenceContext private EntityManager em;
@PostLoad public void auditUsage(GenericEntity entity) {
    AuditRead auditRead = new AuditRead(entity.getClass().getSimpleName(), entity.getId());

Small remark, using the entity manager during a callback method is discouraged in the specification.  But you are allowed to perform some JMS operation.  That way you can also guarantee the correct logging of all read operations.

Record update information

With triggers on the database we can store the last time a record is changed.  But the username (user which last updated the record) can’t be stored like this, because the application server connects with a generic application user to the database. 
So the user name needs to be filled in by your application.

The @PreUpdate and @PrePersist lifecycle callbacks can be used for this purpose with the help of your security/user information. 

The logged in user information is most of the time available in some CDI bean placed on the Session scope.  As we already mentioned, CDI injection is buggy in the callback listener class.  

You can retrieve your bean using one of the following ways
- Retrieve the BeanManager from JNDI and get your bean directly from it (various sources on the internet shows you the 4 lines of code that you need to retrieve a line from the BeanManager)
- Write a CDI extension that captures the bean manager for you, so that you don’t have to retrieve it every time from JNDI. And then perform the 4 lines mentioned above. 
- Use the BeanProvider class from DeltaSpike where you can retrieve with a single line, the bean instance which implements a certain class (type to be exact)

Our GenericEntity abstract class has methods and fields to keep track of the user who created or last modified the entity. The database tables needs to have corresponding fields of course.


With the JPA EntityListeners we can handle most of the auditing requirements which we need in our applications.  We can keep track of who is reading some records or who updated some data for the last time. 
But beware of using of the callback listener classes.  CDI injection is most of the time not implemented according to the specification document and EntityManager should be used wich caution here.

Friday, 19 December 2014

CDI for Java SE already standardised with DeltaSpike


One of the things which are scheduled for the upcoming CDI 2.0 release, is the standardisation of the usage in a Java SE environment.

The Context part of CDI, the different scopes like RequestScoped or ApplicationScoped, isn’t the most useful thing in the Java SE environment.  But having a dependency injection and event mechanism on the other hand is very handy.

Weld and OpenWebBeans

But you don’t have to wait until the release of a CDI 2.0 compatible implementation before you can use it in a Java SE environment.

Weld and OpenWebBeans are at the moment the 2 most important implementations.  They have already the possibility to use CDI in a Java SE environment.

But both frameworks have different ways to start up the CDI environment because in CDI 1.x it isn’t standardised yet.

DeltaSpike is a collection of CDI extensions, and one of the things it provides, is a uniform way of starting CDI in a Java SE environment. And you can use OWB or Weld as your implementation.

DeltaSpike Container Control module

Here the uniform startup is defined;  You have one api module which defines the CDI implementation neutral (so not related to Weld or OWB) classes. And then there exists 2 Implementation modules, one for each CDI implementation.

Other things you need are
- Deltaspike core api and implementation modules
- OWB or Weld implementation with there transitive dependencies if any.

A sample maven project file can be derived from one of the DeltaSpike examples or you can use the one I have assembled, see further on.

When the maven config is in place, you can start for example the CDI container from your main method as follows:

public static void main(String[] args) {
    CdiContainer cdiContainer = CdiContainerLoader.getCdiContainer();
    ContextControl contextControl = cdiContainer.getContextControl();

Uber JAR

When you create a Java SE application, most of the times you wil create an Uber jar with a proper manifest file so that you can start your application easily with the command (the executable jar)

java -jar myProgram.jar

This can be achieved by using the shade plugin of maven.  You can find various resources on the internet how you can integrate and configure it in your project.

But using this procedure for distributing your CDI based application with DeltaSpike has a few pitfalls but workarounds are available. However, they arent related to DeltaSpike, nor OWB or Weld. It is a consequence of the deployment format.

The first issue that you should be aware of is that some files can be in multiple dependency jar files. Files like beans.xml and javax.enterprise.inject.spi.Extension are present multiple times in dependencies of your maven project.

If you don’t specify a certain configuration of the shade plugin, these files will overwrite each other and thus your program will not function.

You should use :
<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>

Another issue that I found is that the asm transitive dependency, used in OWB, isn't properly packed into the Uber jar file.
So you need to add the asm:asm:3.3.1 dependency to your own pom as dependency otherwise the application isn’t starting due to some missing classes.

And the last pitfall is that a lot of frameworks aren’t CDI compatible.  In a Java EE application, this isn’t a problem since there is no beans.xml file in the jar files of those frameworks.  This means that the classes in these jar files aren’t considered as CDI bean and thus no problem occurs during the startup of the application.
But in an Uber jar, all classes are in the same jar file which has a beans.xml file.  Those classes, or better some packages, can be excluded the easiest way when you use Weld, as it has support for a custom configuration in the beans.xml file which allows you to exclude some packages.

<weld:scan>    <weld:exclude name="org.jboss.weld.**" /></weld:scan>

Starter project

To get you started easily with a Java SE application which uses CDI 1.x, I created a basic maven application which has everything configured correctly.
You can download it here.

It has 2 profiles, one for OWB and the other is for Weld.  There exists also a third profile, called shade, which is needed in the case you are using the shade plugin on a project which uses OWB.  It makes sure that the asm transitive dependency is included in your final jar file.


So you don’t have to wait for CDI 2.0 to use CI in Java SE, you can use it already today. And with the use of DeltaSpike SE support module, you can even hide the details of starting the OWB or WELD container which makes it even easier.

Have fun with it.

Wednesday, 26 November 2014

Application module configuration with CDI 1.1


This text will tell you how you can use CDI itself to configure some portable extension of CDI you write yourself.  So first a little bit of introduction what a portable extension is and why you should use it.

When using CDI in your application, almost all the time you can just use what is available, like @Inject, @Named, the scopes and events to name the most important ones.

But sometimes, you must be able to programmatically define new CDI artefacts like scopes or beans.  This can be done by using the portable extension. The required steps are
- Create a class which implements the marker interface javax.enterprise.inject.spi.Extension
- Define the (full name) of the class in a file javax.enterprise.inject.spi.Extension defined in the META-INF/services directory of your application (or jar file)
- Define some method which has a CDI event parameter and has the @Observes annotation.

An example of this can be
public class ModuleConfigExtension implements Extension {

    void configModule(@Observes AfterBeanDiscovery afterBeanDiscovery, BeanManager beanManager) {
        System.out.println("Startup extension");

This method is then called when the CDI container is initialising.

The following image shows the different steps in the container initialisation.


So, now that we know how we can extend the CDI system, you can start creating additional beans and scopes for instances.  But also define some interceptors that applied to every bean like logging without the need to configure it in XML.

So far the introduction, now we can go to the configuration of your extension.
You have created the extension and has put it into a jar which you can reuse for all your projects you develop. 
And in most situations, the default you have defined are good enough, except for some applications that need a little bit of tweaked values.

The first question you can ask yourself is why you should CDI for the configuration here. Well because it is very convenient to override some defaults you specify yourself. And most of all, it is done in a type safe way.  You define the values in code and not as strings in XML, plain text or JSON.
Of course, if you want to be able to specify the values outside of your code, you have no other alternative then using some file with your values and reading that one in.

Lets have a CDI bean which define the defaults 

@ApplicationScopedpublic class BasicModuleConfig {

    @PostConstruct    public void init() {
        System.out.println("PostConstruct of BasicModuleConfig");    }

    @Override    public void doConfig() {
        System.out.println("Basic config for module");    }
(PS The idea is of course to have methods which return the default value. The above code is just to make it clear what is happening)

And when you need some other values as the default ones, just create an extends of this class which you annotate with @Specialized. This version will now be used.

@Specializespublic class CustomModuleConfig extends BasicModuleConfig {

    @Override    public void doConfig() {
        System.out.println("Custom specialized config");    }

CDI 1.0

Well there is a catch. With CDI 1.0 (Java EE 6), you where allowed to use the supplied beanManager in the after bean discovery phase to retrieve the CDI bean.

But this is a bit awkward as you are using CDI features before the CDI container is completely initialised.

So therefor they did some additional clarifications for the CDI 1.1 spec and it is now no longer valid (you receive an exception) when you are trying to do this in a Java EE 7 container.

CDI 1.1 solution

But they came up with another solution, although partially, but you need to do some additional work manually in your code.

They have introduced the Unmanaged class where you can receive an instance of a CDI bean, but which is not maintained by the container.

The following code gives you an example:
void configModule(@Observes AfterBeanDiscovery afterBeanDiscovery, BeanManager beanManager) {
    Unmanaged<BasicModuleConfig> unmanagedConfig = new Unmanaged<>(beanManager, BasicModuleConfig.class);    Unmanaged.UnmanagedInstance<BasicModuleConfig> configInstance = unmanagedConfig.newInstance();    ModuleConfig config = configInstance.produce().inject().postConstruct().get();

So you can use an initialisation method annotated with @PostConstruct, but you can’t use any injection into this bean. If you try this, you will receive some exception that a resolved bean resulted in null (since the container is not ready, the system doesn’t find the bean it needs to inject)

And there is another issue, the @Specialized isn’t picked up. 
But that you can fix in your code.  There is another event that is useful in this case.  When the CDI container scans the class path, every bean which is eligible for CDI management, is handed to a method which observe the @ProcessAnnotatedType event (Process bean phase in the above image)

Here we can keep the bean which has our specialised configuration, and use that one in our configuration.

The code of the extension could look like this then:

public class ModuleConfigExtension implements Extension {

    private Class<? extends BasicModuleConfig> configClass = BasicModuleConfig.class;
    <T> void collectImplementations(@Observes ProcessAnnotatedType<T> pat, BeanManager beanManager) {
        AnnotatedType<T> annotatedType = pat.getAnnotatedType();
        if (BasicModuleConfig.class.equals(annotatedType.getJavaClass().getSuperclass())) {
            configClass = (Class<? extends BasicModuleConfig>) annotatedType.getJavaClass();        }


    void configModule(@Observes AfterBeanDiscovery afterBeanDiscovery, BeanManager beanManager) {

        Unmanaged<? extends BasicModuleConfig> unmanagedConfig = new Unmanaged<>(beanManager, configClass);        Unmanaged.UnmanagedInstance<? extends BasicModuleConfig> configInstance = unmanagedConfig.newInstance();        ModuleConfig config = configInstance.produce().inject().postConstruct().get();
        configInstance.preDestroy().dispose();    }


There is a very convenient way of using CDI itself for the configuration of your portable CDI extension, because all your values are typesafe. When the default configuration values are defined in a CDI bean, you can easily specify custom values in a specialised bean when needed.  

Monday, 29 September 2014

Java EE / GlassFish future. (JavaOne 2014)


On JavaOne, there was a session about the roadmap for GlassFish but it discussed also the main topics for Java EE 8 now that it is approved by the JCP EC.

In this blog text, I will summarise the main points of this session.

You can find the session info here GlassFish Roadmap and Executive Panel [UGF9120]

Java EE 8

There are various things which are on the roadmap for Java EE 8 and some of them form a theme, can be grouped together.

One of them is around JSON communication and contains

  • The support for the HTTP 2.0 protocol as described in Servlet 4.0.  This is a continuation of the HTTP 1.1 spec, first proposed by Google as SPDY and now standardised in HTTP 2.0
  • More JSON support as it is replacing XML nowadays in enterprise cases. There will be a JSON Binding specification which defines how we can Java models for JSON structures.  Today we can do it already for example with the Jackson and Google GSon frameworks.
  • Security considerations for the JSON communication like how can the OAuth 2.0 be integrated.
  • And since JAX-RS is the base for all communications, improvements can be expected in that area too.

Another theme is security. There will be many places where security will be handled

  • The JSON communication with OAuth 2.0 as described earlier.
  • New security interceptors for CDI beans like we have already the @Transactional one.
  • Easier definition of resources for User management, like an annotation for defining the LDAP source, and handling things like password aliasing, role mapping and authentication.
But there will be other improvements or new features coming up.  Some of the most likely candidates are

  • Server sent events, as a lightweight version for the WebSocket protocol.
  • The action based MVC 
  • Splitting up CDI so that it can also be used in Java SE
  • Cloud and multi tenancy support.
  • ...


And what role will GlassFish play in all of this?  Well, each JSR needs a Reference Implementation (RI). So Oracle will continue to develop GlassFish as the RI for Java EE.  So there will be new releases but not commercially supported as they have announced at the end of last year.

And they promise that the quality, stability and security of the product stay as important as the implementations of the features. Because they see it as a tool to test out the new feature of any Java EE version (by the customers) but that you should choose for WebLogic for your production environments.

Why is webLogic always so much behind?

This was a question of one of the attendees of the session. Because for Java EE 7, it is just recently that some of the features became available.  One year and a half after the spec went final.

This long delay had to do with other priorities within Oracle and the time delay should be smaller in future versions.
In the past, the delay had to do with the internal differences between the code base of GlassFish and WebLogic.  Nowadays they are more aligned, but will never share the same code base.  So the plan is to have a time delay of about 6 months for WebLogic to make sure that the Java EE features works well in their enterprise level server.

So lets hope that it will be already the case for Java EE 8.

Time frame

They expect that Java EE 8 will be final in september 2017.  This is a very long period, but luckily we don’t have to wait that long.  By january 2016, there should be a proposed final version of the spec, so we should see not long after that a GlassFish 5.0 version which we can use to test out Java EE 8.

Sunday, 3 August 2014

Concurrency aspects of a Singleton EJB bean


In the previous blog text, I demonstrated some aspects of a Stateless EJB bean. It is guaranteed that each client receives his copy of the bean and that there is no concurrent access.  But it is possible, and here there where differences between the application servers, that the same bean instance is reused in different calls.

This text will handle the Singleton EJB beans. And at first glance, you just have to change the @Stateless annotation with @Singleton.  But there are a few consequences regarding the concurrent access of methods.

With the same set of examples, I’ll explain them to you.

Scope of Singleton

Now it is obvious how long the bean is kept alive. Singleton means that there is only one instance created and reused for all calls.

So if you change the annotation on the SomeEJB class to @Singleton, you are ready to go to run the code for scenario1.

public class SomeEJB { 

The results are now, for GlassFish and WildFly, the same and indicates that we received each time the same instance.

click 1 -> value = 1
click 2 -> value = 2
click 3 -> value = 3

For scenario2, we get the following results

click 1 -> value = 1 - 2 - 3 - 4 - 5
click 2 -> value = 6 - 7 - 8 - 9 - 10
click 3 -> value = 11 - 12 - 13 - 14 - 15

So it is very clear that as the name indicates, we have one instance of the bean. In all cases.

Concurrency aspects

Since we now have only one instance, what happens when we access the singleton bean in a concurrent way.  What is the default behaviour when multiple client access the bean instance?

This we can investigate with the code we wrote for the scenario3.  Look at the previous blog text for the actual code.

click -> value :   1 - 2 - 3 - 4 - 5 
elapsed time : 10018

As it is a singleton instance, each call increment the counter value.  But the interesting figure here is the time it took to complete the test.  It took just over 10 seconds to finish.  This is the 5 calls multiplied by the 2 seconds delay we have put into the method call.
And if you investigate the code execution more in depth, you should find that the second invocation only starts when the first one is finished.
The call to the first invocation immediate returns due to the @Asynchronous annotation and the Future return value. The for loop in the scenario3() method continues and starts with the second invocation of the Singleton bean method.  But this one doesn’t start, and thus also control is not given back to the scenario3 code, until the first invocation is finished.

There is obvious no parallel code execution anymore as we saw in the examples of the Stateless EJB bean.
And it looks look there is an invisible synchronised keyword placed on the method.

Concurrency protection

This default behaviour is specified in the EJB specification to protect the values which are kept in the singleton bean.  Since we now have only one instance available, multiple clients access this same instance and thus could potential read partial updated values.

The easiest solution was to guarantee that only one client can execute some method in the Singleton bean and that all other invocations must wait until the current one is finished.

In our example we proved it for the same method invocation, but in fact, any method call to the same Singleton bean is placed on hold.

Scaling Singleton beans

This default behaviour is easy for the developer and guarantees the correct concurrent access to the values kept in the Singleton bean but it is obvious not a good situation for the scaling properties of our application when we have a Singleton bean which is access by many clients in a concurrent fashion.

In that scenario, we have some additional annotations so that we can handle the concurrency aspects our selves. But of course, it gives the programmer a greater responsibility to do the correct thing.

The @ConcurrencyManagement annotation can be placed on the class and here we can indicate that the bean itself is responsible for correct multithread access handling.

public class SomeEJB { 
    private long counter = 0; 
    public Future<Long> asyncIncAndGet() { 

The other annotation we can use is the @Lock annotation (in case we do container managed concurrency management).  And there exists 2 types of locks, a READ lock and a WRITE lock.

You can obtain a READ lock, and thus execute the method, when no other thread has a WRITE lock at that time.  If there is a WRITE lock taken, your invocation has to wait until the lock is released.

To obtain a WRITE lock, no other threads should hold a READ or WRITE lock on that Singleton bean.

So if you change the code of the SomeEJB class to include the @ConcurrencyManagment annotation, you can have the following results if you run scenario3 again.

click -> value : 4 - 4 - 4 - 4 - 4 
elapsed time : 2002

The elapsed time indicates now that we have again parallel execution of the method but the values we receive for the counter are not correct.

Optimal Singleton pattern

So how should we use the @Lock annotation properly?

You should place the @ConcurrencyManagement(ConcurrencyManagementType.CONTAINER) and @Lock(LockType.READ) on the class definition.
This guarantees that we can access all method in a parallel way in the Singleton Bean.

And those methods that change the value of some instance variables we keep in the Singleton bean, should be annotated with

Then we know that no other thread will be reading the variables and we can safely change the values without the risk there will be read of some wrong values.


You can just annotate a POJO with @Singleton and there will be only one instance of the bean for your whole application.  By default however, the server guarantees that no threads are accessing some method of the bean.
This is a very safe way but also a very slow situation as performance can degrade because clients have to wait to access the bean.
With the use of @ConcurrencyManagement and @Lock annotations we can create the optimal situation where we can have concurrent access if we only read values and make sure that no other thread is reading or writing values when we make changes.

Wednesday, 16 July 2014

Some facts about Stateless EJB beans


With Java EE you can annotate simple java POJO classes with @Stateless and @Singleton markers and they become full fledged EJB beans with middleware services like transactions and security.

But on the contrary to the CDI bean scopes like @RequestScoped or @ApplicationScoped it is not immediate clear how long the EJB bean lives.

Of course, the term Singleton indicates that there is just 1 bean created, but how is then concurrency handled.  

This is the first part of a two part series about EJB beans.

Warning, in this text I use a Stateless EJB bean to store some state, here a counter which is not good practice as you also see throughout the text.  It is used to better indicate and explain what is going on.


The code I use through out this text is quite simple.  I keep a counter instance variable and have a method to increment this counter and return the current value.

public class SomeEJB { 
    private long counter = 0; 
    public long incrementAndGetCounter() { 
        return counter; 

For the thread safety aspects, I use an asynchronous EJB method call where I put in a wait of 2 seconds. Due to the Future return type of the method, the caller of this method gets the control back before the method has finished.

    public Future<Long> asyncIncAndGet() { 
        try { 
        } catch (InterruptedException e) { 
        return new AsyncResult<Long>(counter); 

This code will be used in three EJB beans (Singletons beans will be explained in a next text item).  For this text we use the @Statless annotation as shown in the above code example.

The ‘client’ of the EJB beans is a CDI bean with scope @Model.  This means that each request from the browser we get a new instance and thus a newly injected EJB bean.
In the browser we see the output of our test and how long it took through the use of an JSF page.

public class DemoBean { 
    private SingletonEJB someEJB; 
    private String data; 
    private long elapsedTime; 
    public void testEJB() { 
        long start = System.currentTimeMillis(); 
        scenario1(); // or 2 or 3
        elapsedTime = System.currentTimeMillis() - start; 


I use GlassFish 4 and WildFly 8 to verify the results of the tests.  And as you will see, both servers has a different approach but both are compliant with the specifications.

Scope of @Stateless

Lets start by calling the scenario 1 method on the Glassfish server.  If we click the button on the JSF page, we get the following result (timing is omitted here as only relevant for multithreaded scenarios)

    public void scenario1(){ 
        data = String.valueOf(someEJB.incrementAndGetCounter()); 

click 1 -> value = 1
click 2 -> value = 2
click 3 -> value = 3

Each click increases the value of the counter and since the value keeps incrementing, it is clear that we get the same EJB injected in the CDI bean each time we click on the button.

If we run scenario 2 on GlassFish, we get results that follow the same pattern.

    public void scenario2() { 
        data = ""; 
        for (int i = 0; i < 5; i++) { 
            data += " - " + String.valueOf(someEJB.incrementAndGetCounter()); 
click 1 -> value = 1 - 2 - 3 - 4 - 5
click 2 -> value = 6 - 7 - 8 - 9 - 10
click 3 -> value = 11 - 12 - 13 - 14 - 15

So is @Stateless behaving as a @Singleton? Lets investigate more.

If we run the same scenarios on WildFly server, we get different result and some of them may surprise you.

click 1 -> value = 1
click 2 -> value = 1
click 3 -> value = 1

Now it is clear that we receive each time a new instance of the EJB bean. And thus the value we get back is 1 each time.

Is this correct? Yes.  As the names says, it is a stateless session bean and thus we shouldn’t make any assumptions about which instance of the bean we receive the following invocation time.

This are the results if we run scenario 2 on WildFly

click 1 -> value = 1 - 1 - 1 - 1 - 1
click 2 -> value = 1 - 1 - 1 - 1 - 1
click 3 -> value = 1 - 1 - 1 - 1 - 1

And this is a surprise, no? We execute the method 5 times on the same injected EJB method.  So you could think that it is 5 times the same bean. 

But in fact, we get a proxy injected into the CDI bean, not the actual EJB bean (check the getClass().getName() outcome).  This is because there are possibly additional ‘interceptors’ executed for instance to handle the transactional aspects of database access.

So WildFly decided that the proxy is allowed to access another EJB bean instance each time you ask for a method call.

And after clicking a lot of times on the JSF button, I even have the impression that you receive each time a new instance and that there is no reuse ( or the pool of EJB beans must be very very large)

Exact lifetime of EJB beans on GlassFish

What happens if we concurrently access a stateless EJB bean on GlassFish? This is scenario 3. Let me first explain a bit what it does.

    public void scenario3() { 
        data = ""; 
        List<Future<Long>> results = new ArrayList<>(); 
        for (int i = 0; i < 5; i++) { 
        for (Future<Long> result : results) { 
            try { 
                data = data + " - " + String.valueOf(result.get(3, TimeUnit.SECONDS)); 
            } catch (Exception e) { 

The EJB method is asynchronous and returns immediate an object where we can retrieve the result of the method execution in some near future. So our client is able to call this asynchronous method, and immediately afterwards, calling that same method again (5 times in total in our example).

After we have called it enough times, we wait for the result to return with the result.get().

And what do you think the result will be, the value 5, 5 times in a row? Not exactly, again a surprise isn’t it?

click -> value :   1 - 1 - 1 - 1 - 1 
elapsed time : 2008

The second call to the asynchronous method takes place when the first execution is still ‘active’.  Again, the proxy which is injected, decides to call another EJB instance.

Use of instance variables

So how should we use Stateless session EJB beans?  The specification states that only one client at a time has access to the EJB bean instance. If another clients needs to access some functionality of the bean, it gets access to another instance.
But once the action is performed, the bean can be returned to the pool and used by another client (or same client the next time).

So it is safe to use instance variables to transfer information between private method calls.  But we shouldn't store information instance variables that we expect to linger around for a next call to the EJB bean.


When we inject an EJB bean, we get a proxy to this bean.  And this proxy bean will select a free instance of our EJB bean from the pool.  Of course, when there is no bean available, it will create a new instance. 

In GlassFish, the EJB bean, will return to the pool when it is no longer accessed by the client and can be used during some next call by the same or any other client.

In WildFly, the EJB bean is always destroyed and thus never reused.

It is safe to store information into instance variables for the duration of one call be it is wrong to use it to keep information between different calls.

Next time we discuss the @Singleton EJB bean.