The only problem is that each package resource request creates a new Wicket Session in WicketFilter. This may be light or heavy operation, depends on the actual Session impl.
And in WicketFilter we do not know whether this is a request to a package resource or to any other IResource impl which may need the session. We have this info later. On Wed, Jan 11, 2012 at 2:15 PM, Chris Colman <chr...@stepaheadsoftware.com> wrote: >>A use case: >>Imagine that the management of the session in a cookie is disabled in >>the web server config, so jsessionid is always encoded in the url. >>If resources don't have the jsessionid in their url then a new >>temporary Wicket and http sessions will be created and discarded for >>each request. > > In the use case where jsessionid is to be used instead of cookies there > is no need for jsessionid to be present in every url generated in a page > render. It is only required in urls that will lead to another page so > that the session id is transitive from one page to another as the user > clicks links. > > Urls that are 'dead ends' and will never lead to other pages being > opened don't need this transitive feature and so don't need to carry a > jsessionid. > > I can't ever see a need for encodeURL to be called on a package resource > URL - it doesn't lead to another page so there is no need to send this > 'session DNA' along with URLs to package resources. It should only ever > be needed in URLs that can take the user to another page on the site. > > There's two approaches to avoid sending these jsessionid's along with > package resource URLs: > > 1. Wicket framework does some smarts and doesn't encode links to package > resources. > > 2. Wicket users override newWebResponse and return WebResponse instances > that override encodeURL to avoid calling super.encodeURL(url) for > package resource URLs but do it for links to pages on the site. > Obviously this class would have to analyze the URL and get funky with a > lot of nastiness to get it right. > > In http://issues.apache.org/jira/browse/WICKET-2999 Igor's comment on > 19/8/2010 seems to suggest that approach 1. was taken and that it was > working in 1.5 but that was 16 months ago ;) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
