Package custom Web server assets

Package custom Web server assets

+
Search Tips | Advanced Search

Overview
Packaging Web server changes for deployment can be divided into different phases:

how the Web server finds assets
where to store the assets
packaging the assets

How the Web server finds assets

WebSphere Commerce includes static Web assets...

image files
HTML files
JavaScript files
etc...

...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_profiledir/installedApps/WC_instance _cell/WC_ instance.ear/Stores.war"
When the browser asks for...
http://www.mystore.com/wcsstore/mystore/logo.gif

...the Web server will return the file from...
WC_profiledir/installedApps/WC_instance_cell/WC_instance.ear/Stores.war/mystore/logo.gif

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 your custom Web assets:

Storing the assets inside the J2EE application
Placing 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 your 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 your Web server does not share a file system with the application server, you 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 your 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 your Web server assets:

If your 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, IBM recommends that you store it outside of the EAR file. This ensures that application updates occur as quickly as possible. To do this change your JSP files to use a new alias and configure your Web server for this alias.
If your Web server does not share a file system with your 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
Packaging 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 your 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

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 your Web server does not share a file system with the application server, you 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 your Web Server shares a file system with the application server, the custom Web assets will be removed when installing WebSphere Commerce fixes.