能够在热交换类时避免在 tomcat 中重新加载 spring 上下文答案

【问题标题】：Ability to avoid reloading spring context in tomcat when hot swapping classes能够在热交换类时避免在 tomcat 中重新加载 spring 上下文
【发布时间】：2012-09-06 23:30:23
【问题描述】：

作为大多数开发人员，我们对方法的主体进行了微小的更改，并希望在不必停止和启动容器的情况下对其进行测试。雄猫。 JVM 提供的热交换功能看起来很有希望，我们希望确保 Tomcat 和 Spring 上下文都不会重新加载。当我们有一个单一的模块 maven 项目时，这非常有效。但是，当我们处理风格的多模块 maven web 项目时

kilo
-kilo-business
-kilo-common
-kilo-dao
-kilo-web

并且我们希望更改依赖模块中的类的方法体（比如kilo-web 模块所依赖的kilo-business 模块），热交换会导致tomcat 的上下文重新加载，因此也会导致spring 的重新加载。如果对 kilo-web 模块本身中的类进行了更改，则不会重新加载上下文。这让我相信，因为我有一个现在已经在WEB-INF/lib 中修改的 jar，Tomcat 处理它的方式与WEB-INF/classes 中的类发生变化时不同。当然，这种推论是经验性的——如果有人能指出真实的来源及其推理，那就太好了。

更重要的是，有什么想法可以避免这种情况发生吗？如果我们在 WEB-INF/classes 中有依赖 jar 的内容，这个问题会消失吗？我无法找到一种方法让 eclipse WTP 插件将依赖项目部署为WEB-INF/classes 中的爆炸目录。

我们听说过 JRebel 提供的好东西，但想确保充分利用 JVM 本身可以提供的功能。

提前致谢！

【问题讨论】：

您是说在更新WEB-INF/classes 中的类时，您的经验是Tomcat 不重新加载上下文但新类可用？
@mattb 是的，看起来是这样。
@mattb 我之前错了 - jdwp 也在做一些魔术。

标签： java eclipse spring tomcat maven

【解决方案1】：

实际上，tomcat 实例是通过 eclipse 在调试模式下运行的。当我在kilo-web 中更改类的方法体时，JVMTI 进行了热代码交换，因此更改反映在输出中，但 WEB-INF/classes 中的类本身没有被修改（从上次修改的验证时间戳）。像kilo-common 这样的依赖模块也会发生同样的情况，尽管我间歇性地注意到它（但仍然有效）。毕竟这是一个红鲱鱼 - 我很抱歉。

更一般地说，在听完 Jevgeni Kabanov's talk about classloaders 之后，Tomcat 使用的重新加载类的普通方法需要重新加载上下文，因为创建了一个全新的 Classloader，它从现有 Classloader 复制状态（并遇到相关泄漏的怪癖）。总的来说，一个很棒的视频。

【讨论】：