在具有不同属性的 Websphere 中多次部署 WAR？
我们有一个在 websphere 应用程序服务器内运行的 Axis2 应用程序。该应用程序打包为 WAR 文件。我们需要在同一个 websphere 副本中运行同一个 WAR 的两个副本，并让应用程序的每个副本从文件系统加载不同的属性文件。我正在寻找可以在部署应用程序时从 websphere 管理控制台设置的内容，该内容对应用程序可见，并且可用于更改应用程序搜索其属性的方式。
现在属性文件存储在 WAR 中，因此我们为每个环境构建不同版本的 WAR。相反，我们希望使用单个非特定于环境的 WAR 文件以及存储在文件系统中的外部属性文件。我们有这个工作。但是，我们有两个开发环境托管在同一个 websphere 副本中。因此，我们需要在同一个 websphere 服务器中部署同一 WAR 的两个副本，并让每个实例加载不同的属性文件。
我们尝试的一件事是检查上下文根。当部署应用程序的两个副本时，它们每个都必须具有不同的上下文根（用于访问应用程序的 URL 的第一部分），并且 Axis2 ConfigurationContext 包含用于读取上下文根的函数。不幸的是，当应用程序在 WAS 中运行时，它会获取 Axis2 的上下文根概念（始终为“axis2”），而不是 WAS 正在使用的真正上下文根。
编辑：为了澄清，我们希望在应用程序启动期间加载属性文件（对于那些熟悉 Axis2 的人来说，在 ServiceLifecycle.startup() 期间）。此时，没有需要处理的实际 Web 服务请求，因此我们没有要检查的消息上下文。
We have an Axis2 application which we run inside websphere application server. The application is packaged as a WAR file. We need to run two copies of the same WAR within the same copy of websphere, and have each copy of the app load a different properties file from the filesystem. I'm looking for something that I can set from the websphere management console while deploying the application, which is visible to the app and can be used to change how the app searches for its properties.
Right now the properties file is stored in the WAR so we build a different version of the WAR for each environment. Instead, we'd like to use a single, non-environment-specific WAR file with an external properties file stored in the filesystem. We have that working. However, we have two development environments hosted within the same copy of websphere. So we need to deploy two copies of the same WAR within the same websphere server and have each instance load a different properties file.
One thing we tried was to check the context root. When two copies of the app are deployed, they each have to have a different context root (the first part of the URL used to access the app), and the Axis2 ConfigurationContext includes a function for reading the context root. Unfortunately, when the app runs within WAS, it's getting the Axis2 idea of the context root--which is always "axis2"--and not the real context root that WAS is using.
EDIT: To clarify, we want to load the properties file during application startup (during ServiceLifecycle.startup() for those of you familiar with Axis2). At that point there's no actual web service request to be processed, so we don't have a message context to examine.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我们发现一个名为共享库的 Websphere 功能可以解决我们的问题。 Websphere 共享库实际上是一组条目（目录或 jar 文件），可以将其添加到单个应用程序的类路径中。我们为每个环境（开发、测试等）定义一个共享库，并将每个环境的属性文件放在正确的目录中。
然后，当部署应该作为特定环境（例如 dev）运行的 WAR 时，我们将对 dev 共享库的引用添加到应用程序。为开发共享库定义的目录会自动添加到应用程序的类路径中。
我们正在寻找的另一个更黑客的解决方案是将文件添加到 WAR 的 WEB-INF/classes 目录中。该目录会自动添加到应用程序的类路径中。然后我们可以调用 ClassLoader.getResource() 来定位该文件，并解析文件的路径名以获取应用程序的名称。通过为已部署应用程序的每个实例指定不同的名称，应用程序可以确定应如何初始化自身。
We found a websphere feature called shared libraries that solves our problem. A websphere shared library is actually a set of entries--directories or jarfiles--that can be added to the classpath for an individual application. We're defining one shared library for each environment--dev, testing, and so on--and put the properties file for each environment in the correct directory.
Then, when deploying a WAR that is supposed to run as a particular environment--dev, for example--we add a reference to the dev shared library to the application. The directory defined for the dev shared library is automatically added to the application's classpath.
Another more hackish solution that we were looking at is to add a file to the WAR's WEB-INF/classes directory. This directory is automatically added to the application's classpath. Then we could call ClassLoader.getResource() to locate the file, and parse the file's pathname to get the name of the application. By giving each instance of the deployed app a different name, the application could figure out how it should initialize itself.
WebSphere 资源引用（例如 URL 资源）可以通过从 java:comp/env 名称空间查找来获取，因此在部署时进行绑定。因此，您可以部署两次并绑定到不同的实例 - 您可能熟悉对 JDBC 资源执行此操作。
您可以使用多种有用的资源，例如文件 URL。请参阅 信息中心
WebSphere resource references such as a URL resource can be obtained by lookup from java:comp/env namespace, hence being bound at deployment time. So you can deploy twice and bind to different instances - you are probably familiar with doing that for JDBC resources.
There are various flavours of useful resource you can use such as a FILE URL. See The info centre
@kenster：使用 websphere 命名空间绑定。例如，您可以使用名称 = 应用程序的上下文根名称和值 = 文件系统路径创建名称空间绑定（在环境下）...然后您可以在应用程序中使用 JNDI 检索名称空间绑定，以从值中指定的路径加载属性文件。
@kenster: Use websphere namespace binding. For e.g. you can create namespace binding (under Environment) with name=context root name of application and value= filesystem path...then you can retrieve namespace binding using JNDI in your application to load properties file from the path specified in value.