Ich teste gerade osgi (Spring DM) für eine neue Anwendung aus. Die Anwendung muss Dateisystemereignisse überwachen können. Heute habe ich das mit einem einfachen zeitbasierten Poller gelöst, aber wenn Java 7 veröffentlicht wird, möchte ich das wahrscheinlich durch eine NIO2-basierte Implementierung ersetzen.
Bisher betrachte ich drei Bundles, zwei für die File-Service-Implementierungen und einen für die Geschäftslogik, die einen der Services verbraucht. Die beiden Implementierungen sollten die gleiche Schnittstelle implementieren, also ist meine Frage, wo diese Schnittstelle platziert werden soll? Wenn Sie die Schnittstelle in dem Paket platzieren, das die Implementierung enthält, würde der Dienst von einem seiner Benutzer abhängen.
Was wäre der beste und am meisten osgiartige Weg, dies zu strukturieren? Bis jetzt ist meine beste Wette, ein neues "api" -Bündel zu erstellen, das die allgemeinen Schnittstellen für die Implementierungen definiert.
Separete api-bundle ist wahrscheinlich die beste Wahl. Es ermöglicht Ihnen, die Bündelimplementierung später zu ersetzen. Auch mit separatem api-Bundle können Sie Ihr aktuelles Paket ersetzen, ohne dass der Kunde neu starten muss.
Klassen (und Interfaces) werden anhand ihres Namens und Klassenladeprogramms erkannt. Wenn Sie also die Service-Schnittstelle im selben Paket wie die Implementierung platzieren, verlieren Sie die Möglichkeit, das laufende Paket zu ersetzen. Obwohl die Schnittstelle den gleichen Namen hat und in jeder Hinsicht identisch ist, hat das neu bereitgestellte Paket einen anderen Klassenlader = & gt; consumer betrachtet die neu bereitgestellte Bundles-Schnittstelle als neue Klasse und ihre Abhängigkeiten werden nicht mehr erfüllt.
Weitere Informationen zu Kompatibilität und Versionen von Diensten (siehe Kommentare): Ссылка
Tags und Links osgi