我有一些使用Weblogic的EJBC complient与Weblogic 9.2.1编译的EJB。
我们的客户使用Weblogic 9.2.3。
在服务器启动期间，Weblogic提供以下消息：
<BEA-010087> <The EJB deployment named: YYY.jar is being recompiled within the WebLogic Server. Please consult the server logs if there are any errors. It is also possible to run weblogic.appc as a stand-alone tool to generate the required classes. The generated source files will be placed in .....>
因此，服务器启动需要1.5小时而不是20分钟。下一个服务器启动时间完全相同，这意味着Weblogic不会缓存重新编译的产品。毋庸置疑，我们无法仅针对此特定客户将所有EJB重新编译为9.2.3，因此我们需要现场解决方案。
我的问题是：
1.有没有办法告诉Weblogic保留那些EJB jar，并避免在服务器启动时重新编译？
2.我是否可以告诉Weblogic缓存重新编译的EJB以避免长时间重启？
我们当前的解决方法是编写一个脚本，在EAR创建和部署之前手动执行此重新编译（只需运行 java weblogic.appc＆lt; jar-name＆gt; ），但我们宁愿避免在生产中使用这种解决方案。
答案 0 :(得分：0)
我通过花费大量时间研究来解决这个问题 并反编译一些类。我从weblogic8迁移到10时遇到这种情况 到这个时候你可能已经理解了处理oracle weblogic技术支持的痛苦。
不幸的是，他们没有服务器配置设置来禁用此
你需要做两件事
步骤1.如果打开EJB jar文件，可以看到
ejb-jar.xml中= 3435671213
com.mycompany.myejbs.ejb.DummyEJBService = 2691629828
WebLogic的EJB-jar.xml中= 3309609440
WLS_RELEASE_BUILD_VERSION_24 = 10.0.0.0
你会看到每个ejb名称的这些hascodes。将这些hadcodes设为零。 打包jar文件并将其部署在服务器上。
com.mycompany.myejbs.ejb.DummyEJBService = 0
WebLogic的EJB-jar.xml中= 0
这只是一个标记文件，weblogic.appc保存在每个ejb jar中以触发重新编译 在服务器启动期间，我自动执行这些将这些编码设置为零的过程。 即使您多次执行appc，此哈希码对于每个ejb仍保持相同 如果添加新EJB类或删除类，则将这些条目添加到此标记文件
注1： 怎么得到这个文件？ 如果你打开domains / yourdomain / servers / yourServerName / cache / EJBCompilerCache / XXXXXXXXX 您会看到每个ejb.weblogic的这个文件在重新编译后使哈希码为零
注2： 使用appc生成EJB时，使用-output C：\ myejb将它们生成到展开的目录 而不是C：\ myejb.jar。这样你可以使用标记文件
第二步。 你还需要一个来自weblogic的PATCH。当你安装补丁时，你会看到一些这样的消息 “PATH CRXXXXXX安装成功。为appc取消了EJB重新启动”。 我不记得补丁号码，但你可以请求weblogic。
您需要使用这两个步骤来解决问题。修补程序仅修复问题的一部分 古德勒克!!
欢呼声 拉吉
答案 1 :(得分：0)
EJB中的标记文件是WL_GENERATED
答案 2 :(得分：0)
只是为了更新我们使用的解决方案 - 最终我们选择在客户站点重新编译EJB一次，而不是弄乱EJB的内部标记（我们不希望Oracle说它们不能支持从这种情况派生的问题） 。
我们创建了两个 KSH 脚本 - 第一个遍历所有EJB jar，将它们复制到 temp 目录，然后通过运行多个实例并行重新编译它们第二个脚本只做一件事：java -Drecompiler=yes -cp $CLASSPATH weblogic.appc $1（当然有错误处理:)）
此解决方案将编译时间从70分钟缩短为15分钟。在此之后，我们重新创建EAR文件并使用 new EJB重新部署它。我们在几个UAT环境创建中执行此操作一次，因此我们在这里节省了相当多的时间（55分钟X数每个下降的数量x数量的滴数）