One problem found today is that the calendar plug-in webwork cannot be displayed through IHS (connected to WebSphere via plug-ins. Red Cross is displayed on the page. If you use port 9080 of was, you can access the service normally. The problem must be indicated by IHS.
First, the packet capture tool fiddler2 found that the returned length of the calendar. js file of webwork under IHS is 0, indicating that IHS did not obtain calendar. js. Why? Decided to track the IHS plug-in.
Open the configuration file plugin-cfg.xml for IHS plugin and set loglevel to trace:
<Log loglevel = "trace" name = "..."/>
After saving, restart the IHS server. After refreshing the client, open the log file http_plugin.log of IHS plugin and find the following information:
Warning: ESI: esiparsedate: Unrecognized Date Format:... GMT (The ellipsis contains garbled characters and seems to be in Chinese)
Because files such as calendar. js in webwork are obtained through filters instead of static files, we need to understand how the incorrect HTTP date information is generated. Open the filter source code of webwork and find the actual result produced by response.Code:
DF = new simpledateformat ("E, D Mmm yyyy hh: mm: SS ");
...
Response. setheader ("date", DF. Format (Cal. gettime () + "GMT ");
By querying Java APIs, The simpledateformat class generates a formatted string according to the local settings of JVM. The problem lies in JVM? Open the JVM configuration page of application server in was and find the following Configuration:
-Ddefault. Client. Encoding = GBK-dfile. Encoding = GBK-duser. Language = ZH-duser. region = Cn
This is the guiding configuration of the platform vendor. Change to the following Configuration:
-Ddefault. Client. Encoding = GBK-dfile. Encoding = GBK-duser. language = EN-duser. region = us
After restarting was, the problem is solved.