WebSphere Application Server V7.0: Concepts ... - IBM Redbooks

If you store property files that need to be changed between different
environments inside the EAR file, you might discover that there are problems
involved with that approach, especially in a clustered environment.
In a clustered environment when an enterprise application is deployed to
WebSphere Application Server, it is distributed to each node in the cluster using
the WebSphere Application Server file transfer mechanism. At each node, the
EAR file is expanded and laid out on the file system so that WebSphere
Application Server can execute it. This means that a property file included in the
EAR file is automatically replicated to each member of the cluster.
If you then need to make a change to the property file, you either have to do it
manually on each cluster member, which can be error prone, or you do it on the
deployment manager itself and then distribute the updated file to each node
again. However, WebSphere Application Server does not fully expand the
contents of the EAR file to the file system on the deployment manager (it only
extracts from the EAR file the deployment descriptors needed to configure the
application in the WebSphere Application Server cell repository), so the property
file is not readily accessible on the deployment manager. Because of this, you
must manually unpack the EAR file, extract the property file, modify it, and then
re-create the EAR file again and redeploy the application. This is not a
recommended approach.
Another option is to distribute the property files within the EAR, but after
deployment, extract them from the EAR file and place them in a folder separate
from the EAR. An example of a folder name suitable for that is
\config\cells\\configData on the deployment
manager machine. Anything in that folder is replicated to each node in the cell
when WebSphere Application Server synchronizes with the nodes. For the
application to find the file, it must then refer to it on its local file system. But
because that folder name includes both the name of the profile and the name of
the cell, it can quickly become messy and is usually not a good solution.
8.11 Planning for application upgrades in production
To have a production environment that enables you to roll out new versions of
applications while maintaining continuous availability is not only the responsibility
of the WebSphere infrastructure architects and system administrators, it is also
the responsibility of the developer. Even though they might not always realize it,
developers play a critical role in making the production environment stable and
highly available. If an application is poorly written or developers introduce
incompatible changes, there might not be much the system administrators can
do but to bring down the whole system for an application upgrade. And
unfortunately, application developers are too often not aware of the impact their
decisions have on the production environment.
Chapter 8. Application development and deployment 305