hat only occur if the developer explicitly mounted non static
resources.
>
>>
>>>-Original Message-
>>>From: Martin Grigorov [mailto:mgrigo...@apache.org]
>>>Sent: Tuesday, 17 January 2012 7:20 AM
>>>To: users@wicket.apache.org
>>>Subje
gt; /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
>>Subje
igorov [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 you can exclude /wic
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 wrote:
> See org.apache.wicket.request.mapper.BasicResourceReferenceMapper#mapHandler
>
> All
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
wrote:
> JIRI
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
.@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
> wrote:
&g
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
&g
>Sent: 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
>wrote:
>>
for packaged resources we should not be adding jsessionid i dont think...
-igor
On Thu, Jan 12, 2012 at 1:56 AM, Martin Grigorov wrote:
> Create a ticket please
>
> On Wed, Jan 11, 2012 at 11:32 PM, Chris Colman
> wrote:
>> I just checked with 1.5.x and for stateless pages all bookmarkable page
Create a ticket please
On Wed, Jan 11, 2012 at 11:32 PM, Chris Colman
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 jsessionid suffix appears
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 inv
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 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.
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
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
>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
r will never end up trying
> to use a 'stale' .js file.
>
> Regards
> Chris
>
>
>
> From: Chris Colman [mailto:chr...@stepaheadsoftware.com]
> Sent: Wednesday, 11 January 2012 9:37 PM
> To: users@wicket.apache.org
> Subject:
:chr...@stepaheadsoftware.com]
>Sent: Wednesday, 11 January 2012 9:37 PM
>To: users@wicket.apache.org
>Subject: Javascript resources and jsessionid
>
>I realize that the servlet container is responsible for URL rewriting
>and hence adding the jsessionid but I was after an opinion:
>
>Is it
: Wednesday, 11 January 2012 9:37 PM
To: users@wicket.apache.org
Subject: Javascript resources and jsessionid
I realize that the servlet container is responsible for URL rewriting
and hence adding the jsessionid but I was after an opinion:
Is it right that Javascript resources get URLs rewritten
I realize that the servlet container is responsible for URL rewriting
and hence adding the jsessionid but I was after an opinion:
Is it right that Javascript resources get URLs rewritten to include the
jsessionid when search engines access a website?
(And indeed for normal users on their first vi
21 matches
Mail list logo
