Java 如何为在 Eclipse 中创建的应用程序将 WebSphere 类加载器策略设置为 PARENT_LAST？

How can I set a WebSphere classloader policy to PARENT_LAST for an app created in Eclipse?

提问by butallmj

Our company is currently using RAD to develop our Java apps, but we're looking to move to Eclipse with the WebSphere Developer Tools. The pilot for our transition is going pretty well, except we're running into a classloader policy issue for new applications that are originally created in Eclipse, not RAD. Our projects that were originally created by RAD are deployed with the correct classloader policy (PARENT_LAST) when published via Eclipse because we originally used the Deployment Descriptor Editor in RAD which set the proper classloader policy in /src/main/application/META-INF/ibmconfig/cells/defaultCell/applications/defaultApp/deployments/defaultApp/deployment.xml. But now with Eclipse & WebSphere Developer Tools, we no longer have the nice Deployment Descriptor Editor UI to create or modify this file for us (apparently it's not included with the WDT plugin).

我们公司目前正在使用 RAD 来开发我们的 Java 应用程序，但我们希望通过 WebSphere Developer Tools 迁移到 Eclipse。我们的过渡试点进展顺利，只是我们遇到了最初在 Eclipse 而非 RAD 中创建的新应用程序的类加载器策略问题。我们最初由 RAD 创建的项目在通过 Eclipse 发布时使用正确的类加载器策略 (PARENT_LAST) 进行部署，因为我们最初使用 RAD 中的部署描述符编辑器在/src/main/application/META-INF/ibmconfig/cells/defaultCell/applications/defaultApp/deployments/defaultApp/deployment.xml. 但是现在有了 Eclipse 和 WebSphere 开发人员工具，我们不再有漂亮的部署描述符编辑器 UI 来为我们创建或修改这个文件（显然它不包含在 WDT 插件中）。

So, my question then is what is the best way to go about setting this classloader policy? We still need some new apps to have the classloader policy of PARENT_LAST set when we deploy them to our local servers. Our team has though about this a bit and we can see 4 options at the moment.

那么，我的问题是设置此类加载器策略的最佳方法是什么？当我们将它们部署到我们的本地服务器时，我们仍然需要一些新的应用程序来设置 PARENT_LAST 的类加载器策略。我们的团队对此有所考虑，目前我们可以看到 4 个选项。

1. Open the Admin Console after every publish and change it. This would be a huge pain, and is pretty much not even a real option.
2. Change the server profile setting to use a PARENT_LAST classloader policy for all apps. This however is not the case for all the apps at our company, and would not work for all groups.
3. Run a jython script after every publish to set the classloader policy. This is slightly better than option 1, but not by much.
4. Manually create a deployment.xml file in the same location as the other apps created by RAD with the same structure as the deployment.xml files created by RAD, and modify it as necessary for each app.

1. 每次发布后打开管理控制台并进行更改。这将是一个巨大的痛苦，甚至几乎不是一个真正的选择。
2. 更改服务器配置文件设置以对所有应用程序使用 PARENT_LAST 类加载器策略。然而，这并非适用于我们公司的所有应用程序，也不适用于所有群体。
3. 每次发布后运行 jython 脚本以设置类加载器策略。这比选项 1 略好，但相差不大。
4. 在与 RAD 创建的其他应用程序相同的位置手动创建一个 deployment.xml 文件，其结构与 RAD 创建的 deployment.xml 文件相同，并根据需要针对每个应用程序进行修改。

Option 4 seems to be the best of the bunch, but it's still a manual process and somewhat error prone. Even if most of our developers can grok this approach for new apps, it would be most ideal if this were a simple one button click type process.

选项 4 似乎是最好的，但它仍然是一个手动过程，并且有点容易出错。即使我们的大多数开发人员可以为新应用程序理解这种方法，如果这是一个简单的一键单击类型过程，那将是最理想的。

So given the fact that IBM has omitted the Deployment Descriptor Editor from the WDT plugin it would seem as if option 4 is our only hope, but I'll ask once more, is there any other better way to set a WebSphere classloader policy to PARENT_LAST for an app when that app is created in Eclipse? Any help is appreciated, thanks.

因此，考虑到 IBM 从 WDT 插件中省略了部署描述符编辑器的事实，似乎选项 4 是我们唯一的希望，但我再问一次，是否有其他更好的方法将 WebSphere 类加载器策略设置为 PARENT_LAST对于在 Eclipse 中创建该应用程序时的应用程序？任何帮助表示赞赏，谢谢。

采纳答案by Isaac

Well, Eclipse is free, while Rational Application Developer costs about $5,000 per year (per developer). The nice Deployment Editor (which wasn't that nice. It tends to include all sorts of things that aren't needed. Who needs that Derby DataSource defined there, anyway?) is one of the things you have to give up for saving tons of cash on an annual basis.

好吧，Eclipse 是免费的，而 Rational Application Developer 每年的费用约为 5,000 美元（每位开发人员）。不错的部署编辑器（不是那么好。它往往包含各种不需要的东西。无论如何，谁需要在那里定义的 Derby DataSource？）是您必须放弃的东西之一，以节省大量资源每年的现金。

I'm digressing.

我跑题了。

Option (1) is a complete no-no. You don't want to rely on manual steps for deployments; you should strive to automate deployments to the extent possible.

选项（1）是一个完全的禁忌。您不想依赖手动步骤进行部署；您应该努力尽可能实现自动化部署。

Option (2) mightdo. I am not sure which flavour of WebSphere you're using, but if you're using the Network Deployment edition, then you can design a WebSphere topology that consists of multiple servers and clusters. You could, theoretically, come up with such a topology whereby PARENT_LASTapplications run on a specific server (or cluster) and PARENT_FIRSTapplications run on another server (or cluster).

选项（2）可能会。我不确定您使用的是哪种类型的 WebSphere，但是如果您使用的是 Network Deployment 版本，那么您可以设计一个由多个服务器和集群组成的 WebSphere 拓扑。从理论上讲，您可以提出这样一种拓扑，即PARENT_LAST应用程序在特定服务器（或集群）上PARENT_FIRST运行，应用程序在另一台服务器（或集群）上运行。

You may be able to combine option (2) with a technical initiative to have all of your applications work with PARENT_LAST. This is the recommended approach if your application is using popular third-party libraries that WebSphere happens to use as well (for its own internal purposes). For example, if you're using Commons Lang, then you're already recommended to switch to PARENT_LASTbecause WebSphere uses its own internal copy of Commons Lang that might conflict with yours.

您可以将选项 (2) 与一项技术举措结合起来，让您的所有应用程序都使用PARENT_LAST. 如果您的应用程序正在使用 WebSphere 碰巧也使用的流行的第三方库（用于其自身的内部目的），那么这是推荐的方法。例如，如果您正在使用 Commons Lang，那么已经建议您切换到，PARENT_LAST因为 WebSphere 使用它自己的 Commons Lang 内部副本，这可能与您的冲突。

Option (3) - it's of course better than option (1) but isn't necessarily worse than option (2) if you can get your WebSphere topology right.

选项 (3) - 它当然比选项 (1) 好，但不一定比选项 (2) 差，如果您可以使 WebSphere 拓扑正确。

Option (4) is harder to implement but I believe it's the best approach overall:

选项 (4) 更难实施，但我相信这是总体上最好的方法：

1. It's a one-time setup effort for each EAR (and for each WAR that exists within the EAR).
2. Once it's done, deployment can easily be automated as no extra steps are needed.
3. If you're working with a local test environment to test your code, and you're rapidly publishing applications from your workspace into your local test environment, then this approach is the only approach (other than option (2)) that will work for you without extra manual work.

1. 对于每个 EAR（以及存在于 EAR 中的每个 WAR），这是一次设置工作。
2. 完成后，部署可以轻松自动化，因为不需要额外的步骤。
3. 如果您正在使用本地测试环境来测试您的代码，并且您正在快速将应用程序从您的工作区发布到您的本地测试环境中，那么此方法是唯一适用于的方法（选项 (2) 除外）您无需额外的手动工作。

If none works... consider paying $5,000 per year (per user) and get option (5) - use IBM's editor. Or, better off... hire someone to design an Eclipse plugin that will do that for you. Shouldn't take more than a week or two to develop.

如果没有效果……考虑每年支付 5,000 美元（每个用户）并获得选项 (5) - 使用 IBM 的编辑器。或者，最好...聘请某人设计一个 Eclipse 插件来为您做这件事。开发时间不应超过一两周。

回答by Peacock

Open the admin console within eclipse click server >> your server >> scroll down and under server infrastructure >> java process management select class loader >> select new you can change it here

在 Eclipse 单击服务器中打开管理控制台 >> 您的服务器 >> 向下滚动并在服务器基础结构下 >> java 进程管理选择类加载器 >> 选择新的您可以在此处进行更改

回答by jaybrubin

um nether answer is useful.

嗯，下一个答案很有用。

Go into WAS console and pick your application; example:

进入 WAS 控制台并选择您的应用程序；例子：

Enterprise Applications > my_application_ear > Class loader AND change the "class loader order and WAR class loader policy"

企业应用程序 > my_application_ear > 类加载器并更改“类加载器顺序和 WAR 类加载器策略”