EJB Persistence mit Java Standard Edition (2. Teil)

Da nun das QuickExample über ein funktionelleres Mapping verfügt, kann man das Thema wechseln. EJB3/JPA sollte den Vorteil haben, dass man leicht zu einer anderen Persistenzbibliothek wechseln kann. Um das auszuprobieren, soll nun die EJB3/JPA-Referenzimplementierung von Glassfish mit dem Beispielcode verwendet werden.

Theoretisch müsste zur Verwendung von Glassfish nur die persistence.xml-Datei etwa folgendermaßen geändert werden:

Der Provider wurde auf die Toplink-Version und die Eigenschaften auf Toplink-Varianten geändert, um Treiber, Verbindung, Benutzername und Passwort zu konfigurieren. Hibernates dialect-Eigenschaft ersetzt eine toplink.platform.class.name-Eigenschaft, die ddl-generation-Eigenschaft ersetzt Hibernates hbm2ddl.auto-Eigenschaft, und die toplink.logging.level-Eigenschaft mit der Einstellung fine ersetzt Hibernates showsql-Eigenschaft. SQL-Statements werden im Rahmen des normalen Protokollierens protokolliert.

Sämtliche Hibernate-Bibliotheken werden hinausgeschmissen und durch Bibliotheken der Glassfish-Distribution ersetzt; antlr.jar, asm.jar, asm-attrs.jar, javaee.jar und toplink-essentials.jar sind in Glassfishs lib-Verzeichnis zu finden, man kann sie von Glassfishs Website herunterladen und installieren. Da nur Bibliotheken von Glassfish verwendet werden, braucht man Glassfishs Applikationsserver nicht. Es muss allerdings noch eine Einstellung vorgenommen werden, wenn man den Code ausführt, die es nur bei Toplink gibt – man muss einen Agenten injizieren. Dafür braucht man toplink-essentials-agent.jar, und bei der Ausführung muss man -javaagent:{Pfad zur .jar-Datei}/toplink-essentials-agent.jar aus der Java VM als Argument in der Java-Laufzeit-Befehlszeile hinzufügen.

Dann sollte es laufen. Doch wie stets, wenn man sich in einem Bereich befindet, in dem sich Standards verfestigen, gibt es einige Verhaltensunterschiede zwischen TopLinks und Hibernates EntityManager/Annotations. Im Glassfish-Beispielcode wurden die folgenden Änderungen vorgenommen.

@JoinColumn(„address_id“) wurde den Annotationen zu Person.address hinzugefügt, um Toplinks Problem der nicht korrekten Behandlung von Auslassungen zu umgehen. Die ID-Eigenschaften von Address und Person müssen explizit mit @Column(name=“ADDRESS_ID“) und @Column(name=“PERSON_ID“) benannt werden, weil Toplink sonst beide ID nennt und nur eine einzige bizarre ID-Spalten-Tabelle für die Address_Person-Tabelle erzeugt – übrigens ohne eine Fehlermeldung oder eine Warnung auszugeben.

Darüber hinaus mussten die findBy-Methoden modifiziert werden, sodass sie in ihren where-Ausdrücken bestimmter sind, zum Beispiel where person.name=:param statt where name=:param, weil Toplink kleinlicher bei der Benennung ist.

Und schließlich musste System.out.println(ax.getResidents()) in der exercise-Methode durch for(Person pi:ax.getResidents()) System.out.println(pi); ersetzt werden. Das liegt daran, dass Toplinks Lazy-Loading-Implementierung über eine toString-Methode verfügt, die die Inhalte der Sets nicht ausgibt, sodass man das für das ganze Set wiederholen muss. Nach diesen Änderungen kann der Beispielcode ausgeführt werden.