[ 
https://issues.apache.org/jira/browse/WICKET-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13272226#comment-13272226
 ] 

Michael Bruns commented on WICKET-4550:
---------------------------------------

I still can't exactly understand the reason for this.

In our scenario, we have two Tomcat instances running on the same machine. One 
is considered as active, i.e. new sessions are created on this instance, the 
other is considered as passive, i.e. it only serves sessions which are already 
open until they expire. When we deploy a new version of our application we 
deploy it to the passive instance and then switch the configuration of active 
and passive.

Let's consider the following scenario:
* Instance A is active, B is passive.
* The application contains a static resource something.js, which has the hash 
ABC appended as its version.
* something.js is changed in a new version of the application, so its new hash 
is now 123.
* Then, this new version is deployed to B and B is then made the active 
instance.

The page served by A now contains a resource link to something-ver-ABC.js. As 
the jsessionid is lacking, this request will be redirected to the active Tomcat 
instance, which is B. But B doesn't know the version ABC of something.js, it 
only knows something-ver-123.js. The result is a 404.

Or am I missing something here?
                
> jsessionid is not added to resources if cookies are disabled by the server
> --------------------------------------------------------------------------
>
>                 Key: WICKET-4550
>                 URL: https://issues.apache.org/jira/browse/WICKET-4550
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.5.5
>            Reporter: Michael Bruns
>         Attachments: jsessionid-quickstart.tar.gz
>
>
> 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, both in development and deployment mode.
> Example IS:
> <script type="text/javascript" 
> src="wicket/resource/org.apache.wicket.markup.html.WicketEventReference/wicket-event-ver-1331911540000.js"></script>
> Example SHOULD:
> <script type="text/javascript" 
> src="wicket/resource/org.apache.wicket.markup.html.WicketEventReference/wicket-event-ver-1331911540000.js;jsessionid=${something}"></script>
> This creates a new session for each and every resource in the page, which is 
> an undesirable behavior. I have found a few issues regarding this topic, e.g. 
> WICKET-4334 and WICKET-4312, but none of them could give me a clue about why 
> it doesn't work the way I expect it. In Wicket 1.4.x the jsessionid was added 
> to all resource links, so everything worked fine and the current session was 
> reused.
> 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 mvn 
> jetty:run can be 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 
> the mailinglist. Unfortunately, this doesn't work because the URL is encoded 
> afterwards and the ; is turned into %3B.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to