我们有一个门户应用程序与一个主要的web应用程序上下文和许多次要的web应用程序上下文-插件。目前(非常简化)Main有自己的spring库，如果想要使用spring，插件也必须拥有它们。在common/shared tomcat上下文中，只有驱动程序和接口。
如果将spring库移到与spring可能间接使用或可能使用spring的其他库相关的公共上下文中，它会工作吗?比如hibernate，因为应用程序使用spring-tx等。hibernate是否也必须移动到公共/共享上下文中?
你怎么看，其他方面是什么?从spring应用程序上下文的角度来看，这样做要简单得多。
@RichW正确地指出，将Spring库放在Tomcat的公共类加载器中是一种不好的做法。而且很有可能行不通。
Java使用类加载器层次结构)。当请求类加载时，类加载器将在尝试使用自己的类路径加载类之前，从它的父类加载器递归地请求该类。这个过程一直持续到根类加载器(称为引导类加载器)。通过这种方式，从父类加载器引用的类总是优先于在层次结构更低的类加载器中引用的类。
需要注意的是，在这个过程中，类永远不会从子类加载器加载。因此，Spring需要的任何类也需要加载到公共类加载器中——包括asm、log4j、commons-logging和cglib (Spring依赖的所有类)。这将导致一大堆问题:特别是，在公共类路径中包含公共日志是一个非常麻烦的问题
如果您确实设法启动了Tomcat，那么在回收应用程序时就会遇到内存泄漏的问题。在tomcat中，应用程序是使用传统的垃圾收集来卸载的，因此，如果应用程序中有对某个类的引用，而该应用程序随后又重新启动了，那么该应用程序将不会进行垃圾收集。Spring和日志框架是保存类引用的主要候选框架，因此您可能会在几次应用程序重启后遭受OOM错误。
要做到这一点，唯一安全的方法是考虑使用成熟的应用服务器(比如JBoss as)，并将应用程序部署为EAR。如果您能够从Tomcat迁移到成熟的Java EE容器，那么一个选项就是使用捆绑可选类机制将所有内容打包为EAR。
然后你将把常见的jar移出WARs &
是的，我知道这很诱人。是的，它可以工作。但是，将特定于应用程序或特定于框架的库放在应用服务器的共享库文件夹中，有些人认为这是一种不好的做法，我同意。
在我看来，web应用程序应该包含自己的依赖关系(应用程序jar，框架jar等)。框架也有依赖关系，通常需要多个带有特定版本的jar。有时这些版本会改变，有时依赖关系也会改变。随着时间的推移，共享库文件夹将成为jar的厨房水槽，这将影响你所有的应用程序，也许以不可预测的方式。
选择共享库文件夹路径，你获得了一些小小的便利，但你失去的是选择:一次只影响一个web应用程序的选择。我建议你将jar保存在你的web应用程序中，与其他web应用程序保持良好的隔离。这将使它们更加可靠，并且您会发现框架升级更容易处理。从长远来看，你会更快乐，我保证。