CDI event when transaction is finished

Introduction

CDI events are a very handy way of loosely coupling event driven code. At some point in your code you raise the event, and in some other area, you execute some functionality when this event occurs.

And there is no relation or code dependency between the 2 areas except the CDI event payload class.

For example

public class DataUpdatedEvent {
}

@Inject
private Event<DataUpdatedEvent> dataUpdatedEvent;
public void doSomething() {
    dataUpdatedEvent.fire(new DataUpdatedEvent());
}

public void onDataUpdate(@Observes DataUpdatedEvent dataUpdatedEvent) {
    // React on event
}

Synchronous

By default, the code is executed synchronous. But there are some other use case scenarios already possible without the need for the new, under development, CDI 2.0 spec which will allow also asynchronous execution.

A scenario that I used recently was to have some Cache mechanism available for data stored in a database.  I know there are a lot of full blown solutions like Infinispan, EHCache or TerraCotta to name a few. But I wanted to have a simple Map instance which also contains the data from the database table which changes very rarely.

When you place the event fire within a EJB stateless method, you don't have the required behaviour.

@Stateless
public class DataBoundary {

    @PersistenceContext
    private EntityManager em;
    @Inject
    private Event<DataUpdatedEvent> dataUpdatedEvent;
    public void saveData(Data data) {
        // Obviously, some more clever things to do
        em.persist(data);
        dataUpdatedEvent.fire(new DataUpdatedEvent());
    }
}

Since the execution of the CDI event mechanism is synchronous, the reading of the database table is done before the new data is committed and thus we are reading the old situation.

@Observer(during)

The Observer annotation has an element called during, which you can use to define when the observer method (the one with the @Observer annotation parameter) is executed.

By default, as already mentioned, it is immediately after the rase of the event. But you can also specify here the value TransactionPhase.AFTER_SUCCESS

public void onDataUpdate(@Observes(during = TransactionPhase.AFTER_SUCCESS) DataUpdatedEvent dataUpdatedEvent) {
    // Load the cache again
}

When the event is fired within a transaction, the observer method is executed after the transaction is committed successful to the database.

That is what we need in our simplistic caching example. The code will run after all the data is in the database table and thus the cache will be using the latest data.

Have fun

Miniature post: calling super in HttpServlet methods

Introduction

Lately I was writing some servlets for the Octopus SSO modules which I'm developing right now. Not used to do this anymore, I made a silly mistake which took quit some time to find out what I did wrong.

Servlets

Although they are still the basis of all web frameworks today, we don't write them that much anymore (at least, I don't do it)

So, I needed to have a simple servlet which performs some actions when it is called through the GET method.  Something like this (some code left out, see further on)

@WebServlet(urlPatterns = "/octopusSSOCallback")
public class SSOCallbackServlet extends HttpServlet {
   @Override
   protected void doGet(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse) throws ServletException, IOException {
      // Some things to keep track of the user
      SavedRequest savedRequest = WebUtils.getAndClearSavedRequest(httpServletRequest);
      httpServletResponse.sendRedirect(savedRequest != null ? savedRequest.getRequestUrl() : getRootUrl(httpServletRequest));
   }

}

When I did some tests, I got the following exception in the log.

java.lang.IllegalStateException: UT010019: Response already committed

So, the redirect couldn't be performed because something else closed the response and informed the browser what to do.

So I tried all obvious things what I possibly could have done wrong.  And I started removing code parts in the area marked with the comment // Some things to ...  to find what caused the behaviour.

But nothing solved the issue.

The next thing I tried was to remove the redirect itself, because that was the statement which gave me the exception. And I replaced it with some hello world message stuff.

The exception was gone, of course, but now I received an Http Status 405: method not allowed.

But how could the method not be allowed as I have written some code for it and verified that it gets executed by debugging the code? I was totally lost and didn't have any clue what was going on. I even thought for a moment that the application server had a bug. But that was absurd because I wrote some other servlets a few months ago on the same server.

And then some question on a forum lead me to the solution.

As a good practice, and because the IDE generated me the code as such, I always call the super method when I do override a method.  That is mostly the idea when you override some method.  Do the standard thing and then something additional you want.

So my code contained the following statement as the first line:

super.doGet(httpServletRequest, httpServletResponse);

And the default functionality of the servlet methods is to answer with a Http status 405.

Conclusion

You should always verify what the default functionality of a method is, also when it is defined in your coding standards that you should call the super method. :)

Getting notified when Java EE Application is ready

Introduction

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.

EJB

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.

@Singleton
@Startup
public class StartupEJB {

    @PostConstruct
    public void init() {
        // EJB Ready    }

}

Servlet

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 {

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

    @Override
    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 {

    @Override
    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.

CDI

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    }
}

JSF

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>
    <!-- Application is started -->    <system-event-listener>
        <system-event-listener-class>be.rubus.squad.startup.JsfStartup</system-event-listener-class>
        <system-event-class>javax.faces.event.PostConstructApplicationEvent</system-event-class>
    </system-event-listener>
</application>

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

    @Override
    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)

Order?

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.

WildFly	GlassFish
EJB CDI Servlet JSF @WebServlet(loadOnStartup)	EJB JSF CDI Servlet @WebServlet(loadOnStartup)

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.

Auditing with JPA EntityListener

Introduction

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.

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.

@Entity
@Table(name = "t_user")
@EntityListeners({Audit.class})
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());
    em.persist(auditRead);
}

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.

Conclusion

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.