我有一个遗留的Java企业应用程序,它将一堆服务注册为Spring bean并使用JNDI注册它们.我想将其转换为使用带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服务使用此代码.随着时间的推移,其余的appilcation也将模块化和OSGi-ified,最终这些静态工厂方法将被完全删除.

然而,在那之前,“这是做错OSGi的方式”的评论对我来说并不是很有帮助 – 我知道它不是,但这甚至不是我的最终形式……

解决方法:

你正试图将方形钉穿过一个圆孔.每个开发人员都在计算机科学101中学习全局变量是坏的,所以我会说“正确”的引用是非常错误的,因为静态是主要的全局变量.

因为OSGi从不依赖于全局变量(java中的静态),所以可以在OSGi中的OSGi中运行OSGi中的OSGi,该OSGi位于运行在OSGi之上的App服务器上的WAR文件中.静态是邪恶的(首先由Anselm Baird说,它是OSGi的前身ServiceSpace的作者).开发服务模型是为了解决您遇到的问题;任何服务实现都可以通过其接口和/或属性从任何地方引用其他服务：

 @Reference
 void setSomeService(SomeService s) {
     this.s = s;
     ...
 }

在模块化系统中,*神XML是一种诅咒.

你的问题没有解决方案,因为你不可避免地会遇到排序问题.在OSGi中,不保证服务可用(其最强大和最容易被误解的功能之一).您的服务提供商可以随时出入.因为你的静态模型不处理依赖关系,所以它会虚假地失败,因为它假定是隐式排序.现在很多人都做这些静态解决方案,因为它大多数时间都可以工作;我认为“大多数时候”应该不适合计算机软件.如果我们要对我们的产品负责,不要认为我们会这样做……

假设您使用Eclipse或其他具有重构功能的IDE,那么我很难理解为什么更改代码库以注入此服务会很困难？

OSGi不是一种临时饮食,也不像大多数Java库那样神奇,它是一个成熟的模块化系统,需要你的应用程序才能真正实现模块化,即改变生活方式.试图使用一个框架,然后反对它的流程是一种战略,导致我的经历很悲痛.