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

best place to put properties file in IBM websphere 8.5?

提问by invariant

In our existing application properties file is embedded in a jar file ,we decided to move properties file outside of ear(application) , what is the best place to put properties file in IBM websphere 8.5 ? so that i can retrieve path with WAS Environment variables and file should be available to all nodes in a cluster ..

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

采纳答案by groo

You can use the classloader directories for that. I would use the directory classes (you might need to create) under $WEBSPHERE_HOME/AppServer/classes and drop your properties there. You should than be able to find them from any of your applications / servers.

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

Check the Class loaders page.

检查类加载器页面。

回答by DwB

try this

尝试这个

1. Create a directory (location of your choosing) to hold the properties file.
2. Add the directory to the WebSphere CLASSPATH.
3. Load the properties file from the CLASSPATH.

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

回答by user3669895

Database is the best place to put the properties if the property values are not specific to one node of the cluster or the property value is a password. For properties like passwords I would suggest you set up the property values as jndi properties in the WAS. Use commons configuration to read from both the sources. Have a .property file in your codebase that will override the values from both db and jndi. That way your developers can override the db/jndi values in development.

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

回答by Isaac

Contrary to the (currently) accepted answer, I argue that placing anything under WAS_HOME/classesis a discouraged practice. This directory is often used by IBM to place classes/JAR files that are considered "internal" to WAS and related products (for instance, certain versions of WebSphere Portal place JAR files in that directory).

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

Also, placing items in WAS_HOME/classesmakes the items available to all applicationsrunning on all WAS profilescreated off this WAS installation. You can't change that behaviour; that's how WAS is designed. That's another reason to conclude that WAS_HOME/classesshould be reserved for WAS internal use.

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

This argument can be generalized to practically anylocation under WAS_HOME: user files (that is, files not provided by the software vendor) should not reside in locations that are managed by the product's installer/uninstaller. The WAS_HOMEhierarchy is managed by IBM Installation Manager (or the WAS Installer, depending on the WAS version in question). I wouldn't put any of my files anywhere there.

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

Now, back to your question. If you must have your property files "loose" (that is, not included with any particular EAR), your best bet is to do the following:

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

1. Create a directory outsidethe WAS directory tree and place your files there.
2. In WAS, create a Shared Library definition.
3. Add the directory you created to the Shared Library.

4. Attach the Shared Library to either the server or the application(s) you'd like your property files to be available to:

   • To attach the Shared Library to the server, create a new Classloader element on the server and attach the shared library to it.
   • To attach the Shared Library to the application, perform the attachment through editing the EAR's properties in the administration console, or through scripted deployment parameters.

1. 在 WAS 目录树之外创建一个目录并将您的文件放在那里。
2. 在 WAS 中，创建共享库定义。
3. 将您创建的目录添加到共享库。

4. 将共享库附加到您希望属性文件可用于的服务器或应用程序：

   • 要将共享库附加到服务器，请在服务器上创建一个新的类加载器元素并将共享库附加到它。
   • 要将共享库附加到应用程序，请通过在管理控制台中编辑 EAR 的属性或通过脚本化部署参数来执行附加。

回答by Gas

Just my 2 cents in the discussion.

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

For quick and easy solution I'd put the property file not to the WAS_HOME/classes but to the PROFILE_ROOT/properties - this folder is on the classpath, and its used to store properties anyway. The one benefit over /classes is that is scoped to profile, so if you have different profiles for example for test or integration they may have different settings.

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

And for 'pure' WebSphere solution, that would allow managing properties via console you could check out the resource environment providers (but its rather long, complicated solution): http://www.ibm.com/developerworks/websphere/library/techarticles/0611_totapally/0611_totapally.html

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

回答by Greycon

another solution, which I use, is to add a URL resource reference to your application web.xml. For instance "url/properties".

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

Then define URLs in Websphere, using the admin console, to point to "file:///dev.properties", or "file:///test.properties", for example.

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

Then at deploy time, map the URL reference to the appropriate websphere URL definition.

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

Now, your code can just do a jndi lookup of the URL.

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

This has the advantage that you can deploy a single codebase, and customise at deploy time to point to different URLs.

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