EJB

Few days ago I’ve created a simple interceptors spike-solution at Github. Its purpose was to show my colleagues that in the EJB’s interceptors you can implement a code that exists in the same transaction and the same security context as the called EJB business method. Moreover, you can benefit from all the dependency injection you need. This project uses the following resources injected by the Application Server: TransactionSynchronizationRegistry – used for getting current transaction key and checking if we’re in the same transaction (I’ve written about it e....

More than 18 months ago I’ve posted my mock exam for Oracle Certified Expert Web Component Developer certification. Until now it’s quite popular and useful (deducting from the comments) for many of you. What I dislike about this exam is that it’s published as a plain WordPress post and it’s rather awful to edit it and it’s not so easy to read as well. So, that’s the aim of my small side project: to create a basic platform for presenting exam questions and their answers....

Sometimes you need to pass some additional / contextual data to the called EJB method. Because it’s a contextual data you don’t want to end in changing signatures of all your EJB methods just to add a single or few such parameters. It is possible to add context data using the SessionContext object. Take a look at the following code example: package com.piotrnowicki; import javax.annotation.Resource; import javax.ejb.SessionContext; import javax.ejb.Stateless; import javax....

Recently, I’ve bumped into few posts on StackOverflow where people tend to compare container managed EntityManager instances (so the one injected by the container) by invoking EntityManager#toString() method. I’ve felt that it’s fundamentally wrong to compare EntityManager instances without knowing how they’re managed by the JPA provider or the Server Application. And what if this behaviour differs between Application Server vendors? The JPA provider provides an implementation of EntityManager – that’s obvious....

You probably know that if you use BMT (Bean Managed Transactions) you can get information about current transaction status by using UserTransaction interface (which implementation can be fetched either by JNDI or using dependency injection) and executing it’s getStatus() method. If you use CMT (Container Managed Transactions) you cannot use UserTransaction interface. Instead, you can manage your transaction through SessionContext interface. This interface gives you two places that hooks to the current transaction: setRollbackOnly(-) and getRollbackOnly()....

Just a note to myself – always check what classes are you importing in IDE, because if you see @Singleton in your class, it doesn’t mean it will work as a EJB Singleton. In my case it wasn’t referencing to javax.ejb.Singleton as I assumed, but com.sun.jersey.spi.resource.Singleton. Wasted 2 hours of looking for the answer or issue in a glassfish-3.1 JIRA. Did I mention I should always check the exact package of the imported class…?...

When you create a deployment using Arquillian (great test runner for testing your Java EE code in the container of your choice: jBoss, Glassfish, OpenEJB, … either in embedded, managed or remote mode) remember that the name of the deployment archive file is the exact filename that will be executed in the container. It does make a difference if you use *.war or *.jar for your deployment, so beware the following construct if it’s not exactly what you intended to do:...