2017-01-17 1 views
0

Ich habe diese Situation:Teilen Sie eine JPA-Datenquelle unter OSGi-Bundles

  • eine SQL-Datenbank-Instanz
  • zwei oder mehr OSGi-Bundles mit JPA-Entitäten und feder Datenrepositorien für "ihre" Entitäten
  • einer der "jpa bundles" ist das "core bundle", die anderen hängen davon ab (plugin bundle)

Kann ich das mit einer einzigen Datenquelle verwenden?

Beispiel:

  • "Kernbündel" enthält Person Einheit
  • "Person Liste Plugin Bundle" enthält eine PersonList Einheit, die Hinweise auf die Person Entität durch eine people Eigenschaft

ich jetzt möchte ein PersonListService aus dem "Person list plugin bundle" verwenden, das PersonListRepository.findByPeoplesFirstName(String firstName)

verwendet

Der Hintergrund ist, dass ich möchte, dass die Datenbank meiner Anwendung erweitert werden kann, indem ein osgi-Bundle als Plugin hinzugefügt wird.

Im Moment experimentiere ich mit Apache Karaf und Hibernate 5, wegen der räumlichen Unterstützung, wenn das wichtig ist.

+0

Warum möchten Sie "Plugins" trotzdem verwenden? Wenn Sie beispielsweise eine Personenentität haben, sollten alle Repository-Klassen, die sich mit Person befassen, im selben Paket sein. Ich denke, es wäre nicht sinnvoll, Entitäten und ihre Repositories zu trennen. –

+0

Ich möchte eine Legacy-Anwendung ersetzen, in der Benutzer einfach ein "Plugin" installieren können, indem sie einen Ordner mit PHP-Code hinzufügen. Es gibt jetzt ein "Cache-Builder-Plugin", das der Datenbank einige vorberechnete Tabellen hinzufügt. Dies benötigt Zugriff auf seine eigene Tabelle und auf die "Kern" -Tabelle. – dve

Antwort

0

In OSGi wird empfohlen, dass alle Entitäten eines JPA EntityManagers im selben Bundle enthalten sind. Sie können den EntityManager aus einem Paket erstellen, in dem alle Entitäten angezeigt werden. Dies funktioniert jedoch nicht mit einem Plug-In-Modell, wie Sie es möchten.

Wenn Sie jedoch ein Modell auf der Datenbankseite erstellen, das mehrere Bundles hervorbringt, kann es trotzdem zu unerwünschter Kopplung kommen. Sie sollten das DDD-Konzept beschränkter Kontexte untersuchen und Ihre Persistenzkontexte erstellen, um jeweils einen beschränkten Kontext zu implementieren.

Ein Plugin-Modell ist ohnehin nicht sehr kompatibel zu einer Datenbank, da die Datenbank normalerweise eine recht statische Struktur haben muss, während Plugins zur Laufzeit kommen und gehen können.

Sie können natürlich die DataSource teilen, aber dies ist auf JDBC-Ebene nicht auf Jpa-Ebene.

+0

Ich hatte Angst vor dieser Antwort, aber würde diese Idee funktionieren: Jedes "jpa-bundle" importiert die benötigten und erstellt einen eigenen Persistenzkontext? Ich kann dann keine Objekte von einem zu einem anderen Bundle freigeben, aber trotzdem die Entity- und Service-Definitionen verwenden? – dve

+0

Ich glaube nicht, dass das funktionieren würde. Der Grund dafür ist, dass die EntityManager unterschiedliche Caches haben würden, aber effektiv in dieselbe Datenbank schreiben würden. Sie können natürlich einige Basisklassen teilen, aber jeder EntityManager sollte in verschiedene Tabellen schreiben. –