Configuration documents
WebSphere® Application Server stores configuration data in several documents in a cascading hierarchy of directories. Most configuration documents have XML content.
The configuration documents describe the available application servers, their configurations, and their contents.
Hierarchy of directories of documents
The cascading hierarchy of directories and the documents' structure support multinode replication to synchronize the activities of all servers in a cell. In a WebSphere Application Server Network Deployment environment, changes made to configuration documents in the cell repository, are automatically replicated to the same configuration documents that are stored on nodes throughout the cell.
At the top-level of the hierarchy is the cells directory. It holds a subdirectory for each cell. The names of the cell subdirectories match the names of the cells. For example, a cell named cell1 has its configuration documents in the subdirectory cell1. The name of the cell must be different from the cluster name pair.
On the WebSphere Application Server Network Deployment node, the subdirectories under the cell contain the entire set of documents for every node and server throughout the cell. On other nodes, the set of documents is limited to what applies to that specific node. If a configuration document only applies to node1, then that document exists in the configuration on node1 and in the WebSphere Application Server Network Deployment configuration, but not on any other node in the cell.
Each cell subdirectory has the following files and subdirectories:
- The
cell.xml
file, which provides configuration data for the cell. -
Files such as
security.xml
,virtualhosts.xml
,resources.xml
, andvariables.xml
, which provide configuration data that applies across every node in the cell. - The clusters subdirectory, which holds a subdirectory for each cluster
defined in the cell. The names of the subdirectories under clusters match the names of the clusters.
Each cluster subdirectory holds a cluster.xml file, which provides configuration data specifically for that cluster.
- The nodes subdirectory, which holds a subdirectory for each node in the
cell. The names of the nodes subdirectories match the names of the nodes.
Each node subdirectory holds files such as
variables.xml
andresources.xml
, which provide configuration data that applies across the node. Note that these files have the same name as those in the containing cell's directory. The configurations specified in these node documents override the configurations specified in cell documents having the same name. For example, if a particular variable is in both cell- and node-levelvariables.xml
files, all servers on the node use the variable definition in the node document and ignore the definition in the cell document.Each node subdirectory holds a subdirectory for each server defined on the node. The names of the subdirectories match the names of the servers. Each server subdirectory holds a
server.xml
file, which provides configuration data specific to that server. Server subdirectories might hold files such assecurity.xml
,resources.xml
andvariables.xml
, which provide configuration data that applies only to the server. The configurations specified in these server documents override the configurations specified in containing cell and node documents having the same name. - The applications subdirectory, which holds a subdirectory for each application deployed
in the cell. The names of the applications subdirectories match the names of the deployed
applications.
Each deployed application subdirectory holds a
deployment.xml
file that contains configuration data on the application deployment. Each subdirectory also holds a META-INF subdirectory that holds a Java™ 2 Platform, Enterprise Edition (J2EE) application deployment descriptor file as well as IBM® deployment extensions files and bindings files. Deployed application subdirectories also hold subdirectories for all .war and entity bean .jar files in the application. Binary files such as .jar files are also part of the configuration structure.
An example file structure is as follows:
cells
cell1
cell.xml resources.xml virtualhosts.xml variables.xml security.xml
nodes
nodeX
node.xml variables.xml resources.xml serverindex.xml
serverA
server.xml variables.xml
nodeAgent
server.xml variables.xml
nodeY
node.xml variables.xml resources.xml serverindex.xml
applications
sampleApp1
deployment.xml
META-INF
application.xml ibm-application-ext.xml ibm-application-bnd.xml
sampleApp2
deployment.xml
META-INF
application.xml ibm-application-ext.xml ibm-application-bnd.xml
Changing configuration documents
You can use one of the administrative tools (console, wsadmin, Java APIs) to modify configuration documents or edit them directly. It is preferable to use the administrative console because it validates changes made to configurations. "Configuration document descriptions" states whether you can edit a document using the administrative tools or must edit it directly.
private_Enable_zWAS_for_64bit
in server scope variables.xmlAMODE=64
in processDefinition for control, servant, or adjunct processes in server.xmlwas.com.ibm.websphere.zos.jvmmode
in processDefinition for control processes in server.xml
AMODE=64
in Start command arguments
for the server process. To see the current bit mode of the server:- Using wsadmin, run AdminTask commands to get the bit mode used.
- Using the administrative console, see Run in 64 bit JVM Mode on the application server settings page. Click .
Transformation of configuration files
The WebSphere Application Server master configuration repository stores configuration files for all the nodes in the cell. When you upgrade the deployment manager from one release of WebSphere Application Server to another, the configuration files that are stored in the master repository for the nodes on the old release are converted into the format of the new release.
- Changes the XML name space from the format of the new release to the format of the old release
- Strips out attributes of cell-level documents that are applicable to the new release only
- Strips out new resource definitions that are not understood by old release nodes