my2cents

This is a follow-up for the Beware of WebSphere admins post just below.

My first immediate conclusion after the described deployment problems was to ban the use of the jsession cookie  in future applications. If the application always includes the jsessionid parameter in URLs there’s nothing that can go wrong during deployment in terms of cookie paths.

Contemplating a second longer made it obvious that maybe this wouldn’t be such a wise decision after all. There are number of developers who try to enforce the exact opposite because the jsessionid URL parameter can be considered harmful. I highly recommend reading the following two blog posts that support this thesis:

http://randomcoder.com/articles/jsessionid-considered-harmful
http://boncey.org/2007_1_8_purging_jsessionid

A lot can go wrong when you deploy a simple Java EE application in IBM WebSphere – even if the application needs nothing but a Servlet container.

We recently shipped a JEE application to the customer. Although it was packaged in an EAR file, because the customer required it, it needs nothing but what the Servlet specification mandates. The application was tested both at other customer sites and on our internal infrastructure. Some customers use JBoss, others Oracle Weblogic and we use Tomcat internally. This new customer uses IBM WebSphere *sigh* – not our dearest friend, but so what. So we set up a WebSphere test server in-house and successfully deployed the application.

The customer asked us to fill in a several page form to specify all the necessary configuration parameters our application required. For almost all fields we settled for the provided default values because all we basically needed was a JNDI name pointing to a datasource.

Needless to say the application didn’t run out-of-the-box at the customer site.

Given the fact that the application runs fine on all but this customer’s infrastructure neither the customer nor I thought it necessary for us to provide on-site support. The log files we got for analysis indicated that somehow they seemed to have a multi-threading or multi-session problem. For two weeks the customer’s network and WebSphere specialists tried to figure our what was going on. When they were at their wits end, my repeated offer to send one of our engineers over was accepted. When he, too, was stuck a day later I asked him to share his screen remotely and show me request/response headers in HttpFox.

It became apparent immediately why our application constantly created new sessions. The cookie path for the jsessionid cookie was neither ‘/’ nor was it equal to the context root of our application. Hence, with every response our application returned a new jsession cookie, but when the browser sent a new request to the application it didn’t include the session id – because it didn’t find a cookie with a path that matched the application’s context root. Usually you’d notice this immediately because you’d have to authenticate yourself (i.e. log in) constantly with every request. Since the customer uses SSO this was done transparently in the background.

So, what’s this got to do with the WebSphere admin? Well, in the form mentioned above we were asked for the application cookie path. The default value was ‘/’ and therefore we hadn’t changed it. The admin, however, acted on his own authority and changed this to something else.