我在质量保证的JBoss 4.2中遇到了这种令人讨厌的行为，我想在我们投入生产之前把它扼杀在萌芽状态并找到其他一些角落。
jsp调用具有以下签名的方法：
public void methodName(String arg)
这改为：
public void methodName(String arg, Object... args)
预先存在的JSP通过以下方法调用此方法：
methodName("param");
在部署修改后的代码时，JBoss没有重新编译JSP，这导致了QA崩溃。向jsp添加一个愚蠢的注释修复了问题（JBoss认识到JSP已更改并重新编译它）。
JBoss上是否有设置强制重启时重新编译JSP？
编辑：为了澄清答案中的一些要点，设置是JSP是战争的一部分，这是一个耳朵的一部分。耳朵里有所有的课，放在罐子里。
关于预编译的愿望，如果系统不认为jsp需要编译，会预编译强制重新编译吗？它似乎并非如此。这里的错误不是一个compliation错误，它是一个方法调用错误，因为“更改”（在字节代码级别，而不是真正在代码级别）方法签名。
附录：请注意，我们最近在生产中遇到过，即使已经接受了答案的标志设置，JSP也没有重新编译，即使JSP确实发生了变化。那里的主要错误，但无论如何，JBoss正常关闭。此时它将成为JBoss的旧版本，但如果您仍在使用它，删除工作内容和tmp目录是唯一可以确定的方法。
我并没有改变接受的答案，因为它确实达到了问题的目的。 JBoss错误是一个单独的问题。
答案 0 :(得分：11)
如果JSP是WAR的一部分，而WAR是部署为jar的EAR的一部分，那么我不清楚为什么你的JSP没有被重新编译。 war文件中的JSP是否比上次部署的JBoss编译的类文件具有更新的时间戳？如果没有，在部署之前，无法触摸JSP作为构建WAR / EAR的一部分。 [我指的是使用Unix“touch”命令，而不是手动触摸每个JSP文件。]
或者，$ JBOSS / server / default / deploy / jboss-web.deployer / META-INF / jboss-service.xml中的DeleteWorkDirOnContextDestroy设置可能就是您要查找的内容。默认情况下为false，但将其设置为true可能就是您所需要的。我认为这应该在重新部署时删除JSP的类文件，以便在首次访问每个JSP时重新创建它们。
有关详细信息，请参阅https://jira.jboss.org/jira/browse/JBAS-3358。
答案 1 :(得分：1)
我不知道一个设置，但删除JBoss实例的工作目录中生成的Java类文件将导致JSP在下次调用时重新编译。
答案 2 :(得分：1)
您可以更改JBoss启动脚本，以显式删除存储已编译JSP的“tmp”和/或“work”目录。然后JBoss别无选择，只能重新编译它们。
不是很微妙，但它可以完成这项工作。
答案 3 :(得分：0)
您可以选择在构建时预编译所有jsp。这会很快标记出任何编译错误。
您也可以在制作中执行此操作 - 加快首次访问速度，但我觉得您希望QA步骤比其他任何内容更多。如果是这样，您可以将预编译步骤添加到您选择的构建工具中的测试阶段 - 以及您的CI环境。这将确保不编译的jsp不会使其失去测试。
有关运行预编译任务的详细信息，请参阅此处：
希望这有帮助。
答案 4 :(得分：0)
某些JSP容器（根据JSP 1.2规范的8.4.2节）支持预编译JSP页面的功能。
要预编译JSP页面，请使用查询字符串？jsp_precompile
访问该页面http://hostname.com/mywebapp/mypage.jsp?jsp_precompile
不会执行JSP页面。如果容器支持预编译，则必要时将编译JSP页面。
答案 5 :(得分：0)
Pablojim走在正确的轨道上。您只需要更多信息即可全面了解正在发生的事情。这是我理解的方式。
在prod中，你已经改变了一个需要重新编译其他jsps的jsp。为了重新编译它们，必须发生以下两件事之一
如果您仍需要验证所有jsps是否有效，则所有jsps都需要precompiled using an ant task。这也允许您在war文件中使用预编译的jsps部署war文件。这应该可以解决你的问题。
如果您的文件未部署在war文件中，而是以展开格式部署，则应在war文件中seriously consider packaging your web app进行部署。这使它成为在环境之间部署的一个很好的包。