Gee... David

From where I sit a portal related project can test the breadth of my portal experience. Last week proved to be no exception. Since September I have worked along with several of my colleagues on a facinating application built using WebSphere Portlet Factory. Among the features required to achieve the business objectives of this application is a JMS enabled application, written using IBM Rational Application Developer.

The challenges, in this case, were not to our developmental expertise, but our administrative skills. The beginning of the problem was that the server was unable to authenticate the credentials used by a JMS component. One team member gravitated toward an update as the solution. The portal was a 5.1.0.3 server. WebSphere was at 5.1.1.1 with JDK 1.4.2 and WBISF was unpatched since the portal install.

Armed with the appropriate patches we updated WAS to 5.1.1.15, the JDK to 1.4.2 SR8, WBISF to version 5. The stage was set for an update of portal to 5.1.0.5. Alas, the update failed. An investigation revealed an SSL handshake error. I did some investigating and determined that the configuration of WebSphere Member Manager required SSL. Since I did not install this portal it was unclear what certificates were installed into the key store.

The consultant who installed the server confirmed my suspicion that the keystore had been populated. He further indicated his thought that the JDK update overwrote the keystore. Had I known that SSL was required we could have saved a lot of time but, again, I had no documentation available showing how the server had been configured.

This information answers a lot of questions. Not only does it solve the question as to why the Portal update failed but also answers questions about the JMS related authentication failures.

Tomorrow, if the snow isn't too deep, we are going to turn off the SSL property for Member Manager as a test of my hypothesis without applying any patches.

I will provide an update tomorrow or Wednesday for you who 'may' be interested.