3

一連のサービスをSpring Beanとして登録し、それらをJNDIに登録するレガシーJavaエンタープライズアプリケーションがあります。これを変換して、代わりに OSGi で Spring を使用したいと思います。

以前は、サービス クラスは、それを必要とする他のクラスのクラスパスに含まれており、次のような静的メソッドを持っていました。

public class SomeService {
    // private fields...

    public static SomeService getInstance() {
        SomeService svc = null;
        try {
            InitialContext ctx = new InitialContext();
            svc = (SomeService)ctx.lookup("java:/SomeService");
        } catch (NamingException ex) {
            logger.info("Exception in getNamedObject", ex);
        }
        return svc;
    }

    // Setters and getters, some of which are filled-in with Spring beans

    // Other methods etc...
}

サービスがどこで使用されても、次のようなコードがあります。

SomeService svc = SomeService.getInstance();
// or even
SomeObject results = SomeService.getInstance().getSomeObject();

これを変換する「正しい」方法は、getInstance()完全に削除し、インターフェイスのすべてのユーザーに、Spring によって提供され、META-INF の xml ファイルで構成された実装への独自の参照を強制することです。ただし、システムはすでに運用されているため、この変更は一度にすべてを行うには大きすぎます)。

上記の JNDI アプローチに類似した OSGi サービスのインスタンスを取得する方法はありますか?

更新：いくつかの明確化
ここで私の目標を明確にするために、これは一般的に良いアプローチではないことを知っています。ただし、これは本番環境にある大規模なエンタープライズ アプリケーションであり、「理想的な」OSGi 構造に合わせて全体を一度に変更するのは、一度にすべてを行うには大きすぎる変更です。

ここで私が達成しようとしているのは、アプリケーションの小さな部分を分割して、別の OSGi バンドルとして提供できるようにすることです。しかし、アプリケーションの残りの部分 (「クライアント コード」) はまだこの変更の準備ができていないため、このコードを古い方法とOSGi サービスの両方で使用できるようにする中間ステップが必要です。時間が経つにつれて、アプリケーションの残りの部分もモジュール化されて OSGi 化され、最終的にこれらの静的ファクトリ メソッドは完全に削除されます。

しかし、それまでは、「これは OSGi を行うには間違った方法だ」という発言は、私にはあまり役に立ちませんでした。

4

4 に答える 4