OSGI Bundles - The Big Picture

Nachdem ich nun lange genug gebastelt habe und einige Umstrukturierungen vornahm, möchte ich mal so zwischendurch ein Overview der verschiedenen OSGi Bundles aufzeigen. OSGi Service Referenzen sind rot markiert und OSGi Package Imports grün. Lediglich der Flex Client nimmt ein zweites Flex Modul während des Kompilierens hinzu (akzeptabel)



Der Flex Client nutzt also die OSGi Service Registry um Services zu finden, die direkte Implementierung übernimmt hier ein anderes Bundle (...spring). Diese Trennung rührt daher, da es in früherer Zeit eine zweite Service Implementierung auf Basis von EJB gab.

Die Service Implementierung nutzt ein Bundle der Integrationsschicht (war dies nicht was mit DAO!?), dies wird ebenfalls über die OSGi Service Registry aufgelöst.

Implementiert wird dieses "DAO" Interface Bundle durch ein Bundle welches JPA nutzt (...integration.jpa). Die DAO Implementierung muss natürlich die JPA Entity Klassen kennen (in common.domain und tms.domain). Der Übersicht wegen sei hier auf die Referenzierung von Services und Client auf diese Bundles verzichtet.

Das Bundle ...integration.jpa ist in sofern interessant, da hier der PersistenceContext (sprich:EntityManagerFactory) erzeugt wird. Es müssen also die Bundles mit den Entity Klassen bekannt sein. Ausserdem braucht die Initialisierung des EM auch eine DataSource (Bundle:infrastructure.postgres) und einen JPA Provider (integration.eclipselink). Diese sind in zwei separate Bundles ausgelagert um sie austauschbar zu halten, JPA kann EclipseLink, Hibernate... sein wobei die DataSource die dahinterliegende DB verstecken sollte.

Was auf diesem Bild nicht eingezeichnet ist, das es nicht in diesem Scope liegt, ist ein Modul der Domain Objekte in ActionScript. Diese Klassen werden aus den Java Domain Objekten generiert und dienen dem Flex Client, haben also keinen direkten Bezug zu OSGi (daher Modul und nicht Bundle).

JPA Entity Klassen in mehreren JAR Filex

Also zum Problem, an dem ich nun wieder seit Tagen rumgebissen habe:
Ich habe Entity Klassen in mehreren JAR Files und möchte diese innerhalb einer Webanwendung (WAR) deployen. Das Projektchen ist bzgl. Dependencies ungefähr wie folgt aufgesetzt: entity1.jar, entity2.jar werden von einer Service Layer Implementation service.jar benutzt. Alle drei zusammen werden in einer Flex Webanwendung (könnte auch sonst ein Client sein) benutzt, liegen somit im WEB-INF/lib folder.

Nun ja, soweit eigentlich noch kein Problem, aber wohin mit der persistence.xml? Diese darf natürlich nicht ein einer der beiden entity.jars liegen da sie sonst nur für dieses JAR zählt. Dann die logische Frage: Wer braucht eigentlich alle Entities? Das ist der Service (oder auch Integration) Layer, also dort ins META-INF. Somit funktionierts. Oder auch in WEB-INF/classes/META-INF, allerdings ist dies keine Angelegenheit der Webanwendung itself.

Kleiner Seiteneffekt während der Entwicklung in Eclipse: Man muss natürlich die persistence.xml aus den Domain Object Projekten entfernen, das kann allerdings zu Problemen mit dem Eclipse Dali JPA Validator führen, da der nicht mehr weiss gegen wen oder was er validieren muss.