代码之家 › 专栏 › 技术社区 › RonK

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

ejb weblogic

RonK · 技术社区 · 14 年前

我有一些用WebLogic的EJBC兼容WebLogic9.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创建和部署之前(只需运行 JavaWebLogiC.AppC& lt;jar名称& GT; ,但我们宁愿避免在生产中使用此解决方案。

3 回复 | 直到 14 年前

rajdevar 14 年前

我花了很多时间研究这个问题并反编译一些类。我在从WebLogic8迁移到10时遇到了这个问题。此时,您可能已经了解了处理Oracle WebLogic技术支持的痛苦。

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

你需要做两件事

步骤1.如果打开EJB JAR文件,可以看到

ejb jar.xml=3435671213

com.mycompany.myejbs.ejb.dummeyjbservice=2691629828

weblogic ejb jar.xml=330969440

WLS_版本_内部版本_24=10.0.0.0

您会看到每个EJB名称都有这些hadcodes。将这些hadcodes设为零。打包JAR文件并将其部署到服务器上。

com.mycompany.myejbs.ejb.dummeyjbservice=0

weblogic ejb jar.xml=0

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

注1: 如何获取此文件? 如果打开域/yourdomain/servers/yourservername/cache/ejbcompilercache/xxxxxxx 您将看到每个EJB的这个文件。WebLogic在重新编译后使哈希代码变为零。

注2: 使用appc生成EJB时,使用-output c:\myejb将它们生成到分解目录而不是c:\myejb.jar.This way you can play around with the marker file

步骤2。另外,您还需要WebLogic的一个补丁。安装补丁时,您会看到如下消息 “已成功安装路径crxxxx。消除AppC的EJB重新计算”。我不记得补丁号,但你可以请求WebLogic。

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

干杯拉吉

rajdevar 14 年前

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

RonK 14 年前

只是为了更新我们使用的解决方案——最终我们选择在客户站点重新编译EJB,而不是处理EJB的内部标记(我们不希望Oracle说他们不能支持从这个场景派生的问题)。

我们创造了两个 KSH 脚本-第一次迭代所有EJB JAR,将它们复制到 临时雇员 dir,然后通过运行第二个脚本的几个实例来并行地重新编译它们,该脚本只做一件事: java -Drecompiler=yes -cp $CLASSPATH weblogic.appc $1 (当然有错误处理:)

此解决方案将编译时间从70分钟缩短到15分钟。之后,我们重新创建EAR文件并使用新的 EJBs。我们每创建几个UAT环境就这样做一次,因此我们在这里节省了相当多的时间(55min x num of envs per drop x num of drops)