Hyperjaxb3

In einem früheren Post hatte ich bereits über die Möglichkeiten der Generierung von Javaklassen aus XML und die Beschränkungen von JAXB berichtet. Zu diesem Zeitpunkt hatte ich nach alternativen gesucht, wobei ich schon über Hyperjaxb3 gestoßen war. Auf den ersten Blick schien dieses Framework keine mögliche Alternative bzw. Erweiterung zu bieten. Die Seite http://xircles.codehaus.org/projects/hyperjaxb3 war nicht wirklich aussagekräftig.
Vor einigen Wochen haben wir begonnen unser Projekt auf Maven umzustellen. Während dieser Zeit fanden viele Änderungen an den Interna der HTI statt, was zu vielen Fehlern führte. Oft war Dozer und unsere parallele Klassenhierarchie das Problem. Für den Zweck, dass man unterschiedliche Schichten oder Komponenten mit unterschiedlichen Domain-Klassen in einem System hat, ist es absolut sinnvoll Dozer als Mapper zu verwenden. Das Prinzip von information hiding ist es nur notwendige Informationen bekannt zu geben. Alles was nicht im Rahmen der Abarbeitung einer bestimmten Aufgabe liegt, ist geheim zu halten und sollte die entsprechende Schicht oder die Komponente nicht verlassen. Pro Schicht ein eigenes Domain-Modell zu haben, ist ganz im Sinne dieses Prinzips.
In unserem Fall gibt es kaum etwas zu verbergen. Einzig das Problem der Erhaltung der Persistenzkonfiguration, bei einer erneuten Generierung des Modells, war der Grund für die parallele Klassenhierarchie und den folglich notwendigen Mapper, Dozer, zu verwenden.
Daher haben wir nochmals recherchiert, ob es denn nicht noch andere Möglichkeiten gibt und sind durch das hinzugenommene Maven nochmals auf Hyperjaxb3 gestoßen. Diesmal haben wir eine andere Projektseite (http://confluence.highsource.org/display/HJ3/Home) mit recht guten Tutorials und mit Maven-Konfigurationen gefunden.
Der Mehrwert der Verwendung von JAXB mit Hyperjab3-Plugin ist enorm:

• Die Klassen des Domain-Modells werden bei jedem Buildvorgang mit erzeugt.
• Diese enthalten nun sogar die Persistenzkonfiguration (in Form von JPA-Annotationen).
• Daher wird die zweite Klassenschicht (unsere bisher als Entities bezeichneten Klassen) und folglich Dozer als Mapper überflüssig.

Für die technische Umsetzung ist noch zu erwähnen, dass nun jedoch für JAXB so genannte Custom Bindings definiert werden müssen. Man kann dies inline, also in dem Schema, oder extern in einer extra Binding-Datei (binding.xjb) tun. Ein Binding ist eine Regel in XML-Notation, der JAXB entnehmen kann, wie es bestimmte Mappings beim Marshalling und Unmarshalling von XML-Dokumenten auf Java vorzunehmen hat. Um unser Schema von domänen-fremden Inhalten sauber zu halten, haben wir uns natürlich für die externe Variante entschieden.

Die vollständige Migration der Alternative in das Produktivsystem ist in Arbeit und es bleibt abzuwarten in wie weit alles gut geht.