Spring 依赖注入和插件 Jar

Question

我有一个使用后端服务的默认实现运行的 Web 应用程序。人们应该能够实现该接口并将 jar 放入插件文件夹（不在应用程序类路径中）。服务器重新启动后，想法是将新的 jar 加载到类加载器中，并让它参与依赖注入。我正在使用 @Autowired 来使用 Spring DI。新的插件服务实现将具有 @Primary 注释。因此，给定接口的两个实现，应该加载主要的实现。

我将 jar 加载到类加载器中，并且可以手动调用 impl。但我还无法参与依赖注入，并用它替换默认的实现。

这是一个简化的示例：

@Controller
public class MyController {
   @Autowired
   Service service;
}

//default.jar
@Service
DefaultService implements Service {
   public void print() {
       System.out.println("printing DefaultService.print()");
   } 
}

//plugin.jar not in classpath yet
@Service
@Primary
MyNewService implements Service {
   public void print() {
      System.out.println("printing MyNewService.print()");
   } 
}

//由于缺乏更好的地方，我从 ContextListener 加载了插件 jar

public class PluginContextLoaderListener extends org.springframework.web.context.ContextLoaderListener {

        @Override
        protected void customizeContext(ServletContext servletContext,
                                        ConfigurableWebApplicationContext wac) {
                System.out.println("Init Plugin");
                PluginManager pluginManager = PluginManagerFactory.createPluginManager("plugins");
                pluginManager.init();

                    //Prints the MyNewService.print() method  
                    Service service = (Service) pluginManager.getService("service");
                    service.print();                  
            }
    }

     <listener>
            <listener-class>com.plugin.PluginContextLoaderListener</listener-class>
     </listener>

即使在我将 jar 加载到类加载器中后，DefaultService 仍然作为服务注入。知道如何让插件 jar 参与 spring 的 DI 生命周期吗？

编辑： 简单地说，我有一个 war 文件，在 war 内的 plugins 目录中包含一些插件 jar。根据应用程序查看的配置文件中的值，当应用程序启动时，我想加载该特定的插件 jar 并使用它运行应用程序。这样，我可以将战争分发给任何人，他们可以根据配置值选择要运行的插件，而无需重新打包所有内容。这就是我正在努力解决的问题。

Answer 1

看起来您所需要的只是正确创建 Spring ApplicationContext 。我认为没有类路径混合是可能的。最重要的是 Spring 配置文件在类路径中的位置。因此，将所有插件 jar 放入 WEB-INF/lib 中并继续阅读。

让我们从核心模块开始。我们将使它从位于 classpath*:META-INF/spring/*-corecontext.xml 的文件创建它的 ApplicationContext。

现在我们将使所有插件在其他地方拥有它们的配置文件。即“myplugin1”的配置位置如下：classpath*:META-INF/spring/*-myplugin1context.xml。 anotherplugin 的配置位于 classpath*:META-INF/spring/*-anotherplugincontext.xml。

您看到的是约定。如果您愿意，也可以使用子目录：

• core: classpath*:META-INF/spring/core/*.xml
• myplugin1: classpath*:META-INF/spring/myplugin1/*。 xml
• anotherplugin: classpath*:META-INF/spring/anotherplugin/*.xml

重要的是位置必须不相交。

剩下的就是将正确的位置传递给 ApplicationContext 创建者。对于 Web 应用程序，正确的位置是扩展 ContextLoaderListener 并重写 customizeContext(ServletContext, ConfigurableWebApplicationContext) 方法。

剩下的就是读取您的配置文件（其位置可以作为 servlet init 参数传递）。您需要构建配置位置列表：

String locationPrefix = "classpath*:META-INF/spring/";
String locationSiffix = "/*.xml";

List<String> configLocations = new ArrayList<String>();
configLocations.add(locationPrefix + "core" + locationSiffix);

List<String> pluginsTurnedOn = getPluginsTurnedOnFromConfiguration();
for (String pluginName : pluginsTurnedOn) {
    configLocations.add(locationPrefix + pluginName + locationSiffix);
}

applicationContext.setConfigLocations(configLocations.toArray(new String[configLocations.size()]));

这样您就可以轻松管理 Spring ApplicationContext 中加载的内容和未加载的内容。

更新：

为了使其发挥作用，我还做了一个隐藏的假设，现在我将对此进行解释。核心模块和每个插件的基础包也应该不相交。即：

• com.mycompany.myapp.core
• com.mycompany.myapp.myplugin1
• com.mycompany.myapp.anotherplugin

这样每个模块都可以使用 （在JavaConfig 中的等效项）可以轻松地添加类路径扫描仅针对其自己的类。核心模块不应包含任何插件包的任何包扫描。 插件应该扩展 ApplicationContext 的配置，以将自己的包添加到类路径扫描中。

Answer 2

如果您重新启动服务器，我认为您没有理由不能将 JAR 添加到 WEB-INF/lib 并将其放在 CLASSPATH 中。自定义类加载器和上下文侦听器的所有复杂性都消失了，因为您像对待 Spring 控制下的任何其他类一样对待它。

如果您这样做是因为您不想打开或修改 WAR，为什么不将其放在服务器 /lib 目录中呢？让服务器类加载器拾取它。这使得所有插件类可用于所有已部署的应用程序。

答案取决于单独的 /plugin 目录的重要性。如果它是解决方案的关键，并且您无法将 JAR 添加到服务器的 /lib 目录，那么就是这样。我什么都没有了但我认为至少重新审视您必须确保它是实现您想要的目标的唯一方法是值得的。