Deploying a WAR multiple times in Websphere with different properties?

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开发者_如何学Go"--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.

---

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: 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.

---

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.