Update on WebSphere Portal Malformed URLs

Life has been real crazy lately – we are finally getting ready to deploy the WebSphere Portal v5.1 upgrade on production. In fact a team member is headed to Africa morrow for the deployment on one of the two master sites, while another team member will handle the deployment here on the US site. I too am on my way to Africa to meet with the client and assist with the deployment.

Just thought that I would put out an update on the WebSphere Portal performance issue that I covered in a previous blog entry. Basically we have been following up with IBM support (and a couple of senior IBM contacts that I have who work on the WebSphere Portal product) on the issue that WebSphere Portal renders the home page unilaterally when it encounters a malformed Portal URL. We have lobbied very hard with IBM that the true fix for this issue is that WPS allow us to configure how error handling should be done (just as we can do with any web application). However supposedly WPS has this implementation limitation which prevents it from doing anything differently when it encounters a malformed URL. So at this point, the best they can do is generate a log entry in the wps*.log file that indicates what malformed URL was encountered. Since the URL generally has the unencoded name of the resource (image/css/js) that you are trying to reference, the URL should give you a good idea of what resource is incorrectly referenced. This is at least a step in the right direction. You can find the APAR containing this fix here.

However philosophically speaking, it just does not go down well with me that WebSphere Portal has an inherent architectural limitation that prevents it from allowing administrators to configure error handling! Imagine what flowery words Hani (in his infamous bile blog) would have to say if he were actually using this product instead of his home-brewn EPIX!

I doubt I will be blogging much or any while in Africa! So until later, my friends …