Strange problem with WebSphere Portal URLs following fix pack installation

This started out as a rumour of a problem whereby applying certain fix packs to WebSphere Portal 6.1.0.3 would "corrupt the context root" which had been changed from the default of wps.

We were fortunate enough to recreate the problem in its entirety during the build of a "sandbox" environment - the actual symptoms were slightly different; whilst the new context root worked perfectly, the client had also changed the default home page URIs ( both for anonymous - portal - and authenticated - myportal ), using the same ConfigEngine modify-servlet-path command, as per the Information Centre: -

Changing the portal URI

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/topic/com.ibm.wp.ent.doc_v615/config/cfg_intr.html

Whilst there were no errors in the portal logs ( WebSphere_Portal/SystemOut.log and WebSphere_Portal/SystemErr.log ), or in the ConfigEngine logs, there was definitely a problem; accessing either of the new home URIs resulted in an HTTP 404 exception - which isn't a typical WebSphere exception; accessing the wrong URI would typically result in: -

SRVE0255E: A WebGroup/Virtual Host to handle /new/homepage has not been defined.

SRVE0255E: A WebGroup/Virtual Host to handle dmhw500.uk.ibm.com:10039 has not been defined.

in the browser, with a corresponding exception in SystemOut.log such as: -

[06/07/10 07:02:09:627 BST] 0000002c webcontainer  E com.ibm.ws.webcontainer.WebContainer handleRequest SRVE0255E: A WebGroup/Virtual Host to handle /new/homepage has not been defined.

Therefore, I started digging further and, on ascertaining that the client uses Servlet Filtering, as per Ron Lynn's excellent article: -

http://www.ibm.com/developerworks/websphere/library/techarticles/0707_lynn/0707_lynn.html

I looked at the web.xml that WebSphere Portal ( wps.war in wps.ear ) uses.

This had the WRONG URIs, with filter paths such as: -

<filter-mapping>
<filter-name> Parameter Filter</filter-name>
<url-pattern>/myportal/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name> Parameter Filter</filter-name>
<url-pattern>/portal/*</url-pattern>
</filter-mapping>

rather than the expected URIs that the client had chosen to use.

Changing web.xml for the WPS application via: -

/opt/IBM/WebSphere/wp_profile/config/cells/localhostCell01/applications/wps.ear/deployments/wps/wps.war/WEB-INF/web.xml

( Note this under the application configuration rather than installedApps *AND* needs to be set at the cell/node level )

all was OK.

Having narrowed the problem down to web.xml in wps.war, I dug further into the ConfigEngine/config/work directory structure, and found that PM12630 had backed out the client's changes to web.xml, keeping both the original customer-modified AND the default IBM implementation, which had been causing the problem.

Once I'd realised that this fix was "at fault", I checked the APAR for the iFix, and lo and behold, the problem was highlighted: -

<snip>
The change to the wps.war web.xml file can either be done automatically through the following config task

<wp_profile>/ConfigEngine/ConfigEngine.[bat|sh] apply-PM12630

or manually be exporting the wps.ear, merging the web.xml with the changes outlined in the problem solution section and redeploying the wps.ear.

Do not use the this task if portal url schema names or servlet filters have been modified in wps.war web.xml. In this case, the change has to be manually merged into the web.xml file to keep the prior modifications.
</snip>

http://www-01.ibm.com/support/docview.wss?uid=swg1PM12630

Thus, we have a fix - reinstate the correct Servlet Filters - and can avoid it in the future by manually applying this iFix, and any others that have the same health warning.