Packaging custom Web server assets
Packaging 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.
About this task
How the Web server finds assets
WebSphere Commerce includes static Web assets (image files, HTML files, JavaScript files, and so on) inside a Java EE application. Even though these files are stored inside the Java EE 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 Java EE 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_name _cell/WC_ instance_name.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_name_cell/WC_ instance_name.ear/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 your custom Web assets:
- Storing the assets inside the Java EE 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 |
|---|---|---|
| Java EE 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 Java EE 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 your application server, you will also need to copy the static content to the Web server's file system; that is, you must store the assets in the Java EE application and place the assets on the Web server's file system. |
| Web server file system only | No need to update the Java EE 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 Java EE 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 you need to 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 Java EE 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 Java EE assets for a partial application; that is, you need to export static content from where it is stored and package and deploy it to your deployment target. Follow the standard packaging guidelines for packaging Java EE assets for a partial application.