Despite the fact that EJB inheritance sometimes uses Java inheritance — they’re not always the same. Just as you could read in my previous post, EJB doesn’t have to implement any interface to expose a business interface.
The other way around is also true — just because EJB is implementing some interface or extending other EJB doesn’t mean it exposes all or any of its views.
Let’s say we want to have some basic EJB exposing remote business interface. We then want to extend this EJB and override remote business methods.
Nothing fancy, right? But let’s take a look at some examples.
This post describes some of the pitfalls when coping with intercommunication between different modules (EAR, WAR, EJB-JAR) deployed in the same Java EE 6 Application Server.
The problem is as follows: you have two modules (let’s take the EARs as an example) that are deployed in the same JVM / Application Server: App1.ear and App2.ear.
service.jar; it’s an EJB-JAR with the business logic of the application,
service-api.jar; it’s an API for the service.jar, so the EJB’s in service.jar must implement this API.
client.jar; it’s the EJB-JAR with the business logic of the client application,
service-api.jar; it’s the same API / interfaces as in App1.ear/service-api.jar. It’s here because you will need to know the API of the
service.jar if you want to communicate with it.
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?
Well, the first answer would be: think twice if you really need to do this.
The transaction is container managed, so get/setRollbackOnly(-) should be probably the most important methods for you.
However, if you still need to get some more detailed information about your CMT you can use the TransactionSynchronizationRegistry interface which (just like UserTransaction) can be fetched using JNDI or @Resource annotation:
Here you can find what the integer status returned by this method invocation means.
Just a letter to my future self:
When you use Properties and creates the entries, remember to avoid the whitespaces. The properties are inserted as-they-are, so no trimming occurs.
It might sound trivial, but it wasted at least an hour of my time, while I was searching for a bug in a totally wrong department…
Properties p = new Properties;