jsessionid is not added to resources if cookies are disabled by the server

[ge...@gmx.org]

Hi Wicket fellows,

When I configure the container (either Jetty or Tomcat) to not support cookies, I expect the jsessionid to be added to all resource links in the page. However, with Wicket 1.5.5 this isn't the case, i.e. all URLs are lacking the jsessionid.

We are running our application in a setup with one active and one inactive Tomcat instance running in parallel behind a loadbalancer and an Apache. The requests are routed to the worker that is appended to the jsessionid, and if no worker can found it will be route to the currently active instance. This way you can keep sessions stable on a deactivated Tomcat if you deploy a new version to the inactive Tomcat and then switch it to be the active one.

Now this leads to a quite random behavior when it comes to resources. Let's say Tomcat A is active and Tomcat B is inactive. If I then deploy a new version of the application to B and switch (i.e. A is inactive, B is active), the users still logged in on A will get the resources served by B because the jsessionid is missing and the requests are thus routed to B as the active instance. This causes strange side effects concerning Javascript, CSS, mounted images etc.

In my opinion, this is a bug. I have found a few issues regarding this topic, e.g. https://issues.apache.org/jira/browse/WICKET-4334 and https://issues.apache.org/jira/browse/WICKET-4312. But even if WICKET-4312 seems to say that everything should work as before, I doubt that ;-)

Could someone please verify that I'm not missing some configuration or anything? I created a quickstart do demonstrate the behavior - please see the attached file. The file jetty-web.xml tells Jetty to not support cookies, so it can be run with mvn jetty:run without any further configuration.

By the way, I found a suggestion to use a custom IResourceCachingStrategy to append the jsessionid (or whatever) to URLs of resources in the archive of this list. Unfortunately, this doesn't work because the URL is encoded afterwards and the ; is turned into %3B :-(

Any help is very much appreciated :-)

Cheers,

Michael