Troubleshooting: Changes do not appear in the application during run time

Examine the application information in the configuration repository. Since the WebSphere Application Server is a distributed environment, use the following technique to help you determine which part of the application update process is problematic.

Remember the application update process can be divided into several stages:

1. Updating the master copy of the application.
2. Distributing the new application to nodes that run that application (if using a deployment manager).
3. Expanding the changed assets from the master copy of the application into the application binaries directory.
4. Setting file permissions.

Each step can be validated to help determine where the problem is occurring.

Stage 1: Updating the master copy of the application

In this stage, you want to ensure that the master copy of the application has the new files that are part of your update.

For each update that you perform, a descriptor is created by WebSphere Application Server that indicates which files or modules were added, changed, or deleted from the application. You can examine these descriptors to ensure that your updates have been recorded properly. The descriptor files are under WC_profiledir /config/cells/ cell_name /applications/ WC_ instance_name.ear/deltas/WC_ instance_name . There may be many files under this directory. Each file name is of the format delta- timestamp , where timestamp is a code that indicates the time of the update. To find the latest file, sort the list of files alphabetically and the last file represents the last update. Each file will have contents similar to this:

<?xml version="1.0" encoding="UTF-8"?> 
<app-delta> 
<change_input changetype="fg-update" contenttype="partialapp" update.recycle="update.recycle.none"/> 
<files> 
<file operation="add" uri="Stores.war/ConsumerDirect/css/LocalClasses.css"/> 
<file operation="add" uri="Stores.war/ConsumerDirect/css/Master1_1.css"/> 
<file operation="add" uri="Stores.war/ConsumerDirect/css/Master1_1ko_KR.css"/> 
<file operation="add" uri="Stores.war/ConsumerDirect/css/Master1_1zh_CN.css"/> 
<file operation="add" uri="Stores.war/ConsumerDirect/css/Master1_2.css"/> 
<file operation="add" uri="Stores.war/ConsumerDirect/css/Master1_2ko_KR.css"/> 
<file operation="add" uri="Stores.war/ConsumerDirect/css/Master1_2zh_CN.css"/> 
<file operation="add" uri="Stores.war/ConsumerDirect/css/Master1_3.css"/> 
<file operation="update" uri="Stores.war/WEB-INF/struts-config-ext.xml"/> 
<file operation="update" uri="Stores.war/WEB-INF/tiles-defs.xml"/> 
<file operation="update" uri="xml/member/MemberRegistrationAttributes.xml"/> 
</files> </app-delta>

You can validate the EAR has been updated by opening the master copy of the application in a ZIP utility, such as WinZip. This file is stored under WC_profiledir /config/cells/ cell_name /applications/ WC_ instance_name.ear/WC_ instance_name .ear. Once you have opened the file, look for your changed assets.

Stage 2: Distributing the new application to nodes that run that application (if using a deployment manager)

This stage is applicable only if you are using a deployment manager.

Stage 1, updating the master copy of the application, identified a method to validate the master copy of the application. You should perform these steps on each node that runs your application to ensure that the node has received an updated copy of application. If the node does not have an updated copy, in the WebSphere Administrative Console, check that the node is synchronized. If the node is not synchronized, synchronize it. If the console indicates it is synchronized, perform a full synchronize on that node.

Revalidate the copy of the application on that node and check the application binaries directory to ensure that the new assets have been extracted from the master copy of the application to the binaries directory.

Stage 3: Expanding the changed assets from the master copy of the application into the application binaries directory

If you are using a deployment manager, the Node Agent is responsible for expanding the changed assets from the master copy of the application to the application binaries directory.

If you are not using a deployment manager, this expansion happens immediately after updating the application. The expansion is done by server1.

Occasionally expansion can fail. This is usually caused by incorrect file permissions on the application binaries directory. If you suspect that is the case, correct the file permissions so that the user running the application server has write access to the application binaries directory. Once this is corrected, re-deploy your changes to the application

Stage 4: Setting file permissions

WebSphere Commerce has strict security requirements. The default umask is 027. This means that any files created in the application server have file permissions 750. Since some of the content of the application must be readable by the Web server, WebSphere Commerce has built an extension to WebSphere Application Server application management. Whenever the application is updated this code is invoked to set the file permission on the changed file assets.