Weblogic在从9.2.1迁移到9.2.3时强制重新编译EJB

我使用Weblogic的EJBComplient和WebLogic9.2.1编译了一些EJB。 我们的客户使用Weblogic 9.2.3。 在服务器启动期间，Weblogic发出以下消息：

因此，服务器启动需要1.5小时而不是20分钟。下一次服务器启动需要完全相同的时间，这意味着Weblogic不会缓存重新编译的产品。不用说，我们无法仅为该特定客户将所有EJB重新编译到9.2.3，因此我们需要一个现场解决方案。
我的问题是：
1.有没有办法告诉Weblogic让这些EJB JAR保持原样并避免在服务器启动期间重新编译？
2.我可以告诉Weblogic缓存重新编译的EJB以避免长时间重启吗

---

我们目前的解决方法是在EAR创建和部署之前编写一个手动重新编译的脚本（通过简单地运行java weblogic.appc），但我们宁愿避免在生产中使用此解决方案。

我花了大量时间研究，解决了这个问题 我在从weblogic8迁移到10时遇到了这个问题 此时，您可能已经了解了与oracle weblogic技术支持打交道的痛苦

不幸的是，他们没有服务器配置设置来禁用此功能

你需要做两件事

步骤1.如果打开EJBJAR文件，您可以看到

ejb jar.xml=3435671213

com.mycompany.myejbs.ejb.dummeyejbservice=2691629828

weblogic ejb jar.xml=3309609440

WLS\U发布版本\U构建版本\U 24=10.0.0.0

您可以看到每个ejb名称的hadcodes。将这些hadcodes设为零。 打包jar文件并将其部署到服务器上

com.mycompany.myejbs.ejb.dummeyejbservice=0

weblogic ejb jar.xml=0

这只是weblogic.appc在每个ejb jar中保存的一个标记文件，用于触发重新编译 在服务器启动期间，我自动将这些hadcodes设置为零。 即使多次执行appc，每个ejb的哈希代码也保持不变 如果您添加一个新的EJB类或删除一个类，这些条目将添加到此标记文件中

注1： 如何获取此文件？ 如果打开域/yourdomain/servers/yourServerName/cache/EJBCompilerCache/XXXXXXXXX 您将看到每个ejb的这个文件。weblogic在重新编译后将hashcodes设置为零

注2： 当您使用appc生成EJB时，请使用-output C:\myejb将它们生成到分解目录 而不是C:\myejb.jar。这样您就可以使用标记文件了

第二步。 您还需要weblogic提供的修补程序。安装修补程序时，您会看到如下消息 “路径CRXXXXXX已成功安装。消除appc的EJB重新编译”。 我不记得补丁号，但你可以要求weblogic

您需要使用这两个步骤来修复问题。修补程序仅修复部分问题 祝你好运

干杯

---

raj

EJB中的标记文件是WLU生成的

只是为了更新我们使用的解决方案-最终我们选择在客户站点重新编译EJB一次，而不是弄乱EJB的内部标记（我们不希望Oracle说他们无法支持此场景产生的问题）

我们创建了两个KSH脚本-第一个脚本迭代所有EJB JAR，将它们复制到tempdir，然后通过运行第二个脚本的多个实例并行地重新编译它们，第二个脚本只做一件事：

java-Drecompiler=yes-cp$CLASSPATH weblogic.appc$1

（当然有错误处理：）)

---

此解决方案将编译时间从70分钟缩短到15分钟。在此之后，我们重新创建EAR文件，并使用newejb重新部署它。我们每个UAT环境创建一次，因此我们在这里节省了很多时间（55分钟X每滴环境数X滴数）

为什么您不使用与您的客户相同的版本？@Pascal:我们的客户坚持使用此版本，我们无法“支持”它，因为它需要大量测试，没有人会为此付费。我明白了。那么，谁来为花在改善创业时间上的时间买单呢幸运的是，这个特定的客户正在为解决方案付费，而没有实际的回归测试。（我们期望从BEA获得向后兼容性）多亏了，最终我们选择在客户站点重新编译EJB一次，而不是弄乱EJB的内部标记（我们不希望Oracle说他们无法支持由此场景衍生的问题）。