与大多数开发人员一样，我们对方法的主体进行了微小的更改，并希望在不必停止和启动容器的情况下对其进行测试。 Tomcat的。 JVM提供的热交换功能看起来很有希望，我们希望确保不重新加载Tomcat和Spring上下文。当我们有一个模块maven项目时，这非常有效。但是，当我们处理风格
的多模块maven web项目时kilo
-kilo-business
-kilo-common
-kilo-dao
-kilo-web
我们希望对依赖模块中的类的方法体进行更改（比如kilo-business模块所依赖的kilo-web模块），热交换会导致重新加载tomcat的上下文，从而也是春天的。如果对kilo-web模块本身中的类进行了更改，则不会重新加载上下文。这让我相信，因为我有一个现在已经在WEB-INF/lib中修改过的jar，Tomcat正在以不同的方式处理它，以便WEB-INF/classes中的类发生变化。当然，这种推论是经验性的 - 如果有人可以指出真实的来源及其推理，那将是很好的。
更重要的是，有什么想法可以避免这种情况发生？如果我们在WEB-INF/classes中拥有相关广告的内容，这个问题会消失吗？我无法找到一种方法来使eclipse WTP插件将依赖项目部署为WEB-INF/classes中的展开目录。
我们听说过JRebel提供的好东西，但是想确保充分利用JVM本身提供的功能。
提前致谢！
答案 0 :(得分：1)
实际上，tomcat实例是通过eclipse在调试模式下运行的。当我在kilo-web中更改类的方法体时，JVMTI执行了热代码交换，因此更改反映在输出中，但是WEB-INF / classes中的类本身未被修改（从最后修改的时间戳）。对于像kilo-common这样的依赖模块也会发生同样的情况，尽管我间歇性地注意到它（但仍然有效）。毕竟是红鲱鱼 - 我道歉。
更一般地说，在听完Jevgeni Kabanov's talk about classloaders之后，重新加载Tomcat使用的类的vanilla方法需要重新加载上下文，因为创建了一个全新的类加载器，它从现有的类加载器复制状态（并运行到带有问题的怪癖中）相关的泄漏）。总的来说，一个很棒的视频。