在 IBM websphere 8.5 中放置属性文件的最佳位置？答案

【问题标题】：best place to put properties file in IBM websphere 8.5?在 IBM websphere 8.5 中放置属性文件的最佳位置？
【发布时间】：2014-05-23 17:48:50
【问题描述】：

在我们现有的应用程序属性文件嵌入到一个 jar 文件中，我们决定将属性文件移到耳朵（应用程序）之外，将属性文件放在 IBM websphere 8.5 中的最佳位置是什么？这样我就可以使用 WAS 环境变量检索路径，并且文件应该对集群中的所有节点都可用..

【问题讨论】：

标签： java jakarta-ee properties websphere websphere-8

【解决方案1】：

在讨论中只有我的 2 美分。

为了快速简便的解决方案，我不会将属性文件放在 WAS_HOME/classes 中，而是放在 PROFILE_ROOT/properties 中 - 此文件夹位于类路径中，无论如何它都用于存储属性。 /classes 的一个好处是它的范围是配置文件，因此如果您有不同的配置文件，例如用于测试或集成，它们可能有不同的设置。

对于“纯”WebSphere 解决方案，这将允许通过控制台管理属性，您可以查看资源环境提供程序（但它的解决方案相当长、复杂）： http://www.ibm.com/developerworks/websphere/library/techarticles/0611_totapally/0611_totapally.html

【讨论】：

我在 PROFILE_ROOT/properties 目录中添加了一个新的属性文件，但是当我的应用程序搜索该文件时，我收到了 FileNotFound 异常。另一方面，应用程序可以找到现有的属性文件。我是否需要执行任何操作才能识别新文件？
@SreeramJayan 你使用getResourceAsStream() 方法来获取输入流吗？您是如何尝试加载属性的？
我使用 FileInputStream 加载属性文件。
@SreeramJayan 这就是原因:-)。因为该文件夹不在“文件路径”上，而是在类路径上。您需要根据需要将方法替换为 ServletContext 或 ClassLoader 中的 getResourceAsStream()。
但是我怎么能用 FileInputStream 加载同一目录中的其他属性文件呢？

【解决方案2】：

与（当前）接受的答案相反，我认为将任何内容放在WAS_HOME/classes 下是一种不鼓励的做法。 IBM 经常使用此目录来放置被认为是 WAS 和相关产品“内部”的类/JAR 文件（例如，某些版本的 WebSphere Portal 将 JAR 文件放置在该目录中）。

此外，将项目放在WAS_HOME/classes 中可以使项目可用于在此 WAS 安装创建的所有 WAS 配置文件上运行的所有应用程序。你无法改变这种行为；这就是 WAS 的设计方式。这是得出结论WAS_HOME/classes 应保留供 WAS 内部使用的另一个原因。

这个论点可以推广到WAS_HOME 下的几乎任何位置：用户文件（即不是由软件供应商提供的文件）不应驻留在产品安装程序管理的位置/卸载程序。 WAS_HOME 层次结构由 IBM Installation Manager（或 WAS 安装程序，取决于所讨论的 WAS 版本）管理。我不会把我的任何文件放在那里。

现在，回到你的问题。如果您必须让您的属性文件“松散”（即不包含在任何特定的 EAR 中），您最好的选择是执行以下操作：

在 WAS 目录树之外创建一个目录并将您的文件放在那里。
在 WAS 中，创建共享库定义。
将您创建的目录添加到共享库。
将共享库附加到服务器或您希望属性文件可用于的应用程序：
- 要将共享库附加到服务器，请在服务器上创建一个新的 Classloader 元素并将共享库附加到它。
- 要将共享库附加到应用程序，请通过在管理控制台中编辑 EAR 的属性或通过脚本化部署参数来执行附加。

【讨论】：

投反对票的人：想解释一下我的回答有什么问题吗？
嗨，对不起。我没有解释，因为当时我正在玩手机。出于几个原因，我对你的回答投了反对票。
出于几个原因，我对您的回答投了反对票。 1) 他对他的问题非常具体，他提出了一个应该对集群中的所有节点都可用的解决方案。 2) 他没有提到任何关于 WAS 门户或其他产品的内容，因此您在此目录被其他产品使用的观点只是担心可能永远不会发生的事情（大多数情况下）。 3）共享库解决方案要复杂得多，并且在这种情况下会出错（如果您只想要一个应用程序，它肯定是有效的。可以访问属性而不是整个集群）。
我尊重你的方法，但我可能会说我是那种喜欢简单而不是试图在解决方案中完全合规和完美的人。 aka - 在性能成为问题之前，我更喜欢易于使用和编码的清晰性。
@Isaac 感谢您的回答，如果仅在门户服务器中放入类文件夹是问题..，我仍然觉得当前接受的答案比共享库容易，因为我没有使用任何门户服务器..

【解决方案3】：

我使用的另一个解决方案是将 URL 资源引用添加到您的应用程序 web.xml。例如“网址/属性”。

然后使用管理控制台在 Websphere 中定义 URL，以指向“file:///dev.properties”或“file:///test.properties”等。

然后在部署时，将 URL 引用映射到适当的 websphere URL 定义。

现在，您的代码可以对 URL 进行 jndi 查找。

这样做的好处是您可以部署单个代码库，并在部署时进行自定义以指向不同的 URL。

【讨论】：

我更喜欢应用程序配置的最佳实践模式。更多信息请访问ibm.com/support/knowledgecenter/SSAW57_8.5.5/…
@BenAsmussen 嗨，你能详细说明一下吗？我看了你提供的链接，这和我描述的差不多？可能我描述的不是很好:-(
您的解释是正确的，但是从您的帖子中配置的方式不是很清楚。因此，IBM 提供了 URL 位置加载的链接和注释。 :-)

【解决方案4】：

您可以为此使用类加载器目录。我将使用 $WEBSPHERE_HOME/AppServer/classes 下的目录类（您可能需要创建）并将您的属性放在那里。您应该能够从您的任何应用程序/服务器中找到它们。

查看Class loaders page.

【讨论】：

您可能希望阅读我的回答，了解为什么不鼓励将项目放在 WAS_HOME/classes 中。
我不同意你在这种情况下的论点。如果他询问如何将特定应用程序的属性外部化，那么我会使用您在回答中提到的共享库。但他非常具体地要求提供一个选项以使属性在集群中的所有节点上可用。
仍然无济于事。对于水平集群，无论如何您都必须在每个物理节点上执行此操作。 AppServer/classes 方法不能节省工作；它带来的限制多于好处。
@Isaac - 我仍然认为在这种特定情况下（对于集群中的所有服务器），它比必须在所有应用程序中配置共享库更容易、更实用、更少受人为错误的影响并且更好.共享库在水平集群中也有完全相同的问题（你必须在所有物理节点+应用程序中这样做）。

【解决方案5】：

试试这个

创建一个目录（您选择的位置）来保存属性文件。
将目录添加到 WebSphere CLASSPATH。
从 CLASSPATH 加载属性文件。

【讨论】：

【解决方案6】：

如果属性值不是特定于集群的一个节点或属性值是密码，则数据库是放置属性的最佳位置。对于像密码这样的属性，我建议您将属性值设置为 WAS 中的 jndi 属性。使用公共配置从两个源中读取。在您的代码库中有一个 .property 文件，它将覆盖 db 和 jndi 中的值。这样，您的开发人员可以在开发中覆盖 db/jndi 值。

【讨论】：