Falls jemand Interesse hat meine Reviews der einzelnen Tage, ein paar Bilder oder ein paar Videos anzuschauen, dann möchte ich an dieser Stelle auf meine Blogeinträge bei der LMIS AG aufmerksam machen.
Posts mit dem Label Java EE werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Java EE werden angezeigt. Alle Posts anzeigen
24.05.2013
JAX 2013 - Crosspost der Reviews
Falls jemand Interesse hat meine Reviews der einzelnen Tage, ein paar Bilder oder ein paar Videos anzuschauen, dann möchte ich an dieser Stelle auf meine Blogeinträge bei der LMIS AG aufmerksam machen.
28.11.2012
JPA 2.0 - Simple Collection Mapping
Collections, und auch Maps, von einfachen Datentypen können direkt und somit ohne weitere Entitäten gemappt werden. Nahezu alle Konfigurationsmöglichkeiten bleiben dabei erhalten. Ein paar Feinheiten und Besonderheiten sind allerdings zu beachten.
Für die Beispiele wird die JPA Spec (JSR-317) zu Grunde gelegt.
java.util.List<T> / java.util.Set<T>
In JSR-317 ist definiert, dass alle Collections von einfachen Datentypen, wie auch von sogenannten Embeddables, durch eine einfache Annotation gemappt werden können. Ein einfaches Beispiel ist für diesen Fall schnell erstellt.
Die zentrale Annotation ist in diesem Fall @ElementCollection zur Definition einer Liste von Vornamen. Somit ist keine weitere Entität notwendig, die einen Wrapper um den einfachen Vornamen bildet, wie es vorher notwendig war. Entsprechende Tabellen werden automatisiert erstellt.
In diesem Fall wird die Beziehung direkt über eine Foreign-Key-Relation in der Tabelle Person_firstnames abgebildet. Auf den ersten Blick wäre eine sprechendere Tabellenbezeichnung sinnvoller. Daher wird die Entität durch eine Annotation erweitert:
@CollectionTable bietet die Standardkonfigurationsoptionen, wie:
- name
- schema
- catalog
- joinColumns
- uniqueConstraints.
Weitere Konfigurationen sind nicht notwendig und wie zu sehen ist, wird das Mapping für einfache Datentypen deutlich einfacher.
@ElementCollection kann aber nicht nur auf einfache Datentypen, sondern auch auf Embeddables angewandt werden. Ein Embeddable ist eine Klasse, die innerhalb der beinhaltenden Entität gespeichert wird und sich die Id mit der beinhaltenden Klasse teilt. Dabei wird jedes persistente Attribut / Embeddable mit persistiert.
Mit der Erweiterung durch die Liste der favorisierten Gerichte, werden die generierten Tabellen ebenfalls umfangreicher.
Wie zu sehen ist, wird aus dem FavoriteFood keine separate Entität, sondern, wie auch bei den Vornamen, eine einfache Liste, verknüpft über eine normale Fremdschlüsselbeziehung.
In beiden Fällen, sowohl bei den einfachen Datentypen, als auch bei den Embeddables, ist allerdings wichtig, dass mit dem Interface java.util.List gearbeitet wird und nicht mit einer konkreten Implementierung. Wird nicht mit dem Interface gearbeitet, tritt bereits einer Fehler bei der Analyse durch dem OR-Mapper auf.
Ein Grund für eine konkrete Implementierung wäre als Beispiel das Sortieren. Das kann an dieser Stelle eleganter gelöst werden.
Mit Hilfe der Annotation @OrderBy kann sowohl die Spalte nach der sortiert werden soll, als auch die Reihenfolge (asc oder desc) definiert werden. @OrderBy sorgt für eine Erweiterung der Statements um eine "ORDER BY" Bedingung auf die angegebene Spalte.
Spannend ist auch die Speicherung einer Liste von Enums. Wie beim Speichern von Enum-Werten, kann auch für die gesamte Liste angegeben werden, ob der Ordinalwert oder die textuelle Darstellung gespeichert werden kann.
java.util.Map<K,V>
Für die Benutzung von Map gelten im wesentlichen die gleichen Regeln, wie auch für das Nutzen von Set oder List. Somit wird der Einsatz von Maps in Entitäten leichter als er es vormals war. Eine Map mit einfachen Werten wird, wie auch Listen oder Sets, leicht gemappt, daher steige ich auch hier direkt mit einem etwas komplexeren Beispiel ein. Die Liste der Haustiere wird ersetzt durch eine Map der Haustiere mit ihren zugehörigen Namen.
Die Tabellenstruktur wird entsprechend um eine Tabelle erweitert.
Dabei ist zu erkennen, dass die neu erstellte Tabelle Person_pets neben dem Fremdschlüssel zur Person zwei weitere Spalten beinhaltet. Die eine Spalte pets_KEY entspricht dem Schlüssel der Map (dem Namen des Haustieres) und die Spalte pets entspricht dem Wert in der Map. Sofort fällt auf, dass neben dem nicht unbedingt glücklichem Namen der Tabelle auch nicht unbedingt der Ordinalwert der Enum gespeichert werden soll. Auch dies kann durch Annotationen behoben werden.
Mit @Enumerated wird festgelegt, dass der Wert des Eintrages in der Map als textuelle Repräsentation gespeichert wird. Gleichzeitig können mit Hilfe der Annotation @MapKeyColumn die Eigenschaften der Schlüsselspalte festgelegt werden. Sollen die Eigenschaften der Wert-Spalte festgelegt werden, wird dafür die normale @Column Annotation verwendet.
Was ist aber, wenn die Schlüsselspalte der Map als Enum werden soll?
Mit der Annotation @MapKeyEnumerated kann die Art der Speicherung für den Enum-Wert in der Schlüsselspalte festgelegt werden. Somit besteht auch an dieser Stelle die Möglichkeit, dass nicht der Ordinalwert, sondern die textuelle Repräsentation gespeichert wird.
Wie also zu sehen ist, wird das Mapping von einfachen Collections mit JSR-317 deutlich leichter und komfortabler. Viel Erfolg beim Ausprobieren!
Die Beispiele finden sich wie immer im Repository.
13.10.2012
Maven Build Profiles - Test unterschiedlicher JPA Provider
Auf dem Plan standen, neben Hibernate, EclipseLink oder auch OpenJPA.
Um für die Betrachtung eine möglichst schnell zu wechselnde Laufzeitumgebung zu haben, habe ich mir die Maven Build Profiles mal wieder ins Gedächtnis gerufen. Ziel der Build Profiles ist es ja, dass man recht leicht zwischen dedizierten Umgebungen wechseln kann. Gleichzeitig kann man in den Build-Profilen aber auch selektiv Dependencies oder Properties überschreiben, setzen oder neu definieren. Also eigentlich genau das richtig für mein Unterfangen, oder?
Begonnen habe ich mit einer einfachen Entität, dem Standard-Beispiel quasi. Basis für die gesamte Betrachtung war eine einfache Person mit ein paar wenigen Attributen.
Eine einfache und leicht zu verstehende Entität. Um die Provider möglichst einfach zu testen, habe ich einen kleinen JUnit-Test erstellt. Dieser versucht eine Person zu erstellen, diese zu persistieren und schlussendlich auch wieder aus der Datenbank zu lesen.
Der Test selbst ist unspektakulär, der EntityManager wird vor jedem Test erstellt und es wird eine Transaktion geöffnet. Nach jedem Test wird der EntityManager wieder geschlossen. Interessant ist allerdings noch die Erzeugung der EntityManagerFactory. Dies wird vor dem Test selbst in der @BeforeClass Methode ausgeführt und sieht wie folgt aus:
Der Name der Persistence-Unit wird an dieser Stelle aus einer System-Property ausgelesen. Je nach Provider wird eine der drei Persistence-Units für die Erzeugung der EntityManagerFactoryherangezogen.
Damit diese Property vom Buildprozess aus gesteuert werden kann, wird das Surefire-Plugin um einen Konfigurationseintrag erweitert.
Mit Hilfe dieser Property können nun die Build Profiles elegant die Werte überschreiben und damit die zugehörige Persistence-Unit für den Test auswählen.
Durch diese Konfiguration kann für jeden Provider ein eigenständiges Profil erstellt werden, welches, von den anderen Profilen unabhängig, eigene Dependencies definiert und vollkommen autark aufgerufen werden kann. Damit ist ein Wechsel des Providers bereits während der Testphase möglich.
Ein Aufruf von mvn clean test -P EclipseLink liefert dann direkt die folgende Ausgabe.
In beiden Fällen wird die Auswahl der Persistence-Unit über die überschriebene Property getätigt. Die Dependencies und sonstigen Einstellungen werden ebenfalls aus dem aktivierten Profil entnommen.
Der Code ist wie immer im Repository verfügbar.
29.08.2012
CDI mit Tomcat 7 - Ein einfaches "Hello World!"
Nach dem letzten Vortrag der JUG über den Einsatz von CDI in No-Tier-Enterprise Applications (Folien auch auf Slideshare verfügbar) wollte ich mal testen, ob das ganze auch mit dem Tomcat 7 realisierbar ist.
Die schlechte Nachricht ist, dass von Haus aus der Tomcat keine Unterstützung bietet, sondern erst mit einer weiteren Bibliothek gepimpt werden muss. Die gute Nachricht ist allerdings, dass durch den Einsatz der Bibliothek keine Konflikte entstehen und dem Einsatz von CDI nichts im Wege steht.
Für die Nutzung von CDI sind drei Schritte notwendig. Zum einen ist es notwendig, dass die Dependency dem bestehenden Projekt hinzugefügt wird. Danach wird ein Listener innerhalb der web.xml definiert und schlussendlich wird noch die beans.xml angelegt.
1) Hinzufügen der Dependency
2) Erweitern der web.xml mit einem zusätzlichen Listener
3) Hinzufügen der leeren beans.xml
Das war schon die halbe Miete, mehr muss für das einfache Beispiel nicht konfiguriert werden.
Die Struktur der Anwendung ist ebenfalls bewusst einfach gehalten und besteht im wesentlichen aus zwei Klassen, der Service-Klasse HelloWorld und dem Servlet HelloWorldServlet.
HelloWorld ist ein einfacher Service, der auf Anfrage den Text "HELLO WORLD!" zurück gibt.
HelloWorldServlet ist mittels @javax.servlet.annotation.WebServlet als Servlet definiert worden und steht somit als Endpoint der Anwendung zur Verfügung. Gleichzeitig wird eine Instanz von HelloWorld in das Servlet injected und dort zur Ausgabe "HELLO WORLD!" genutzt.
Ein Aufruf des Servlets liefert dann, nach Start des Tomcats die gewünschte Ausgabe.
Ziemlich einfach und schnell zu realisieren! Da werde ich auf jeden Fall mal ein wenig testen!
Der Code ist natürlich auch im Repo verfügbar!
20.07.2012
No-Tier Enterprise Applications with CDI (Lars Röwekamp)
Insgesamt waren ca. 20-25 Teilnehmer im Haus der Wissenschaft und haben Lars Röwekamp (www.openknowledge.de) bei seinem Vortrag zum Thema CDI zugehört. Lars geht in seinem Vortrag auf die Möglichkeiten ein, die sich seit der Einführung von CDI 1.0 ergeben haben.
Ziel des Vortrags war zu demonstrieren, dass eine klassische 3-Tier Application mit Hilfe von CDI in quasi in eine No-Tier Application umgewandelt werden kann.
Ein wichtiger Punkt direkt vorab. Die eigentliche Schichtentrennung wird dabei nicht aufgehoben, sondern bleibt im wesentlich "unter der Haube" vorhanden. Wir gehen also nicht zurück in die Welt des Spaghetti-Code oder des GOD-Patterns.
Man kann aber klar erkennen, dass mit der Einführung von CDI (seit Java EE 6) deutlich weniger Overhead bei der leichtgewichtigen Erstellung von Enterprise-Anwendungen vorhanden ist. Die Entwicklung geht damit weg von einer klassischen Ausrichtung, hin zu einer vereinfachten, lose gekoppelten Architektur in der sich die Transaktionen auf eine fachliche Ebene verschieben und die Services als eine Wolke von Businessobjekten zur Verfügung stehen. Damit stehen nicht mehr die infrastrukturellen Themen im Vordergrund, sondern die wesentlich wichtigeren fachlichen Aufgaben.
Nach einer kurzen Einführung in das Thema CDI:
- IoC / DI lite (Java EE ohne EJB)
- IoC / DI advanced (Lifecycle Management und Scoping)
- IoC / DI extreme (Typsicherheit und lose Kopplung)
- IoC / DI open (leichtes Customizing)
ging es auch direkt in ein praktisches Beispiel anhand eines einfachen Use-Case. In dem Beispiel wurde sowohl die Leichtgewichtigkeit während der Entwicklung, als auch die zahlreichen Vorteile klar. Der für mich persönlich größte Benefit liegt definitiv in der fachlichen Konzentration anstelle der Infrastruktur-Themen. Die Arbeit mit fachlichen Objekten und das Loslassen von infrastrukturellen Themen ist definitiv ein Punkt der mir gefallen hat.
Was mir persönlich allerdings gefehlt hat, ist eine deklarative Transaktionssteuerung, diese musste, wie im Beispiel klar geworden ist, selber erstellt werden. Es soll allerdings mit Erscheinen der Version 1.1 eine Möglichkeit geschaffen werden.
Ebenfalls etwas unschön fand ich die Steuerung der Conversations, da diese innerhalb der Methoden gestartet und auch beendet werden müssen. Auch da würde ich mir eine deklarative Steuerung über Annotationen wünschen. Im aktuellen Stand muss dieses Feature, beispielsweise über Interceptors, selber entwickelt werden.
Alles in allem ein sehr gelungener Abend, der sicherlich von der Qualität des Vortrags, wie auch von der Länge des Vortrags herausragend war.
Danke JUG!
Abonnieren
Posts (Atom)