This tutorial desribes, how to install and configure a standalone Tomcat, so that a deployed webapp can connect to a jBoss and use the authentication of the application server. This method is decoupled from the login module or authentication type (LDAP, Database, …), respectively. It differs from the approach described in Standalone Tomcat with jBoss plus authentication against LDAP, in that it allows for parallel logged in users and it does not need to authenticate to LDAP/Database on both sides, but on the jBoss only.
Category: Java
The Cartesian Product Read Issue
Building up a project with a JPA persistence layer requires some design decisions from you. Although the abstraction layer is meant to relieve you from the pain working with a relational database, you have to keep in mind that everything you do with your entities has somehow to be translated to the underlying resource and is subject to its constraints. Often the abstraction layer even adds constraints, since the OR-Mapper has to be independent from the concrete implementation of your resource and therefore can only use the intersection of the different sets of functions. Furthermore there are general solutions to many common problems that might be a lot of slower than a specialized implementation in some cases. In the last posts I tried to give some hints and advices, how a persistence provider — especially hibernate — can be configured, in order to overcome many of this problems. Still, you have to decide beside plenty others, when to use lazy- and eager-fetching.
Read More
Unit Test Your Persistence Layer
This post is an addition to the post Unit Test Your DB Schema and Named Queries. It shows how to use the TestNG Annotations in order to simulate a lightweight EJB container enabling you to test your persistence layer (DAO, entity classes and similar). If you are using JBoss 6 you may use the embedded EB container. EJB3Unit supports testing Enterprise Beans, too. But I couldn’t get the latter to run smoothly and I do not use the former, yet. So if you are still tied to the old Java EE 5 world you might benefit form this solution.
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
Unit Testing of DB Schema and Named Queries
It is essential to software development, that bugs or misconfiguration are detected as early as possible. Therefore, tests being run during the build process can help to detect problems before your software is applied in a productive environment. In a EJB 3.0 application you may validate your DB-Schema and your named queries in a unit test, by starting up the EntityManagerFactory. It is one of the fine new features of JPA 1.0 (related to CMP in EJB 2.x) that you are able to use it without a container in a normal Java application. For your test you need a jndi.properties in your classpath:
Read More
Cache Named Queries with Hibernate
In the last post (see organize your named queries) a nice way to organize named queries has been proposed. The advantages of using named queries in the first place is discussed in the mentioned post, too. Hibernate offers a nice way removing a big disadvantage of named queries or to be more precise of JPQL queries in general, as compared with associations of an entity. Query results are not cached by default, neither in the first level nor in the second level cache. But you may add a query hint in order to advise hibernate to cache the results. Fortunately, like for associations, the query cache does store the ids for resulting entities, so the first and second level cache is requested for the respective objects. If the values are not present in the cache they are retrieved from the underlying resource.
Read More
Organize Your Named JPQL Queries
Named queries have some nice properties. They are precompiled and therefore faster than their “normal” counterparts, encourage to use named parameters, make your code easier to read and avoid messing up your code with string concatenated queries. A nice addon is, that named queries are validated during the creation of the persistence unit. If you have a unit test (see unit test db schema and named queries), checking whether the entities represent a valid DB Schema, the named queries are validated, too. So, there will be syntactical as well as some static analysis (e.g. “exist all referenced entities?”) during the test phase, before your application is even packaged.
Read More
EAGER Fetch of Multiple Associations
Associations are fetched lazily by default. You may change this behavior by setting the parameter fetch=FetchType.EAGER of the annotation @OneToMany for example. This has the disadvantage, that the association is eagerly fetched each time the respective entity is retrieved from the underlying database. This leads to the so called cartesian product read issue since the respective association is retrieved with the query of the owning entity via LEFT OUTER JOIN (see JPQL and joins). So, a lot of redundant data might be retrieved from the database, since the OR-Mapper has no interception point where he can prevent to retrieve data cached already. Another way is to overwrite the lazy fetch type in a jpql query (see override fetch type). So the cartesian product read issue does still exist, but you can control when to eagerly fetch an assoctiation and when not.
Read More
Ordering Collections with JPA
Often there is the need to sort an entity or a collection, e.g. If you have a list of line items in a bill and do not want that the order may change or is semantically wrong. Unfortunately, using a java.util.List will not suffice, since the DB has not to retain the order of the list. You might recognize this only after a long time, since some RDBMS will return the rows by insertion order. There are different ways to introduce an ordering with JPA (see Java Persistence: Ordering).
Read More
JPQL joins and benefit/drawbacks of fetch joins
JPQL can handle LEFT OUTER JOIN (may be abbreviated to LEFT JOIN) and INNER JOIN (may be abbreviated to JOIN or to IN() <- don't use AS for the alias of "right hand side" here in combination with hibernate). The following document describes the different types of joins: visual explanation of sql joins.
Read More