Copying files and making changes directly to the installedApps directory is not a recommended approach for making code or configuration changes. This can lead to inconsistencies and unexpected loss of your changes.
To maintain a consistent and stable environment, always deploy code following the documented best practice. Keep reading to learn more.
I'll use a scenario to help you understand the problem:
You just made a JSP change, somewhere within the following EAR:
You restart your server, and your JSP is working correctly and your wc-server.xml changes are in effect.
A few weeks later, your team applies an APAR (iFix), and suddenly, the JSP change is missing and so is the change you made to the wc-server.xml file.
Why are your changes getting lost?
To understand why this happens, lets look at how Commerce does deployments to the Runtime (installedApps) Commerce EAR.
The Expanded EAR is what you know as the Runtime EAR located in the installedApps directory. The contents of this EAR is what is used when the Commerce application is started, and is the one containing the logic that handles all Commerce requests.
The Master EAR file (aka the Collapsed EAR), is the master copy of the EAR. This is the EAR file that is referenced and updated during deployments and utility based configuration changes.
When there is maintenance or any action that requires the EAR to be updated, WebSphere performs the following tasks:
Extracts he application from the Master repository:
WASinstallDir/profiles/instanceName/config/cells/WC_instance_cell/application to WC_profiledir/wstemp
Merges new content with extracted EAR
Checks in new collapsed EAR into configuration repository
If non-managed node, expand assets to installedApps directory
If managed/federated, asynchronously transfer EAR as a zip to the node and expand assets to installedApps directory
If clustered, it will send the zip to all nodes running the application, then expand assets to installedApps directory
Restarts the application.
What originally existed in the installedApps EAR, is completely lost by the end of Step 3 above.
To avoid losing your customizations, make sure you follow some best practices to make updates to your environment:
To make an update to your wc-server.xml file, update your instance.xml file and then run updateEar to propagate your changes:
Propagating changes to the WebSphere Commerce configuration file
If you deploy changes to your wc-server.xml through WCBD, then only make changes to the wc-server.xml through that method, and do not use the updateEar approach, because your source control version of the instance.xml and wc-server.xml will get out of sync with your runtime version.
To make updates to a JSP or any other custom file, use one of our documented deployment methods:
Customized WebSphere Commerce Enterprise Application (EAR) assets
Expanded EAR file (runtime EAR) location for standalone and clustered environments.
Master EAR file (collapsed EAR) location for standalone environment:
Master EAR file (collapsed EAR) location for clustered environment: