com.sun.enterprise.deployment.backend.IASDeploymentException: Could not resolve a persistence unit corresponding to the persistence-context-ref-name [de.icanmakeit.jpokerstats.jpa.dao.GameDao/_entityManager] in the scope of the module called [jpokerstats]. Please verify your application.

The core problem here is that the mentioned GameDao uses the @PersistenceContext annotation to obtain an EntityManager from the container (or in this case Spring) but there are multiple persistence units defined in the persistence.xml (for the live system, for testing, etc.) and the Glassfish is unable to decide to which of these persistence units the annotation should be mapped.

Since I wanted all of this to be managed by Spring, I didn’t bother this error and worked around it by downgrading the web.xml from 2.5 to 2.4 which disabled the J5EE dependency injection mechanism in Glassfish and let Spring do its job. Simply specifying @PersistenceContext(unitName=”myunit”) wasn’t an option, since the same classes use a different persistence unit during JUnit tests and on the live server and explicitly specifying a persistence unit name breaks the unit tests.

Since my “inner ITIL” requires a developing solution after finding a workaround, I searched around the net, read a couple of dozen forum posts and finally figured out a way to solve the problem (…which I could have done earlier if I only had read the complete J5EE specification… *yawn*).

When deploying a 2.5 web application to Glassfish, the server examines it for any dependency injection annotations such as @PersistenceContext. It generates a default name for any unnamed annotation by using the FQCN, appended with a slash and the name of the field/property that is the injection target. In the above example, this would result in the name de.icanmakeit.jpokerstats.jpa.dao.GameDao/_entityManager. The server then tries find a persistence unit reference for this name. If there is only one persistence unit defined, this one will be used, otherwise the deployment descriptors are checked for configuration hints.

So in order to solve this problem, we have to provided these configuration hints. Adding the following few lines to the web.xml solves the problem:

<persistence-context-ref>
    <persistence-context-ref-name>de.icanmakeit.jpokerstats.jpa.dao.GameDao/_entityManager</persistence-context-ref-name>
    <persistence-unit-name>pokerstats_live</persistence-unit-name>
</persistence-context-ref>

This approach has one major drawback: if your software contains more than one @PersistenceContext injection target, you have to define a persistence-context-ref for each occurrence. This situation can be avoided by naming each @PersistenceContext annotation and giving them all the same name (note: the correct attribute is name, not unitName):

@PersistenceContext(name="pokerstats")
private EntityManager _entityManager;

All injection target with the same annotation name can now share a single persistence-context-ref (you can also use this name to look up the persistence unit using JNDI):

<persistence-context-ref>
    <persistence-context-ref-name>pokerstats</persistence-context-ref-name>
    <persistence-unit-name>pokerstats_live</persistence-unit-name>
</persistence-context-ref>

Update: Below you’ll find the relevant parts of the Spring configuration file for the example above. It defines two beans, the first one makes the datasource, that has been configured in the Glassfish Server, available for use in Spring. The second one defines the entity manager factory that Spring will use to support the JPA context.

<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName" value="jdbc/__pokerstats"/>
</bean>

<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
    <property name="dataSource" ref="dataSource"/>
    <property name="persistenceUnitName" value="pokerstats_live"/>
    <property name="loadTimeWeaver">
        <bean class="org.springframework.instrument.classloading.glassfish.GlassFishLoadTimeWeaver"/>
    </property>
    <property name="persistenceProvider">
        <bean class="oracle.toplink.essentials.PersistenceProvider"/>
    </property>
</bean>

Now that all persistence classes are ready, we are going to see if they work the way we want. As we are going to use Spring in the web application, we can also use it for the tests as well, because the Spring IoC container is suitable for standalone applications and provides easy to configure testing facilities.

(Some people have asked me to use the more… function in these articles, so I will try that here.)

Getting the sources

As always, you can either go the project website or checkout the associated tag from the source control system:

svn checkout http://jpokerstats.googlecode.com/svn/tags/tutorial_part_04

Changes that became necessary

While writing this part of the tutorial, I had to change some of the classes to work the way I wanted. The most important change is switching the temporal type startTime and endTime in the Game class from TemporalType.TIME to TemporalType.TIMESTAMP. The reason behind this is the fact, that times saved to the database and loaded again are no longer equal (in terms of equals()) to the times before the save. The times contained are identical, but something else isn’t, so I had to switch as timestamps compare correctly.

As I am also learning while writing this, it may happen from time to time that I need to revise the code from a previous part of the tutorial. I will inform you of these changes as I do now.

Configuring Spring

We need a configuration file to configure Spring persistence, so we’ll create one for testing purposes. Don’t be discouraged by all the declarations in there, I’m going to explain them later on.

<!--?xml version="1.0" encoding="UTF-8"?-->
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:p="http://www.springframework.org/schema/p"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx-2.5.xsd"&gt;

&nbsp;

&nbsp;

&nbsp;

&nbsp;

&nbsp;

FINE org.hsqldb.jdbcDriver jdbc:hsqldb:mem:jpokerstats_test sa oracle.toplink.essentials.platform.database.HSQLPlatform drop-and-create-tables

&nbsp;

You can read about all this configuration options in the excellent Spring reference handbook. It might actually help you to understand what happens here. For starters, I recommend reading chapter 3 and chapter 12.

First, the obvious part: I have declared a bean called entityManagerFactory and this will tell Spring how to configure itself to work with our persistent classes. This is also where we configure the database settings, although these are specific to the JPA implementation we are going to use. These options are simply passed through to Toplink.

Next I have defined a bean called transactionManager. Spring does not only manage our database connections, it also manages our transactions so that we don’t need to handle them ourselves or let the container handle them via JTA as not all containers provide container managed transactions. The Hint <tx:annotation-driven/> tells Spring that we will signal the use of transactions via annotations. This feature is pretty cool, you’ll see more of it in a later part.

The remaining two unnamed beans enable two other nice features. PersistenceAnnotationBeanPostProcessor is responsible for resolving any @PersistenceContext or @PersistenceUnit annotations within our application and inject an EntityManager or EntityManagerFactory instance, just like an EJB 3 container would do. The other class, PersistenceExceptionTranslationPostProcessor, will wrap any JPA specific exception with a corresponding Spring exception. As you may have read already, Spring supports many ORM providers, not just JPA. By wrapping the exceptions, your application only has to handle Spring exceptions while the underlying persistence layer can be freely exchanged.

Writing the test itself

The tests will use the Spring testing extension, a neat functionality that makes testing quite easy. I created a test case named SpringJpaTest that extends AbstractJPATests. This will cause Spring to initialize itself when the test is run and it provides a testing framework for JPA of which this test isn’t going to use much. To use all features provided by this superclass, we would have to configure a real persistence container with a DataSource and some load-time weaving. Sounds ugly? It is, at least for now, so we’ll stick to the simple things. The @ContextConfiguration tell Spring to load the configuration for this test class from a file in the same package named just like the class but suffixed the -context.xml. That’s why our configuration file is named SpringJpaTest-context.xml. To let Spring do it’s thing, we tell the class to run with the special SpringJUnit4ClassRunner.

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class SpringJpaTest extends AbstractJpaTests
{
@PersistenceContext
private EntityManager _manager;

// other stuff
// ...

}

The _manager field will be injected by Spring with an EntityManager just before the test is run. Each test method runs within it’s own transaction and the changed made to the database are rolled back when the method finishes. The method annotated with @Beforewill be called by JUnit once before each test method is run and we will use this mechanism to prepare the data to work with. Spring makes sure that the @Before-method runs in the same transaction as the actual test method.

I’m using HSQLDB for testing as well for the live application as it has a small footprint and is easy to configure. Toplink will create the necessary tables for us because we configured the toplink.ddl-generation option to drop-and-create-tables. This provides us with a clean database for each test cycle.

Pitfalls

The preparation of the data is pretty straightforward and contains no magic whatsoever. But there are some pitfalls I need to show you. German speaking readers might remember this article about bi-directional relationships in JPA. We face the same problem here: a game references 0 or more game results and each of this game results references the game. For this to work and foremost for this to be saved to the database, we need to make both of these assignments (only an excerpt of the code is shown):

_game = new Game();
final GameResult result1 = new GameResult();

// assignment result -> game
result1.setGame(_game);

// assignment game -> result
_game.addResult(result1);

I’ve seen people struggle with this and finally, they came up with the great idea that when one of this assignments is made, the other assignment is triggered and made automatically. So they fitted both method (in this case setGame() and addResult()) with some clever code like this:

public void setGame(final Game game)
{
if (null != game)
game.addResult(this);
_game = game;
}

public void addResult(final GameResult result)
{
if (null != result)
result.setGame(this);
_results.add(result)
}

As you may easily see, this code will result in an infinite loop. I’ve tried to devise some collisionfree adaptation of this, but there is no clean way to do this within the entity classes themselves. In later development steps, we will use helper classes to do this work for us.

The next problem I came across was Toplink’s caching mechanism. The test works as follows: it creates some data objects, saves them to the database, loads them again and checks if they have been saved correctly. Unfortunately (at least for the testing) Toplink caches the objects currently attached to the EntityManager. If they get selected again (as they get in the test), the database itself is not queried and the results are delivered from the cache. To be able to test if really something was written to the database, we need to call _manager.flush() to make Toplink actually save to the database and then _manager.clear() to detach all entities saved so far.

The last pitfall: the test method itself has to be annotated with @Transactional or it will not participate in the same transaction used for createTestData(). As transactions are not commited by default, the database would be empty again by the time the test is run.

What’s next?

As this tutorial is about developing web applications, the next part finally deal with some web technology called Facelets, the templating framework for JSF. So stay tuned!

In the last part of the tutorial, we spent some time with the basic setup of the project and wrote our first classes that we’re going to use as JPA entities. You might recall the simple entity/relationship diagram from the last part that showed how these classes, that JPA will map to database tables for us, are related to each other. Let’s recap:

• A game can have many results
• A result belongs to exactly one game and to exactly one player
• A player can have many results

The GameResult class is what actually binds games and players together. The player that participated in a game can easily be determined by checking the results of the game, as each of these is associated with a player. This relationship can be used the other way round to check in which games a player participated. So now it’s time to tell JPA about the relationships.

Getting the sources

As always, you can either go the project website or checkout the associated tag from the source control system:

svn checkout http://jpokerstats.googlecode.com/svn/tags/tutorial_part_03

Establishing relationships

First, we add two new field together with getters and setters to the GameResult class. One of it holds an instance of Game, the other an instance of Player, so the the result can tell us to which game and to which player it belongs. In more technical terms, GameResult has a many-to-one relationship with Game and Player. The way JPA is designed, this forces us to declare GameResult the owner of the relationship. This can be done by annotating the appropriate getters with @ManyToOne. The target entity classes will be resolved by JPA automatically by evaluating the field type.

private Player _player;

private Game _game;

@ManyToOne
public Player getPlayer()
{
return _player;
}

public void setPlayer(final Player player)
{
_player = player;
}

@ManyToOne
public Game getGame()
{
return _game;
}

public void setGame(final Game game)
{
_game = game;
}

As we have many-to-one relationships, both Player and Game must declare a collection of GameResult objects. In each of these classes, we introduce a field of type Set<GameResult> and add getters and setters for it. As you are free to name your methods as you like, we need to give JPA a hint on how to connect the relationships. So we annotate the getters with @OneToMany and specify the mappedBy attribute. This is a string that tells JPA which property on the related class is the counterpart for this relationship.

private Set_results;

@OneToMany(mappedBy="game")
public Set getResults()
{
return _results;
}

public void setResults(Setresults)
{
_results = results;
}

Why using the mappedBy attribute?

Using the mappedBy attribute may seem unecessary at first glance but think about a situation where you have entities A and B. A is a person record and B a transaction record. B references two person records at once, e.g. in a buyer/seller situation. Now B suddenly has two fields of type A and JPA cannot determine, which belongs to which relationship. You can solve the situation by using the mappedBy attribute to make the relationships unique again.

Why using sets instead of lists?

Reading a tutorial like this I’d assume you know why, but let me tell you. There is only a single logical difference between a list and a set: a list has an order whereas a set has not. But this simple logical difference is a big technical one: append, insert and remove operations on list cause far more overhead than they do on sets, so sets are a lot faster. In this example, we also do not need the order of elements in the sets as we will re-sort them according to the users preferences in the web frontend later on. If you do not believe me, you could write you own test program. Although I have to say that the increase in performance by using sets instead of lists will be eaten up by the “black magic” that Spring, Facelets and all the others use to get the application working. I guess, everything comes at a price, but that’s fine with me. If it were otherwise, I would write everything myself like most C people do.

Saving us trouble

The are a lot of things to stumble or even fall over when working with JPA. In order to avoid mistakes right from the start, I need to explain some things and add some extra code.

First of all, we’ll not be working with whole sets of objects at once, so we add extra methods to work with single objects at a time:

public void addResult(final GameResult result)
{
_results.add(result);
}

public void removeResult(final GameResult result)
{
_results.remove(result);
}

You might have noticed another problem. What if the set is not initialized? To avoid countless NPEs, we add a constructor to Game and Player and make sure the set gets initialized.

public Game()
{
_results = new HashSet();
}

One big source of errors when working with JPA revolves around object identity. The question here is: Under what conditions are two objects treated as equal? Let’s assume you create 5 Player instances, set the names to John Doe and add them to a set. You end up with 5 John Does in a set. This is not what we want, we want only one John Doe in the set. This gets even worse if you load the same record from the database twice. Although it is the same record, the objects will no be treated as such. If one is already in a list and you ask Java: “Hey, is there a John Doe in there?” and use the other object, Java will respond: “No!”. This will get you into serious trouble and from my experience, 80% of all problems in the persistence layer of a project are caused by identity problems. To fully understand the seriousness of identity problems, consider the US no-fly lists.

There is a book called Effective Java: Language Programming Guide. It is quite old now, but its contents remain valid even today. I recommend reading chapter 8: Always override hashCode() when you override equals(), it describes a solution to our problem. For further reading please refer to the articles on equals() (1, 2) by Angelika Langer and Klaus Kreft. Readers capable of reading German can read the articles in German: 1, 2, 3.

After reading this, we’ll implement the equals() and hashCode() methods for all entity objects. It is important not to include the dataset id in the hash, as it is not part of the semantic content of a record. Most likely you IDE can generate those methods for you. Below is an example for the Game class:

@Override
public int hashCode()
{
final int offset = 11;
final int multiplier = 37;
int hashCode = offset;

// long values will be split into two integers
hashCode += (int)(_buyinChips>>>32) * multiplier;
hashCode += (int)(_buyinChips & 0xFFFFFFFF) * multiplier;
hashCode += (int)(_buyinCosts>>>32) * multiplier;
hashCode += (int)(_buyinCosts & 0xFFFFFFFF) * multiplier;
hashCode += (int)(_rebuyChips>>>32) * multiplier;
hashCode += (int)(_rebuyChips & 0xFFFFFFFF) * multiplier;
hashCode += (int)(_rebuyCosts>>>32) * multiplier;
hashCode += (int)(_rebuyCosts & 0xFFFFFFFF) * multiplier;

// reference values have to be null-tested
if (null != _date) hashCode += _date.hashCode() * multiplier;
if (null != _startTime) hashCode += _startTime.hashCode() * multiplier;
if (null != _endTime) hashCode += _endTime.hashCode() * multiplier;
if (null != _gameType) hashCode += _gameType.hashCode() * multiplier;

return hashCode;
}

@Override
public boolean equals(final Object other)
{
if (null == other || !(getClass().equals(other.getClass())))
return false;

final Game otherGame = (Game) other;

if (null == _date)
if (null != otherGame.getDate())
return false;

if (null == _endTime)
if (null != otherGame.getEndTime())
return false;

if (null == _startTime)
if (null != otherGame.getStartTime())
return false;

if (null == _gameType)
if (null != otherGame.getGameType())
return false;

// we start off assuming the objects are equal and use AND
// operations for the comparisons
boolean equals = true;
equals &= getBuyinChips() == otherGame.getBuyinChips();
equals &= getBuyinCosts() == otherGame.getBuyinCosts();
equals &= getRebuyChips() == otherGame.getRebuyChips();
equals &= getRebuyCosts() == otherGame.getRebuyCosts();

if (null != getDate())
equals &= getDate().equals(otherGame.getDate());

if (null != getStartTime())
equals &= getStartTime().equals(otherGame.getStartTime());

if (null != getEndTime())
equals &= getEndTime().equals(otherGame.getEndTime());

if (null != getGameType())
equals &= getGameType().equals(otherGame.getGameType());

return equals;
}

I added some unit tests to make sure that these methods actually work and that the contract for equals() and hashCode() is not violated.

What’s next?

The next part of this tutorial will deal with even more testing. Now that hashCode() and equals() are implemented, it’s time to see if our model works when used in a real database. We will create some basic tests using HSQLDB and let Spring do the configuration work for us.

Welcome to part two of my tutorial for developing lightweight Java web applications! I meanwhile created an online code repository for the source files yo that you may refer to them more easily. You can either visit the project site or you can checkout the source files representing this part of the tutorial by using Subversion and calling the following command:

svn checkout http://jpokerstats.googlecode.com/svn/tags/tutorial_part_02

I have always been the hands-on guy, and I’ve always disliked documentations and tutorials that explain aspect of something without a surrounding context So in this tutorial, I’m going to explain the aspects of lightweight Java web applications by using a complete example application that actually does something.

During this tutorial, I will often skip man explanations of the source code itself, pointing out only the interesting and challenging parts. To get the whole picture, please refer to the source code repository.

Introducing JPokerStats

The application that is going to be developed is simply called JPokerStats. I play a lot of poker and I use a self-written Ruby on Rails application to track the games I’ve played with my friends. Basically what I’m doing now is rewriting the software in Java.
The database model behind JPokerStats is made up of three tables that will store all necessary data:

This tutorial assumes that you are already familiar with object-relational-mapping technologies or at least the concept behind it.

Setting up the project

We start off with the application by creating a skeleton using the Maven archetype plugin. We can achieve this by executing:

mvn archetype:create -DgroupId=de.icanmakeit.jpokerstats -DartifactId=jpokerstats -Dversion=0.1-SNAPSHOT -DarchetypeArtifactId=maven-archetype-webapp

This will create some basic files for us such as the Maven project description (pom.xml), the necessary directory structures and the web specific files such as the web.xml which we are going to modify instantly by replacing the 2.3 header declaration with a 2.4 declaration. You might object and say that version 2.5 web applications are currently state of the art. You’re right on this but we’ll leave the version set to 2.4 for now and I will explain why in a later part of this tutorial.

Dependencies

Next we’re going to define the projects dependencies. It already has a dependency on JUnit that we upgrade from version 3.8.1 to version 4.4 to be able to use annotations for our tests.
As the title of this tutorial states, we are going to use a lot of external libraries as can be seen in the following list:

• JSF API/RI 1.2_07
• Facelets 1.1.14
• JPA 1.0
• Spring Framework 2.5.1
• Apache Shale 1.1.0-SNAPSHOT

We will be adding the needed artifacts to the pom.xml. Notice that I have declared some properties containing various version numbers for libraries. Most of them consist of more than one artifact, so referencing a single version property make it easier to upgrade them at a later time. Some artifacts are not available in the central repository and need to be downloaded from other repositories. I have included those in the pom.xml, but after adding dependencies you should run mvn compile to check if they are all available.
Some artifact scopes are defined as provided. This means that Maven supplies those libraries at compile time but does not include them in a software release file (in this case the web archive or WAR), assuming that the servlet container or application server will provide them. If your server does not include those libraries (e.g. Tomcat doesn’t) you might want to change the scope from provided to compile.

The first Java code

To finish off this part of the tutorial, we’re finally going to write some Java code for the JPA layer of our project. So I create three classes, Game, Player and GameResult an put some attributes in them. As JPA objects are simple Java beans or POJOs, this step is quite easy. To simply the work with attributes such as gender or gameType, we define some enumerations to help us with these values.
After writing the Java classes, we need to instrument them for use with JPA. This tutorial is going to use HSQLDB for data storage because it can be run out of the box and needs no additional setup. But since we are using JPA you could use any other supported database such as MySQL, postgreSQL or Oracle.

The primary key is going to be generated and we leave the decision on how to do this to JPA. The JPA implementation will use the method it thinks is most suitable for the database used.

@Id
@GeneratedValue(strategy = GenerationType.AUTO)
public int getId()
{
return _id;
}

JPA is able to translate enumerations to database value either by saving the values position (e.g. 2) within the enumeration or by saving the value itself as string (e.g. MALE). I prefer the latter method because it makes the database easier to read and those few extra bytes do not actually matter (at least to me). So we’re going to specify this behavior on the getter for gender.

@Enumerated(EnumType.STRING)
public Gender getGender()
{
return _gender;
}

We’ll use the same way of annotating fields for the other classes as well. In addition, JPA requires us the specify how to store temporal values such as the date on which a game took place. We choose DATE for real date values where the time doesn’t matter and choose TIME when we want only the times saved. In case we needed date and time saved together, we would specify TIMESTAMP.

@Temporal(value=TemporalType.DATE)
public Date getDate()
{
return _date;
}

@Temporal(value=TemporalType.TIME)
public Date getStartTime()
{
return _startTime;
}

By this, we are done for this part of the tutorial. In the next part, we will introduce JPA based relationships between the entities and configure the database and Spring for our application.

What is this all about? (Motivation)

If you’ve ever dug deeper into developing web applications with JSF or have developed Java web applications in the past using other frameworks and libraries, e.g. Turbine, Velocity, Struts, etc., you will soon find that JSF itself has a a nice concept but provides only the most basic functionality.

In JSF itself you have a strict seperation of concerns and a nicely split MVC architecture, but for a fully fledged application that uses persistent data, pluggable components and a templating system, JSF on its own just isn’t enough.

You could now start creating a new Java 5 EE application, building several components (JPA, EJB, etc.), bundle them into an EAR file and deploy them to the Glassfish application server. But we won’t. Don’t misunderstand me: there’s nothing wrong with writing a full Java Enterprise application and I salute to those who do, but for most developers such a setup is just overkill (whereas a simple Servlet is not enough). But this series is about lightweight applications. Please note that “weight“ is not measured in bytes but in the amount of stuff you have to write to get things done.

This series describes a different approach to Java web applications and is inspired by the facesgoodies project developed by Matthias Wessendorf. This project is a kickstart project for developing JSF applications including Spring and Shale using the JPA persistence layer. Unfortunately it is not document very well and somewhat hard to understand for those who have never used Spring or configured a more complex web application or a persistence unit.

This series/tutorial is designed to help you design next generation web applications using modern, community supported technologies.

Take a look around (The libraries used)

Java Server Faces (JSF)

Since you need at least a basic understanding of JSF in order to understand this tutorial I will not go into further details when describing JSF. Let’s just say that Java Server Faces is the recommendable technology for developing web applications with Java. You can read more about JSF by reading the official documentation.

Facelets

Facelets is a templating library for use with JSF. All pages are written in pure XHTML by utilising the XML namespace features to add additional JSF or JSP libraries. Basically you define a couple of named placeholders in your template file(s) and fill them later on with page specific content. Facelets offers a simple API with not more than ten tags for use in your templates and pages. And believe it or not, you usually don’t need more than four of them. You can read more on Facelets by visiting the official project site, reading the documentation or the Inside JSF article series over at JSF Central.

Java Persistence API (JPA)

JPA is a standardized API specification for Java persistence. It allows you to create simple POJO beans and map them to the database of your choice by adding some simple annotations. Since JPA is only a specification, we will also need a library that implements this specification. You may choose from several implementation, the two most popular are Hibernate and Toplink. This tutorial will use Toplink Essentials, the library that comes bundled with the Glassfish application server.

Spring

Spring is a fully fledged, modular Java Enterprise framework. What does that mean? In this tutorial we will not use all modules offered by Spring. We will use the IoC container to reduce the applications complexity when it comes to configuring objects and services. It will also help us to design decoupled components that can be switched later against other implementations, giving us a more flexible design.

We want our application to run on simple Servlet containers such as Jetty or Tomcat, therefor we cannot let the application server manage our database connections and transactions. This functionality will instead be provided by the Spring DAO and the Spring Transaction module.

Spring is – contrary to many other open source projects – very well documented. You might consider reading the developer manual or at least parts of it.

Apache Shale

Shale is a set of modules that are built around the basic JSF implementation and enhance it by various features. For the beginning, we will only use Shale Core and Shale Views. Views provides the application with a real controller layer in accordance with the MVC principle, replacing the JSF “glue objects“ proposed by many JSF tutorials.

Maven 2

In order to reduce the hassle of managing the classpath, dependencies, directories and other aspects of Java software development, this project will be built using Maven 2. You might consider making yourself familiar the way Maven works by reading the getting started documentation.

Manchmal gibt es aber auch Codeteile, die von vorneherein sehr merkwürdig sind:

final Date heute = new SimpleDateFormat("HH:mm dd.MM.yyyy").parse(new
SimpleDateFormat("HH:mm dd.MM.yyyy").format(new Date()));

Es ginge auch etwas einfacher:

final Date heute = new Date();

Solche Dinge will man dann doch lieber nie wieder sehen…

Der Artikel handelt in diesem Fall speziell von Java, dass durch seine Abstraktion von den eigentlichen Systemgrundlagen eine zusätzliche Hürde mit einbringt, die vorgestellten Thesen und Lösungsansätze sind allerdings allgemeingültig.
O’Brien sieht den Grund für die Konflikte in einer zu starren Abgrenzung zwischen den beiden Personengruppen, deren Tätigkeit thematisch überlappt, deren Zuständigkeiten aber hart getrennt sind. Er skizziert eine ideale Verfahrensweise und und stellt einen zweistufigen Plan vor, wie man die Reibung zwischen Administration und Entwicklung verringert.

The Short-term Solution: Hold Hands and Sing a Song

If your organization has friction between Operations and Development, a quick short-term fix is to nominate one person from each team to serve as a liaison to the other group.

Diesen Schritt haben wir in unserer Firma bereits vollzogen und es hat sich als sehr gut heraus gestellt, eine direkte Schnittstelle zur anderen Abteilung zu haben. Probleme aber auch Anforderungen sind so viel einfacher zu klären.

The Long-term Solution: Stop Developing Applications, Stop Administering Systems

…do away with System Administrators and Application Developers. No, really, I mean that.

Der Ausschnitt selber klingt recht drastisch, er beschreibt aber eine thematische Annäherung von Administratoren und Entwicklern und den Wandel der klassischen Rollen im Verlauf der Zeit und im Zuge der technischen Entwicklung.

Insgesamt ein sehr lesenswerter Artikel, den ich jedem Administrator und jedem Entwickler nur empfehlen kann.

I doubt that it’s a matter of it being “unpredictable” so much as it is getting over the learning curve.

Genau in dieser Lernkurve stecke ich auch derzeit noch und erlerne JPA gerade im Eigenstudium. Für erfahrene Entwickler ist dieser Beitrag daher nicht gedacht.

Das Problem

Es existieren zwei Entitäten, Benutzer und Gruppe. Jeder Benutzer kann einer Gruppe angehören, folglich können zu einer Gruppe mehrere Benutzer gehören. Beide Entitäten sind wie folgt definiert:

@Entity
public class Benutzer
{
    private String _name;
    private String _vorname;
    private String _benutzername;
    private String _email;
    private int _id;
    private Gruppe _gruppe;

    /*
     * Es folgen die ganze Getter und Setter fuer die
     * obigen Eigenschaften.
     * [...]
     */
    
    @ManyToOne
    public Gruppe getGruppe()
    {
        return _gruppe;
    }

    public void setGruppe(final Gruppe gruppe)
    {
        _gruppe = gruppe;
    }
}

@Entity
public class Gruppe
{
    private int _id;
    private String _name;
    private String _beschreibung;
    private Set<Benutzer> _benutzer = new HashSet<Benutzer>();
            
    /*
     * Es folgen die ganze Getter und Setter fuer die
     * obigen Eigenschaften.
     * [...]
     */            
            
    @OneToMany(mappedBy = "gruppe")
    public Set<Benutzer> getBenutzer()
    {
        return _benutzer;
    }

    public void setBenutzer(final Set<Benutzer> benutzer)
    {
        _benutzer = benutzer;
    }
}

Ein kleines Programm geht jetzt her und erzeugt drei Benutzer und zwei Gruppen. Zwei der Benutzer werden der ersten Gruppe zugewiesen, der dritte der anderen Gruppe.

EntityManager em = createEntityManager();

        final Gruppe g1 = createGruppe("Demokraten", "Die Partei der Demokraten");
        final Gruppe g2 = createGruppe("Republikaner", "Die Partei der Republikaner");

        em.persist(g1);
        em.persist(g2);
        
        final Benutzer b1 = createBenutzer("Obama", "Barack", "bobama", "obama@senate.gov");
        final Benutzer b2 = createBenutzer("McCain", "John", "jmccain", "mccain@senate.gov");
        final Benutzer b3 = createBenutzer("Clinton", "Hillary", "hclinton", "clinton@senate.gov");

        b1.setGruppe(g1);
        b2.setGruppe(g2);
        b3.setGruppe(g1);

        em.persist(b1);
        em.persist(b2);
        em.persist(b3);

Danach geht das Programm her und lädt die Datensätze wieder aus der Datenbank und gibt sie und ihre Beziehungen aus.

final List result = em.createQuery("SELECT b FROM Benutzer b ORDER BY b.name").getResultList();
        
        for (final Object b : result)
        {
            if (b instanceof Benutzer)
            {
                final Benutzer benutzer = (Benutzer) b;
                LOG.info(benutzer);
                LOG.info("\t+--> " + benutzer.getGruppe());
            }
        }

        final List result2 = em.createQuery("SELECT g FROM Gruppe g").getResultList();
        
        for (final Object o : result2)
        {
            if (o instanceof Gruppe)
            {
                final Gruppe g = (Gruppe) o;
                LOG.info(g);
                LOG.info("Benutzerzahl: " + g.getBenutzer().size());

                for(final Benutzer b : g.getBenutzer())
                {
                    LOG.info("\t+--> " + b);
                }
            }
        }

Es entsteht folgende Ausgabe:

JPAClient.showDemo()@107: Benutzer [2902]: Clinton, Hillary (hclinton, clinton@senate.gov)
JPAClient.showDemo()@108: 	+--> Gruppe [2800]: Demokraten (Die Partei der Demokraten)
JPAClient.showDemo()@107: Benutzer [2901]: McCain, John (jmccain, mccain@senate.gov)
JPAClient.showDemo()@108: 	+--> Gruppe [2801]: Republikaner (Die Partei der Republikaner)
JPAClient.showDemo()@107: Benutzer [2900]: Obama, Barack (bobama, obama@senate.gov)
JPAClient.showDemo()@108: 	+--> Gruppe [2800]: Demokraten (Die Partei der Demokraten)
JPAClient.showDemo()@120: Gruppe [2800]: Demokraten (Die Partei der Demokraten)
JPAClient.showDemo()@121: Benutzerzahl: 0
JPAClient.showDemo()@120: Gruppe [2801]: Republikaner (Die Partei der Republikaner)
JPAClient.showDemo()@121: Benutzerzahl: 0

Das Problem ist offensichtlich: Während jeder Benutzer eine Referenz auf das ihm zugeordnete Gruppenobjekt hält, kennt keine der Gruppen die Benutzer, die ihr zugeordnet sind.

Die Lösung

Bidirektionale Beziehungen sollten eigentlich anders funktionieren. Das oben geschilderte Problem ist das, was auch vielen anderen wegen seiner Struktur Probleme bereitet. Die Beziehung funktioniert beidseitig und solange der gleiche EntityManager läuft, können Objekte vom JPA-Provider zwischengespeichert werden. Daher reicht ein einseitiges Zuweisen nicht aus, vielmehr muss in diesem Fall auch der Gruppe der Benutzer zugewiesen werden. Erst dann sind die zwischengespeicherten Objekte vollständig.

EntityManager em = createEntityManager();

        final Gruppe g1 = createGruppe("Demokraten", "Die Partei der Demokraten");
        final Gruppe g2 = createGruppe("Republikaner", "Die Partei der Republikaner");

        final Benutzer b1 = createBenutzer("Obama", "Barack", "bobama", "obama@senate.gov");
        final Benutzer b2 = createBenutzer("McCain", "John", "jmccain", "mccain@senate.gov");
        final Benutzer b3 = createBenutzer("Clinton", "Hillary", "hclinton", "clinton@senate.gov");

        b1.setGruppe(g1);
        b2.setGruppe(g2);
        b3.setGruppe(g1);
        
        g1.getBenutzer().add(b1);
        g2.getBenutzer().add(b2);
        g1.getBenutzer().add(b3)

        em.persist(b1);
        em.persist(b2);
        em.persist(b3);
        
        em.persist(g1);
        em.persist(g2);

Folgende Ausgabe zeigt das Ergebnis der Änderung:

JPAClient.showDemo()@107: Benutzer [2952]: Clinton, Hillary (hclinton, clinton@senate.gov)
JPAClient.showDemo()@108: 	+--> Gruppe [2850]: Demokraten (Die Partei der Demokraten)
JPAClient.showDemo()@107: Benutzer [2951]: McCain, John (jmccain, mccain@senate.gov)
JPAClient.showDemo()@108: 	+--> Gruppe [2851]: Republikaner (Die Partei der Republikaner)
JPAClient.showDemo()@107: Benutzer [2950]: Obama, Barack (bobama, obama@senate.gov)
JPAClient.showDemo()@108: 	+--> Gruppe [2850]: Demokraten (Die Partei der Demokraten)
JPAClient.showDemo()@112: Lade Gruppen
JPAClient.showDemo()@120: Gruppe [2850]: Demokraten (Die Partei der Demokraten)
JPAClient.showDemo()@121: Benutzerzahl: 2
JPAClient.showDemo()@126: 	+--> Benutzer [2952]: Clinton, Hillary (hclinton, clinton@senate.gov)
JPAClient.showDemo()@126: 	+--> Benutzer [2950]: Obama, Barack (bobama, obama@senate.gov)
JPAClient.showDemo()@120: Gruppe [2851]: Republikaner (Die Partei der Republikaner)
JPAClient.showDemo()@121: Benutzerzahl: 1
JPAClient.showDemo()@126: 	+--> Benutzer [2951]: McCain, John (jmccain, mccain@senate.gov)

Diese Art der Zuweisung im Code eines Client-Programms ist natürlich etwas unschön, sinnvoller wäre es, diese Zuweisung gleich im entsprechenden Setter der Benutzerklasse zu machen.

public void setGruppe(final Gruppe gruppe)
    {
        _gruppe = gruppe;
        if (null != _gruppe.getBenutzer() && !_gruppe.getBenutzer().contains(this))
        {
            _gruppe.getBenutzer().add(this);
        }
    }

Das Problem erübrigt sich auch, wenn man einen anderen EntityManager verwendet als den, der die Objekte persistiert hat.

Bedingt durch meine Arbeit habe ich kürzlich an einer Java Enterprise Schulung teilgenommen und dort einiges neues gelernt. Der erste Teil der Schulung drehte sich um das Thema Enterprise Java Bean (EJB) 3.0. Ich spare mir jetzt mal die Erläuterungen, worum es geht, was man damit tut, usw., denn dieser Beitrag beschäftigt sich vorrangig mit den kleinen Hürden des Alltags.

Die Aufgabe: Es geht um die vermeintliche einfache Frage, wie man eine simple Bean implementiert, die Abfragen auf eine Datenbank macht und wie man diese Bean von einem Remote-Client aus anspricht. Das war die Aufgabe, die ich mir gestellt hatte, zusammen mit der Aufgabe, diese Software sowohl auf dem Glassfish als auch auf dem JBoss zum Laufen zu bringen.

Entwicklung der Bean

Vom Prinzip her ist dies der einfachste Teil. Hat man später erstmal die Hürden mit den Application Servern genommen, sollte EJB-Entwicklung eigentlich einfach bleiben, zumindest was den eigentlichen Bean-Teil angeht. Entwickelt werden soll eine Stateless SessionBean, die einige unterschiedliche Methoden hat, um Datenbankabfragen zu machen und die Ergebnisse teils als primitiven Typ, teil als Objekt zurück zu geben. Die Bean verwendet eine vom Bean Container bereitgestellte DataSource für den Zugriff auf die Datenbank. Diese DataSource wird per Injection in die Bean geholt.

Remote Business Interface

package de.icanmakeit.blog.ejb3.client;

import de.icanmakeit.blog.ejb3.model.StatistikData;
import javax.ejb.Remote;
import java.util.Date;

@Remote
public interface StatistikDemo
{
    int getUserCount();
    Date getLastLogin(String username);
    StatistikData getDatasetCount();
}

Das Business Interface ist einfach gehalten. Um später von einem entfernten Client darauf zuzugreifen, ist die Annotation @Remote notwendig. Die Klasse StatistikData ist eine POJO-Bean (im Sinne von Java Bean, nicht im Sinne von Enterprise Bean) mit passenden Gettern und Settern. Sie sei hier mal außer Acht gelassen, da sie keine Logik oder spezielle Elemente enthält. Die Klasse implementiert allerdings das Interface Serializable, sonst wäre sie als Datentyp für den entfernten Datenaustausch nicht nutzbar.

Das Business Interface wird von der jeweiligen zuständigen Bean implementiert und dient auch später auf dem Client als Schnittstelle zur Bean.

Die Stateless SessionBean

Folgender Code spiegelt die eigentliche Bean wider. Die Logik, die zur Ermittlung der einzelnen Rückgabewerte führt, habe ich der Übersicht halber weggelassen, da sie für das Verständnis der Bean nicht wichtig ist.

package de.icanmakeit.blog.ejb3.server;

import de.icanmakeit.blog.ejb3.client.StatistikDemo;
import de.icanmakeit.blog.ejb3.model.StatistikData;
import javax.ejb.Stateless;
import javax.sql.DataSource;
import javax.annotation.Resource;
import java.util.Date;

@Stateless(name = "StatistikDemoEJB", mappedName = "StatistikDemoEJB-MappedName")
public class StatistikDemoBean implements StatistikDemo
{
    private DataSource _dataSource;

    @Resource(name = "", mappedName = "", type = DataSource.class)
    public void setDataSource(final DataSource ds)
    {
        this._dataSource = ds;
    }

    public StatistikDemoBean()
    {
    }

    public int getUserCount()
    {
        final int userCount;
        // Ergebnis bestimmen
        // ...
        return userCount;
    }

    public Date getLastLogin(final String username)
    {
        final Date lastLogin;
        // Ergebnis bestimmen
        // ...
        return lastLogin;
    }

    public StatistikData getDatasetCount()
    {
        final StatistikData result;
        // Ergebnis bestimmen
        // ...
        return result;
    }
}

Die Annotation @Stateless signalisiert, dass es sich um eine Stateless SessionBean handelt, die einen Namen und einen MappedName hat. Je nach Application Server wird der eine oder der andere für den späteren Lookup benötigt.

Über die @Resource Annotation wird der Container angewiesen, eine Instanz vom angegebenen Typ durch einen Lookup über den angegebenen Namen oder MappedName zu bestimmen und der Methode als Parameter mit zu geben. Dies geschieht, bevor ein Client irgendeine der definierten Methoden aufruft. Welche Angaben für name und mappedName eingetragen werden müssen, hängt vom jeweiligen Server ab, auf dem die Bean später läuft. Beispiele für JBoss und Glassfish folgen weiter unten.
Die @Resource Annotation könnte auch direkt an der Variable stehen, der Setter könnte dann wegfallen. Allerdings widerspricht das meinem Verständnis von Kapselung, außerdem ist der Getter für einen späteren Test ohne Container notwendig. Es bleibt aber festzuhalten, dass

private DataSource _dataSource;

@Resource(name = "", mappedName = "", type = DataSource.class)
public void setDataSource(final DataSource ds)
{
    this._dataSource = ds;
}

und

@Resource(name = "", mappedName = "", type = DataSource.class)
private DataSource _dataSource;

den gleichen Effekt haben im EJB 3 Container.

EJB-Descriptor ejb-jar.xml

EJB 3 lässt dem Entwickler die Wahl, alle wichtigen Einstellungen der Beans auch in einer XML-Datei namens ejb-jar.xml zu definieren. Diese kann zusätzlich zu oder anstelle der Annotations in der Java-Klasse verwendet werden. Im fertigen JAR für das Deployment der EJB ist diese Datei im Verzeichnis META-INF unter zu bringen.
Eine entsprechende Datei für die oben definierte Bean sähe aus wie folgt.

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
		  http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
         version="3.0">
    <enterprise-beans>
        <session>
            <ejb-name>StatistikDemoEJB</ejb-name>
            <ejb-class>de.icanmakeit.blog.ejb3.server.StatistikDemoBean</ejb-class>
            <session-type>Stateless</session-type>
            <transaction-type>Container</transaction-type>
            <resource-ref>
                <res-ref-name><!-- JNDI-Name --></res-ref-name>
                <res-type>javax.sql.DataSource</res-type>
                <injection-target>
                    <injection-target-class>de.icanmakeit.blog.ejb3.server.StatistikDemoBean</injection-target-class>
                    <injection-target-name>setDataSource</injection-target-name>
                </injection-target>
            </resource-ref>
        </session>
    </enterprise-beans>
</ejb-jar>

Aufruf im Remote-Client

Grundsätzlich funktioniert folgender Quellcode für jeden Remote-Lookup einer Bean. Allerdings gibt es Unterschiede in Abhängigkeit davon, auf was für einem Server die Bean läuft. Diese Unterschiede machen sich in zwei Punkten bemerkbar:

• Für die Erzeugung eines InitialContext-Objektes mit dem parameterlosen Konstruktor wird eine Datei jndi.properties im Klassenpfad benötigt, die festlegt, welche Factory den Context mit welcher URL erzeugen soll. Der Inhalt dieser Datei ist server-spezifisch. Details zur Konfiguration folgen in den konkreten Beispielen weiter unten.
• Der JNDI-Name der zu verwendenden Bean variiert ebenfalls je nach Server.

Folgender Code verdeutlich aber den grundlegenden Ablauf:

package de.icanmakeit.blog.ejb.clientapp;

import de.icanmakeit.blog.ejb.client.StatistikDemo;
import de.icanmakeit.blog.ejb.model.StatistikData;
import java.util.Date;
import javax.naming.InitialContext;
import javax.naming.NamingException;

public class EJBClient
{
    public static void main(final String[] args) throws NamingException
    {
        final InitialContext ic = new InitialContext();
        final StatistikDemo stat = (StatistikDemo) ic.lookup("...");
        System.out.println("Anzahl Benutzer: " + stat.getUserCount());
        final StatistikData data = stat.getDatasetCount();
        System.out.println("Anzahl Datensätze: " + data.getOverallCount() + ", davon " + data.getOutdatedCount() + " nicht akutell.");
        System.out.println("Letzer Login des Benutzers 'test': " + stat.getLastLogin("test"));
    }
}

Deployment im Glassfish

Glassfish ist der OpenSource Application Server, den Sun für sich als Sun Application Server 9 verwendet. Er bietet ein komfortables Frontend zur Konfiguration vieler Einstellungen, unter anderem auch für Datenbankverbindungen.

Datenbank-Verbindung einrichten

Zunächst muss ein Datenbankpool eingerichtet werden. Dies kann man unter Resources > JDBC > Connection Pools tun. Die Einrichtung sollte selbsterklärend sein. Bitte beachten, dass der Datenbanktreiber dem Server noch im entsprechenden lib-Verzeichnis zugänglich gemacht werden muss. Nachdem der Pool eingerichtet wurde, kann mit ihm eine JDBC-Ressource für den Container bereit gestellt werden. Dies geht im Menüpunkt Resources > JDBC > JDBC Resources und ist ähnlich einfach. Diese Einstellungen fügen Zeilen wie die folgenden in die Datei domain.xml im Verzeichnis domains/config/ein:

<domain>
    ...
    <resources>
        ...
        <jdbc-resource enabled="true" jndi-name="jdbc/__testdb" object-type="user" pool-name="TestMySQLPool"/>
        ...
        <jdbc-connection-pool 
                allow-non-component-callers="false" 
                connection-validation-method="auto-commit" 
                datasource-classname="com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource"
                fail-all-connections="false" 
                idle-timeout-in-seconds="300" 
                is-connection-validation-required="true" 
                is-isolation-level-guaranteed="false" 
                max-pool-size="4" 
                max-wait-time-in-millis="60000" 
                name="TestMySQLPool" 
                non-transactional-connections="false" 
                pool-resize-quantity="2" 
                res-type="javax.sql.ConnectionPoolDataSource" 
                steady-pool-size="1">
            <description>Testverbindungspool</description>
            <property name="user" value="username"/>
            <property name="port" value="3306"/>
            <property name="password" value="secret"/>
            <property name="databaseName" value="test_db"/>
            <property name="serverName" value="myserver.local.net"/>
        </jdbc-connection-pool>
        ...
    </resources>
    ...
</domain>

Bean anpassen & deployen

Da die DataSource jetzt konfiguriert ist, kann ein entsprechender Name in die @Resource Annotation der Bean eingetragen werden. Für den Glassfish sieht dieser dann aus wie folgt:

@Resource(name = "jdbc/__testdb", type = DataSource.class)
public void setDataSource(final DataSource ds)
{
    this._dataSource = ds;
}

Diese Regelungen gelten analog für Einträge in die ejb-jar.xml. Das Deployment der Bean kann nun über die Administrationswebseite erfolgen.

Client anpassen und starten

Um eine Bean auf dem Glassfish Server anzusprechen, muss auf dem Client ihr mapped name verwendet werden. Der Client wird also wie folgt angepasst:

final InitialContext ic = new InitialContext();
final StatistikDemo stat = (StatistikDemo) ic.lookup("StatistikDemoEJB-MappedName");

Der Client läuft nur mit server-spezifischen Klassen im Klassenpfad, es muss die JAR-Datei appserv-rt.jar aus dem lib-Verzeichnis des Servers eingebunden werden. Dies ist leider ein echtes Manko, denn durch fehlende Aufteilung dieser Bibliothek muss jeder Client die vollen 16 MB dieser Datei verwenden. In diese Bibliothek ist auch eine jndi.properties enthalten, deren Einstellungen vollkommen ausreichen, wenn Glassfish auf dem lokalen Rechner läuft. Läuft er woanders, muss eine eigene jndi.properties erstellt und die URL angepasst werden:

[code]
java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory
java.naming.provider.url=iiop://localhost:1050
java.naming.factory.url.pkgs=com.sun.enterprise.naming:com.sun.enterprise.naming
[/code]

Danach sollte einem erfolgreichen Testlauf nichts mehr im Wege stehen.

Deployment im JBoss

Um EJB 3.0 mit dem JBoss zu nutzen, muss man den Installer der derzeit aktuellsten Version (4.0.4) herunterladen und den Server darüber installieren. Vollwertige EJB 3 Unterstützung enthält nur das EJB 3.0 Installationsprofil, selbst das Installationsprofil all kann mit EJB 3 nichts anfangen.

Datenbankverbindung einrichten

Da der JBoss leider nicht über eine Administrationsoberfläche verfügt, muss man die Datenbank mit Hilfe einer Datei konfigurieren. Zahlreiche Beispiele für unterschiedliche Datenbanken liefert der JBoss direkt mit (Verzeichnis docs/examples/jca). Die Konfigurationsdateien für Datenbankverbindungen müssen auf den Namen -ds.xml enden, damit der JBoss sie als das erkennt, was sie sind. Sie können entweder im Verzeichnis deploy des jeweiligen Profils abgelegt werden (üblicherweise server/default/deploy) oder in die JAR-Datei der Bean integriert werden. Ich benutze für dieses Beispiel eine MySQL-Datenquelle, die wie folgt konfiguriert ist:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE datasources
        PUBLIC "-//JBoss//DTD JBOSS JCA Config 1.5//EN"
        "http://www.jboss.org/j2ee/dtd/jboss-ds_1_5.dtd">
<datasources>
    <local-tx-datasource>
        <jndi-name>Test-DS</jndi-name>
        <connection-url>jdbc:mysql://myserver.local.net/test_db</connection-url>
        <driver-class>com.mysql.jdbc.Driver</driver-class>
        <user-name>username</user-name>
        <password>secret</password>
        <new-connection-sql>SELECT 1</new-connection-sql>
        <check-valid-connection-sql>SELECT 1</check-valid-connection-sql>
        <valid-connection-checker-class-name>
            org.jboss.resource.adapter.jdbc.vendor.MySQLValidConnectionChecker
        </valid-connection-checker-class-name>
        <exception-sorter-class-name>
            org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter
        </exception-sorter-class-name>
        <metadata>
            <type-mapping>mySQL</type-mapping>
        </metadata>
    </local-tx-datasource>
</datasources>

Bean anpassen & deployen

Die Adressierung der Datenbankverbindung für die Injection in die Bean folgt im JBoss einer anderen Syntax als im Glassfish. Statt der Eigenschaft name muss hier die Eigenschaft mapped name verwendet werden. Hier ist der JNDI-Name der konfigurierten Datenbank mit java:/ als Präfix einzusetzen:

@Resource(mappedName = "java:/Test-DS", type = DataSource.class)
public void setDataSource(final DataSource ds)
{
    this._dataSource = ds;
}

Diese Regelungen gelten analog für Einträge in die ejb-jar.xml. Nachdem man die Bean als JAR gepackt hat, kann sie durch Kopieren dieses JARs in den oben erwähnten Ordner deploy auf dem Server installiert werden. Etwaige Fehler dabei erscheinen in der Logdatei.

Client anpassen und starten

Um auf die im JBoss laufende Bean entfernt zugreifen zu können, muss im Client der Lookup über den Namen der Bean mit dem Zusatz /remote erfolgen:

final InitialContext ic = new InitialContext();
final StatistikDemo stat = (StatistikDemo) ic.lookup("java:/StatistikDemoEJB/remote");

Damit der Lookup klappt, muss auch eine JBoss-spezifische Konfiguration in der jndi.properties eingetragen werden. Im Falle des JBoss gibt es keine Vorgabedatei in einer der Bibliotheken, es muss also immer eine eigene angelegt werden. Es ist hierbei darauf zu achten, dass die URL nicht wie beim Glassfish mit einem Protokoll versehen wird. Die Eintragung von z.B. iiop:// würde zu einer Exception Unknown protocol iiop führen.

[code]
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
java.naming.provider.url=localhost:1099
[/code]

Im Gegensatz zum Glassfish hat der JBoss sauber getrennte Client-Bibliotheken, die schon fast zu speziell unterteilt sind. Für eine Anwendung wie diese müssen folgende Bibliotheken aus dem client-Verzeichnis verwendet werden:

• concurrent.jar
• jboss-aop-jdk50-client.jar
• jboss-aspect-jdk50-client.jar
• jboss-client.jar
• jboss-common-client.jar
• jboss-ejb3-client.jar
• jboss-j2ee.jar
• jboss-remoting.jar
• jbosssx-client.jar
• jboss-transaction-client.jar
• jnp-client.jar

Für andere Clients könnten noch zusätzliche Bibliotheken notwendig werden. Ein Teil der Bibliotheken ist auch zusammengefasst im jbossall-client.jar, da diese Bibliothek nicht ausreicht und alleine schon 4 MB auf die Waage bringt, hielt ich es für sinnvoller, die einzelnen Dateien aufzulisten, diese zusammen sind nur 2 MB groß (also um Faktor 8 kleiner als beim Glassfish).

Fazit

Der eigentlich EJB 3.0 Standard stellt für Enterprise-Entwickler eine deutliche Erleichterung gegenüber EJB 2.0 dar. Für Neulinge in dem Bereich wird das Erlernen der Techniken einfacher, weil komplizierte und abstrakte Konstrukte abgeschafft wurden.

Gemessen an den anfänglichen Hürden zwischen der EJB-Theorie und dem tatsächlichen praktischen Einsatz, wäre es besser gewesen, man hätte gerade im Bereich JNDI-Adressierung für die am häufigsten verwendeten Dinge wie Datenbankverbindungen, EntityManager, o.ä. ein einheitliches Adressierungssystem mit in den Standard aufgenommen. Die Einarbeitung in die unterschiedlichen Implementierungen gleicht gerade zu Beginn einem Puzzlespiel. Hat man diese Hürden aber erstmal genommen, steht dem komfortablen Einsatz von EJB 3.0 nichts mehr im Wege (zumindest, bis man auf die nächste “Tretmine” tritt).