Package custom Web server assets

Administer > Deploy > Deploying customized assets > Customized WebSphere Commerce Web server assets

Package custom Web server assets

Package Web server changes for deployment can be divided into different phases: how the Web server finds assets, where to store the assets, and packaging the assets.

How the Web server finds assets
WebSphere Commerce includes static Web assets (image files, HTML files, JavaScript files, and so on) inside a J2EE application. Even though these files are stored inside the J2EE application, they are not served from the application server. Static Web assets are served directly from the Web server, which has aliases configured. Each alias represents a path to some directory on the file system. When a browser requests content that starts with the alias, the Web server attempts to find this file in the file system. WebSphere Commerce provides several aliases. These aliases point to directories inside the WebSphere Commerce J2EE application.
Here is an example scenario.
To serve the static Web Content for the Stores Web Module, WebSphere Commerce defines the following alias:
Alias /wcsstore " WC_PROFILE /installedApps/WC_ instance _cell/WC_ instance/Stores.war"
When the browser asks for http://www.mystore.com/wcsstore/mystore/logo.gif, the Web server will return the file from WC_PROFILE/installedApps/WC_ instance_cell/WC_ instance/Stores.war/mystore/logo.gif if it exists. If it does not, it will return a page not found error message to the browser.
Storing the Web server assets
There are two options when deploying the custom Web assets:

Store the assets inside the J2EE application

Place the assets only in the Web server's file system

Use the following table to help you decide which is best for you. The option you select will determine how to package and deploy the assets.

Location Pros Cons
J2EE application When migrating, all Web assets will be brought to the next version.
If using multiple Web servers, the Application server will distribute the assets to the EAR directory on each node running the application.
If you have a lot of static content, the J2EE application can become large. Larger applications take longer to update. This means that custom code deployment and installing WebSphere Commerce fixes will take longer.
If the Web server does not share a file system with the application server, we will also need to copy the static content to the Web server's file system; that is, store the assets in the J2EE application and place the assets on the Web serve's file system.
Web server file system only No need to update the J2EE application, and therefore, this procedure will be faster When migrating to the next release, you can lose the image files and have to redeploy them.
If the Web Server shares a file system with the application server, the custom Web assets will be removed when installing WebSphere Commerce fixes.

Some general tips on packaging the Web server assets:

If the Web server and Application server share the same EAR directory, store the static content in the J2EE application. Use the WebSphere Application Server tooling to update the application. However, if you have a lot of static content, it is recommended that you store it outside of the EAR file. This ensures that application updates occur as quickly as possible.
To do this change the JSP files to use a new alias and configure the Web server for this alias.

If the Web server does not share a file system with the Application server, it is best to store the file assets outside of the J2EE application. You will need to find a mechanism to update all Web servers with the new content (such as SCP or FTP).

Packaging the Web server assets
Package Web server assets is similar to packaging J2EE assets for a partial application; that is, export static content from where it is stored and package and deploy it to the deployment target. Follow the standard packaging guidelines for packaging J2EE assets for a partial application.

Next topic: Deploy custom Web server assets

Related tasks

Deploy custom Web server assets

+
Search Tips | Advanced Search

Location	Pros	Cons
J2EE application	When migrating, all Web assets will be brought to the next version. If using multiple Web servers, the Application server will distribute the assets to the EAR directory on each node running the application.	If you have a lot of static content, the J2EE application can become large. Larger applications take longer to update. This means that custom code deployment and installing WebSphere Commerce fixes will take longer. If the Web server does not share a file system with the application server, we will also need to copy the static content to the Web server's file system; that is, store the assets in the J2EE application and place the assets on the Web serve's file system.
Web server file system only	No need to update the J2EE application, and therefore, this procedure will be faster	When migrating to the next release, you can lose the image files and have to redeploy them. If the Web Server shares a file system with the application server, the custom Web assets will be removed when installing WebSphere Commerce fixes.