好的，这是问题所在。我们使用旧版本的Tomcat（6.0.35），因为我们的linux版本（ubuntu 12.04）没有更新版本的存储库。不幸的是，6.0.35中存在影响我们的错误（https://issues.apache.org/bugzilla/show_bug.cgi?id=53725）。 IT不希望/不能改变tomcat版本。他们想要使用包管理系统，他们不想重建tomcat。他们无法在一大堆服务器上维护这样的东西，我们也不特别想禁用Gzip。我们可以处理腐败，直到我们最终升级。
所以有了这个背景，真正的问题。修复此错误的更改位于一个单独的类中。我们提出了一个疯狂的解决方案（可能永远不会看到生产，但更多的是“这将是如此可怕，让我们试试吧！”有点想法），我们如何编译类的固定版本并热切换它毕竟，tomcat和我们的项目使用相同的JVM。
这是可行/可能/有点疯狂吗？
一些障碍。我们使用的是Java 6.新类添加了方法和字段。我不确定tomcat是否会保留它。
答案 0 :(得分：0)
在大多数情况下，这实际上是不合理的。干净地卸载类然后加载替换的唯一方法是让用于加载该特定类的ClassLoader被垃圾收集。这将要求您删除对ClassLoader加载的任何类的所有引用（可能至少是TomCat的所有类），并使用ClassLoader重新加载它们，ClassLoader加载所有类，如正常，除了您“修复”的类。您必须使它加载该类而不是旧类，同时仍允许其他类正常加载。
简而言之，它可能需要深入研究java ClassLoaders。我建议你实际上不要尝试这个，因为如果没有关闭TomCat服务器，它肯定会无法正常工作（因为你必须重新加载所有TomCat的类）。
答案 1 :(得分：0)
谁正在进行解压缩，Tomcat或应用程序？如果它是应用程序，只需将错误的类的副本复制到src / main / java中项目类路径的根目录，然后将该类的修补版本放在那里。
打包后，修补的类将位于WEB-INF / classes中，并覆盖服务器中的版本。但是仅从应用程序的角度来看，它被覆盖，服务器无法看到修补版本，仍然可以看到有缺陷的版本。
如果它的tomcat本身需要解压缩，那么在不修改服务器的情况下就无法修复它。
但是如果它的应用程序确实可以解压缩它，那么没有义务使用服务器的库我们可以使用我们自己的更新副本，通常不在补丁中，而是在WEB-INF / lib的jar中 - 服务器就是为此而设计的。