Contents:
For users who are experiencing problems with iSeries Access for Web performance immediately after restarting a WebSphere Application Server (WAS) instance:
This situation is caused by the fact that WAS, by default, creates java program objects and does bytecode verification for all classes on their first usage. The java program information is thrown away when the application system is ended. This means that these steps are performed every time the application system is restarted. To get around having to do this, a special setting can be set to allow the java program information to be cached. This works for WAS V4 and WAS V5. If users have iSeries Access for Web configured under multiple WAS instances, one cache file can be used to contain the cached class information from all of the instances.
Information on how to do this can be found in the V5R2 System i and i5/OS Information Center, in the article
Java Cache for User Classholders.
In the Information Center instructions, users are told how to create a JAR file to hold the cache information. Instead of doing this, you can use the file supplied by us below, ClassCache.jar. You can install this anywhere on your iSeries system where the correct authority exists to the path and file, but we recommend putting the file in /QIBM/UserData/Access/Web2.
Download ClassCache.jar
When using Microsoft Internet Explorer and any of the iSeries Access for Web functions to download a file to the browser, many times Internet Explorer will display the file's content in the browser without offering an opportunity to just save the file. Basically, Internet Explorer sniffs the data, and for many file types decides it is capable of displaying the data. Many users do not want this behavior, and would prefer to save the file immediately.
To get around this issue, starting with V5R3 5722XH2 PTF SI18964, iSeries Access for Web can now optionally write a HTTP header that forces Internet Explorer to display a File Save As window. The HTTP header being written is a Content-Disposition header. The Content-Disposition header that can be optionally written is controlled by creating a disposition.properties file. Different Content-Disposition headers can be written based on the file content-type (MIME-type) being downloaded.
iSeries Access for Web uses the file extension to determine the file content-type (MIME-type) to be sent to the browser. The file content-type is used by the browser to determine how best to render the information. For more information on controlling the MIME-type based on the file extension, see the iSeries Access for Web File considerations article in the iSeries V5R3 Information Center. This article covers how to map file extensions to different MIME-types.
Once the MIME-type mapping setup has been done, a disposition.properties file needs to be created in the iSeries Access for Web UserData tree. For most of the supported web serving environments, the iSeries Access for Web UserData tree is:
/QIBM/UserData/Access/Web2/application_server/instance_name/server_name/config
Replace application_server, instance_name, and server_name with the unique values on your system.
The disposition.properties file needs to contain entries that specify what Content-Disposition header value should be written based on the MIME-type of the file being downloaded using iSeries Access for Web.
The following properties files show an example of what would be required to force a File Save As window when downloading a file with a .TXT extension.
The extensions.properties file needs to contain:
txt=text/plain
The disposition.properties file needs to contain:
text/plain=attachment
Changes to the properties file will take effect within a couple of minutes of the files being changed. The changes do not take effect immediately unless the web application system is stopped and restarted.
| 
