我们有一个门户应用程序，其中包含一个主Web应用程序上下文和许多次要Web应用程序上下文 - 插件。目前（非常简化）主要有自己的弹簧库和插件，如果他们想使用弹簧也必须有它们。在通用/共享tomcat上下文中，只有驱动程序和接口。
如果弹簧库被移动到普通的上下文中，弹簧可能会间接使用它们或者它们可能会使用spring吗？像hibernate一样，因为应用程序正在使用spring-tx等。休眠是否也必须转移到公共/共享上下文？
您如何看待，其他方面是什么？从spring应用程序上下文的角度来看，这样会容易得多。
答案 0 :(得分：0)
如果您能够从Tomcat迁移到成熟的Java EE容器，那么可以选择使用EAR将所有内容打包为Bundled Optional Classes mechanism。
然后你将常见的JAR移出WAR＆amp;进入EAR的最高层。
答案 1 :(得分：0)
@RichW说明将Spring库放在Tomcat的通用类加载器中是不正确的。并且很有可能它不起作用。
Java使用classloader hierarchy）。当请求类加载时，类加载器将在尝试使用它自己的类路径加载类之前递归地从它的父类加载器请求该类。此过程继续到根类加载器（称为引导类加载器）。通过这种方式，从父类加载器引用的类总是优先于层次结构中更深层次的类加载器中引用的类。
重要的是要注意，在此过程中，类永远不会从子类加载器加载。因此，Spring所需的任何类都需要加载到公共类加载器中 - 包括asm，log4j，commons-logging和cglib（所有spring依赖于它们）。这将导致一系列问题：特别是，包括公共类路径中的公共日志记录a whole world of hurt
如果你真的设法让Tomcat启动，那么在回收应用程序时你会遇到内存泄漏问题。在tomcat中，应用程序使用传统的垃圾收集进行卸载，因此如果有任何内容对应用程序中的一个类的引用随后重新启动，那么该应用程序将不会进行垃圾收集。 Spring和日志框架是保持对类的引用的主要候选者，因此在重新启动应用程序后，您可能会遇到OOM错误。
安全地执行此操作的唯一方法是考虑使用完整的应用程序服务器（例如JBoss AS）并将您的应用程序部署为EAR。
答案 2 :(得分：-1)
是的，我知道这很诱人。是的，它可以工作。但是将特定于应用程序或特定于框架的库放在应用服务器的共享库文件夹中被一些人认为是不好的做法，我同意。
在我看来，web-apps应该包含自己的依赖项（app jars，framework jar等）。框架也具有依赖性，通常需要具有特定版本的多个罐。有时这些版本会发生变化，有时依赖变化。随着时间的推移，共享库文件夹将成为罐子的厨房水槽，这将影响您的所有应用程序，可能以不可预测的方式。
进入共享库文件夹路径可以获得一些轻微的初始便利，但是您失去的是选择：一次只影响一个Web应用程序的选择。我建议你将你的jar放在你的网络应用程序中，包含得很好并与其他网络应用程序分开。这将使它们更可靠，您将发现框架升级更容易处理。从长远来看，你会更开心，我向你保证。