Administer > Deploy > Deploying customized assets
What's changed for deploying customized assets
Overview
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:
- Utility JAR files
- EJB modules
- Web modules
- Connector modules
- XML configuration files
- Properties files
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:
- Tools framework configuration files
xml/tools
- Messaging files
xml/messaging
- WCS instance configuration file
EAR/xml/config/wc-server.xmlFor WCS 7.0, there are two versions of the WCS configuration 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...
- Each EJB JAR
- WAR files under...
stores.war/WEB-INF/classes
WebProject\WebContent\WEB-INF\classes
- JAR files under...
stores.war/WEB-INF/lib
WebProject\WebContent\WEB-INF\libIn addition, WCS has included additional utility JAR files and directories to the application class path...
WC_INSTANCE/xml
WC_INSTANCE/propertiesAs 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" XMLCacheSize="1000" XMLPath="tools:tools/devtools:WEB-INF/xml/tools:WEB-INF" developmentMode="false" display="false" resourceBundlePath=""> <resourceConfig file="common/resources.xml"/> <resourceConfig file="preview/resources.xml"/> <resourceConfig file="policyeditor/resources.xml"/> .... </ToolsGeneralConfig>
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...
EcInboundMessageDtdPath="/opt/WCS561/xml/messagingHowever, in WCS 7.0, this would be...
EcInboundMessageDtdPath="messaging"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:
file:///opt/WAS70/AppServer/profiles/demo/installedApps/WC_CELL/WC_APP.ear/xml/tools/common/resources.xml
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...
- Publish a starter store using the Administration Console
- Add an attachment
- Update a store logo using the WCS Accelerator
- Apply WCS fix packs
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:
- Installing a WCS fix pack could remove any previous customization
- Installing a WCS fix pack could fail
- Migrating to the next release of WCS can remove any previous customization
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