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.g. here), SessionContext – for reading user’s principal – user’s security context is also available in the interceptor, EntityManager – to persist some data before invoking the business method; it exists in the same transaction as the called method, so either both: the interceptor persistence and business method ends with success or both of them will be rolled-back. This example also shows how easily you can add RESTful Web Service to your application (take a look at com.piotrnowicki.interceptors.web package). ...

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.interceptor.AroundInvoke; import javax.interceptor.Interceptors; import javax.interceptor.InvocationContext; @Stateless public class MyService { /** * EJB session context - allows to get to the context data. */ @Resource SessionContext ctx; /** * Method invoked by the client. * * Explicit interceptor; it could be also configured in ejb-jar.xml * or it could be annotated at the class level (which means that * every class method will be intercepted.) * * @param id * just an exemplary parameter */ @Interceptors(MyInterceptor.class) public void myMethod(String id) { String ctxParamKey = ContextData.MY_PARAM.getKey(); // Simple as that - access context's data (map) value. Object ctxParam = ctx.getContextData().get(ctxParamKey); print("[myMethod] Method parameter: " + id); print("[myMethod] Context parameter: " + ctxParam); } /** * Just a minor helper method to print message on the console. * * @param msg * message to be printed. */ private void print(String msg) { System.out.println(msg); } /** * Simple enumeration to be less error-prone when using String based * identifiers as map key. * */ public static enum ContextData { MY_PARAM("myParamKey"); private String key; private ContextData(String key) { this.key = key; } public String getKey() { return key; } } /** * Interceptor which will set our context data before calling the * real EJB method. */ public static class MyInterceptor { /** * Interceptor's SessionContext is the same as EJB's. */ @Resource SessionContext ejbCtx; @AroundInvoke public Object intercept(InvocationContext ctx) throws Exception { String ctxParamKey = ContextData.MY_PARAM.getKey(); // Just put some data into context map. ctx.getContextData().put(ctxParamKey, "Context hello!"); // You can use EJB's context - i.e. check user's principal // ejbCtx.getCallerPrincipal(); return ctx.proceed(); } } } The result of this code execution is: ...

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. More interesting is that the Application Server is scanning all @PersistenceContext fields and wrapping these EntityManagers into its own class – a proxy – which delegates requests to the JPA provider’s EntityManager. Therefore, if you’re comparing results of toString() method of such EntityManagers, you can’t say about PersistenceContexts equality but rather about Server Application EntityManager equality. ...

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(). But what if you would like to check the current transaction’s status? ...

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: ...