JIRI issue 4334 has fixed this now which is great.
The next issue is that while Wicket is able to avoid establishing a
session for requests for package resources it would be good if their URL
made it easy for other filters (eg., Open Persistence Provider in View)
to also ignore them to allow them
See org.apache.wicket.request.mapper.BasicResourceReferenceMapper#mapHandler
All IStaticCacheableResource are passed to
org.apache.wicket.request.resource.caching.IResourceCachingStrategy#decorateUrl.
There you can tag them as you wish.
On Mon, Jan 16, 2012 at 9:09 PM, Chris Colman
Another approach is to mount explicitly all your resources which you
think need the session.
This way you can exclude /wicket/resource/... in your filter.
On Mon, Jan 16, 2012 at 9:18 PM, Martin Grigorov mgrigo...@apache.org wrote:
See
...@apache.org]
Sent: Tuesday, 17 January 2012 7:20 AM
To: users@wicket.apache.org
Subject: Re: Javascript resources and jsessionid
Another approach is to mount explicitly all your resources which you
think need the session.
This way you can exclude /wicket/resource/... in your filter.
On Mon, Jan 16, 2012
at
/wicket/resource ?
Wicket doesn't mount anything by itself. Your code initiates such mounting.
-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Tuesday, 17 January 2012 7:20 AM
To: users@wicket.apache.org
Subject: Re: Javascript resources and jsessionid
Another
.
-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Tuesday, 17 January 2012 7:20 AM
To: users@wicket.apache.org
Subject: Re: Javascript resources and jsessionid
Another approach is to mount explicitly all your resources which you
think need the session.
This way
Create a ticket please
On Wed, Jan 11, 2012 at 11:32 PM, Chris Colman
chr...@stepaheadsoftware.com wrote:
I just checked with 1.5.x and for stateless pages all bookmarkable page
links do not incur the jsessionid suffix for a non cookie client. Once
an Ajax link is added to the page however the
for packaged resources we should not be adding jsessionid i dont think...
-igor
On Thu, Jan 12, 2012 at 1:56 AM, Martin Grigorov mgrigo...@apache.org wrote:
Create a ticket please
On Wed, Jan 11, 2012 at 11:32 PM, Chris Colman
chr...@stepaheadsoftware.com wrote:
I just checked with 1.5.x
: Friday, 13 January 2012 3:15 AM
To: users@wicket.apache.org
Subject: Re: Javascript resources and jsessionid
for packaged resources we should not be adding jsessionid i dont think...
-igor
On Thu, Jan 12, 2012 at 1:56 AM, Martin Grigorov mgrigo...@apache.org
wrote:
Create a ticket please
On Wed
there was a problem
with its implementation or maybe it regressed somehow.
-Original Message-
From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
Sent: Friday, 13 January 2012 3:15 AM
To: users@wicket.apache.org
Subject: Re: Javascript resources and jsessionid
for packaged resources we should
...@gmail.com]
Sent: Friday, 13 January 2012 8:13 AM
To: users@wicket.apache.org
Subject: Re: Javascript resources and jsessionid
i remember this being fixed in 1.5 after the resource refactor...
-igor
On Thu, Jan 12, 2012 at 12:54 PM, Chris Colman
chr...@stepaheadsoftware.com wrote:
Yes, I have vague
I just opened IE and with a new clean session went to our website and
voila - IE sees the .js files with jsessionid as different to the ones
without it and so there are two of every .js file required by both the
home page and the second page I visited.
I imagine if user visits a site on a
I noticed this is an existing JIRA issue that was apparently fixed in
1.4 but I'm seeing the double package resources in the cache using an up
to date 1.5-SNAPSHOT.
Existing JIRA issue:
https://issues.apache.org/jira/browse/WICKET-2999
I just opened IE and with a new clean session went to our
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 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
I can see things like DynamicWebResource might need a session as what it
streams out could depend on session state but most instances of things
like images, .css, .js, etc., are static.
Perhaps some kind of convention could be used in the URL so that the
WicketFilter could quickly and easily tell
I just had a look at the 1.5 WicketFilter source code and it appears not
to be creating or finding a Wicket Session at all - which is a good sign
- although maybe it's created somewhere else now.
The only problem is that each package resource request creates a new
Wicket Session in WicketFilter.
As it turns out WicketFilter isn't responsible for directly creating a
session but some code it calls indirectly in BufferedResponseMapper
attempts to locate a sessionId which for some reason, creates a session
if there is none yet:
protected boolean hasBufferedResponse(Url url)
{
I just checked with 1.5.x and for stateless pages all bookmarkable page
links do not incur the jsessionid suffix for a non cookie client. Once
an Ajax link is added to the page however the jsessionid suffix appears
on all links which makes sense as the page is no longer stateless once
Ajax gets
19 matches
Mail list logo
