In Java EE applications you are safe to consider that every method in a session bean has an associated transaction, since there is an implicit declaration of the transaction attribute required. If you like to change this behavior you have to configure this proactively by adding the annotation @TransactionAttribute with another value (see enum TransactionAttributeType). Context and Dependency Injection (CDI) does not have such an implicit declaration and no direct container managed support for transactions. But it has a very nice realization of the interceptor concept. This post shows, how to facilitate an interceptor in order to add a transaction to every (or a selection) method in a CDI bean, if it does not already exist. This is the default behavior of required.
Read More
Tag: java ee
Circumvent Nested Transaction Issues in Tapestry-5.x
Ajax component events may be wrapped in a transaction as I pointed out in “Transaction Handling for Ajax Components in Tapestry-5.x“. But on some occasions an Ajax component event is surrounded by a component event. So the code in the ControllerUtil of article “Transaction Handling in Tapestry5” will lead to ‘transaction already active’ problems, since we try to begin a transaction in the nested ajax component event although there is already an active transaction attached to the current thread. We can overcome this situation by checking, whether an active transaction is present and begin/commit/rollback a new transaction iff not. This behavior is similar to the default transaction attribute REQUIRED in Java EE.
Read More
Transaction Handling for Ajax Components in Tapestry-5.x
In “Transaction Handling in Tapestry5” I described, how to configure transactions wrapping a complete page or component render request. The same is necessary (possible) for Ajax components. Besides having less transactions and sharing the first-level-cache for subsequent calls, this realizes the “Open Session in View Pattern” automatically. So you can access the database lazily via getter from an entity, for example, without running into lazy loading exceptions due to the fact that the transaction has been closed and the entities are detached already.
Read More
Inject Java EE Beans into Tapestry-5.x
Tapestry uses it’s own Inversion Of Control (IOC) container. Tapestry pages are not Servlets or Servlet Filter (and not another managed class). Therefore they cannot be used for injection of Java EE Beans. But there is the AppModule, which is conceptual some kind of related to Spring Java Config. It allows to configure the Tapestry application directly in Java. Like everything in Tapestry it has an Adaptive API. Hence you have to follow a naming (signature) pattern for your methods and Tapestry finds them. You don’t have to implement an interface.
Read More
Script Your Remote Session Beans with Groovy
A JavaEE application with a multi-tier application generally has a presentation layer running in a servlet engine, a business logic layer running in a EJB container and a persistence layer facilitating JPA. During the development often there are occasions where a new functionality in the business logic (called backend from now on), which has no corresponding code in the presentation layer (let’s name it frontend), yet. So, what you need is a way to try out your code. This post shows you how to use the groovy shell to connect via JNDI to your remote session beans and call them in order to test your application fast. You may use it for a fast monitoring or maintenance API to your system, too. The groovy code of your efforts to test your code (monitor your application) may even be read from the history of the groovy shell and compiled into byte code. This code may be called from a test case or in a monitoring software (like nagios).
Read More
Override fetch type in JPQL Queries
Executing a getter — representing a one-to-many or many-to-many association — on an entity causes one or n (with n entries in the collection) database calls, depending on the fetching strategy (see fetch strategies). This is a nasty little detail that may cause performance bottlenecks. Changing the fetch type (lazy/eager) may not be appropriate, since an association is generally used in more than one context, so there may be contradictory concerns. Generally spoken, an eager fetching is only in rare occasions a good idea on one-to-many or many-to-many associations, since this leads to the cartesian product problem (simply put, you have to read [nearly] the hole db in order to get one entity). Fortunately there is another solution that enables overriding a lazy fetch type in a dedicated JPQL-Query. This may entail a hole bunch of JPQL queries you will have to write (not more queries to execute on the db!!!), since you want to eagerly fetch an association in one situation but not in another.
Read More
Using JAAS login modules from jBoss in Tomcat
A jboss login module (like the LdapExtLoginModule in jbosssx.jar shipped with jboss-5.0.1.GA) returns a
Group array with one SimpleGroup named “Roles” as its role set.
The parent class AbstractServerLoginModule combines this with the Principal
object representing the user. So the set of principals consists of two entries acting as the
user and his roles. These are added to the principals of the Subject instance, which
has been given to the login module when LoginModule#initialize(Subject, javax.security.auth.callback.CallbackHandler, java.util.Map, java.util.Map)
is called.