OSGi + Hibernate

Question

データベースアクションを4つの（osgi）バンドルに分散するのではなく、そこではやや異なることがあります。私はすべての永続性問題を担当する（シンプルな）OSGiバンドルを作成したいと思います。私はこれが "バンドルごとのユニークなクラスローダー"のために聞こえるほどシンプルではないと感じています。 私が本当に感謝するのは、誰かがこの種の問題に対する解決策を知っている場合です。

Answer 1

（あなたはHibernateのアノテーションを使用している場合）

保存Hibernateのバンドルは注釈付きクラスについて通知されるすべてのエンティティクラスローダー。

次に、SessionFactoryを構築する前に、このようなことをしてください。

ClassLoad cl = Thread.currentThread().getContextClassLoader(); 
try { 
Thread.currentThread().setContextClassLoader(yourClassLoader); 
factory = cfg.buildSessionFactory(); 
}finally { 
Thread.currentThread().setContextClassLoader(cl); // restore the original class loader 
} 

Answer 2

クラスローディング問題を解決するには2つの方法があります。

• 特定のOSGi-Frameworkに拘束されていますか、できるだけ互換性を維持しますか？またはあなたの実装に分点を使用できますか？ Equinoxには、Buddy Classloadingというメカニズムがあります。この追加により、異なるOSGi-Bundle間の特定のクラスの可視性を高めることができます。このトピックに興味がある場合は、Understanding how Eclipse plug-ins work with OSGi、Eclipse - a tale of two VMs (and many classloaders)という2つの記事をお伝えしたいと思います。
• OSGiの実装を独立させようと思えば、Hibernate-Bundleと他のバンドルの両方が依存する別のバンドルに、永続化したいクラスを抽出することを検討するかもしれません。こうすることで、すべての永続クラスのクラス定義にアクセスできます。

Answer 3

Bundleクラス/ apiで興味深いメソッドが見つかりました。

public java.lang.Class loadClass(java.lang.String name) throws java.lang.ClassNotFoundException 

これはいくつかのクラスローダの問題を解決する必要がありますか？

Answer 4

は、私はそれがの春分の実装をEclipseに特定だと離れてバディクラスローディングから滞在することをお勧めするつもりだと、私の意見では、人々はそれが仕事を得るが、彼らはなぜ理解していないと、誰もが通り終わります他の人のバディ。これにより、OSGiのクラスローディングの仕組みや、使用するパターン（複合クラスローダー、コンテキストクラスローディング、OSGiサービスなど）を正しく理解することができなくなります。

永続性バンドルが、永続化する必要があるタイプを事前に知っている場合、バンドルはドメインクラスを含む必要なすべてのパッケージ（Require-Bundle is evil）をインポートできます。

OSGiサービスの背後にあるものを隠すために、Spring dmのようなものを使うことを提案していますが、（Rogerの返信のように）コンテキストクラスローダーを管理するとHibernateを助けることができます。

Answer 5

ハイバーネートdoes support OSGiでも、それはongoing effortです。