Administer > Deploy > Deploying customized assets

What's changed for deploying customized assets


Deployment changes have been made in the following areas:

J2EE packaging improvements

The J2EE specification outlines the packaging format of J2EE applications. This package is called an Enterprise Application Archive (EAR) file. It is a single ZIP file with an .ear extension that contains special files that describe the application. The EAR file contains all of the file assets required to run the J2EE application. These include, but are not limited to the following assets:

WebSphere Application Server distributes the EAR file throughout the distributed environment.

In previous releases of WCS, many files required at runtime were stored outside of the EAR file. Starting with v7.0, the WCS application has been repackaged. All files required at runtime are now inside the EAR file. WAS can now distribute the application throughout the environment.

The location of the file within the EAR file varies by the WCS component. Some key files that have been moved into the EAR file:

Configuration files

The packaging for WCS 7.0 has changed, and therefore, the procedure for locating and reading configuration files has also changed. In addition, each WCS component takes a slightly different approach on how the search for the files is configured.

For a clustered WCS EAR file, the EAR file is stored under a different path for each cluster member. You cannot store an absolute path to any file in the application; use a dynamic mechanism to locate the files. WCS 7.0, uses the class loader to locate and read the file assets that are in the EAR file. If you migrated the instance from WCS 5.x to 7.0, all absolute paths in the instance configuration file have been changed to relative paths. The path is relative to entries in the class path.

All WCS modules share the same class path.

The following are classes are automatically added to the class path per the J2EE specification...

In addition, WCS has included additional utility JAR files and directories to the application class path...


As an example, consider the WCS tools framework system. Inside the instance configuration file, we see...

<ToolsGeneralConfig DTDPath="tools/common:tools/devtools:tools/bi:tools/catalog:schema/xml:sar"

    <resourceConfig file="common/resources.xml"/> 
    <resourceConfig file="preview/resources.xml"/> 
    <resourceConfig file="policyeditor/resources.xml"/> 


During the migration process to WCS 7.0 runtime environment, absolute paths within instance.xml have been converted to relative paths. For example, file and paths are changed to relative paths in the instance file. If files and paths are in the EAR, their paths are relative to class paths in EAR.

Consider this example: in previous release, such as WCS 5.6.1, you would have...


However, in WCS 7.0, this would be...


All files required at run time should be moved into the EAR. The EcInboundMessageDtdPath is relative to the EAR instead of to WC_INSTALL

The tools framework uses an XML search path identified by the XMLPath attribute, which specifies a set of directories that search for a particular file. In this example, the tools framework must load all of the resourceConfig files identified by the file attribute of the nested resourceConfig elements.

The algorithm is:

For each resourceConfig file
   for each XMLPath
       URL filePath = this.getClassLoader().getResource(XMLPath + "/" + resourceConfigFile)
       if (filePath !=null) 
           file is found, process it, move to next file 
       else file is not found 
           move to next XMLPath

Here is an example execution for the algorithm in the WCS environment, on AIX, when the runtime is trying to load the common/resources.xml file:

this.getClassloader().getResource("tools" + "/" + "common/resources.xml");

This causes the application server to locate the file tools/common/resources.xml in the application's class path. Since the WC_INSTANCE.ear/xml directory is in the class path, the application server will return the following URL:


If null was returned, it would move on to the next search path of...

this.getClassloader().getResource("tools/devtools" + "/" + "common/resources.xml");

Although some components do not have this search path feature, these components will all assume the relative paths found in the instance configuration file are retrievable from the application's class path.

Application updates

WCS provides an extensible application. You typically customize the WCS application to meet the business requirements. This could be as simple as adding some JSP files, or it could involve adding new EJB beans.

In WAS 7.0, you no longer have to provide an entire EAR file. WCS tooling has been updated to take advantage of this new function. Examples include...

WAS ensures that the changed application files are distributed to all nodes running the WCS application.

Use the WAS tooling to update the WCS application. If you use the old deployment procedure we will can encounter problems later, such as:

Related concepts

Customized WCS database assets
Customized WCS EAR assets
Customized WCS Web server assets

Related tasks

Deploy customized assets
Package custom database assets
Deploy custom database assets
Package custom Java EE assets
Deploy custom Java EE assets
Package custom Web server assets
Deploy custom Web server assets

Related reference

Minimize downtime during deployment
Troubleshoot: Deployment
WCS deployment checklist
Top 10 tips to ensure a successful deployment of WCS
How to increase the success with WCS deployment


Search Tips   |   Advanced Search