You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Chris Colman <ch...@stepaheadsoftware.com> on 2012/12/23 14:05:22 UTC
Attempting to establish session for static resources in Wicket 6
A while ago when working with Wicket 1.5 we raised issue 4334 that dealt
with the problem of jsessoin ID's being present in static resource URLs
for the initial request and this issue was fixed.
Not requiring jsession ID in the URL meant there was no reason to ever
establish a session during requests for static resources i.e.
WebApplication#newSession was never called for static resource requests.
This worked very well but we've just discovered that in Wicket 6, even
though the URLs for static resources do not contain jsessionIDs there is
some code that is calling getSession - unnecessarily we believe (we hope
=] ).
Is there any reason why WebApplicatoin#newSession is called when no
session is required to service the static request? If not it would be
great if that call could be avoided.
Calling WebApplication#newSession on static resources becomes a problem
when you employ OpenSessionInView/OpenPersistenceManagerInView by using
a filter to wrap all Wicket requests within the context of an open
persistence session/manager. To optimize performance we use an 'ignore
list' that avoids wrapping the request if it is for a resource that
starts with a particular pattern (eg., /wicket/resource,/robots.txt)
We override WebApplication#newSession and do some fancy things whenever
a new session is established - this is intended for non static resource
requests. Some of this code assumes that there is an OpenSessionInView -
which fails in the case of static resources because their URLs are part
of the ignore list and so the request was not wrapped within an open
persistence session/manager.
I was hoping that Wicket 6 could be fixed to avoid the call to
newSession like Wicket 1.5 did after the resolution of 4334.
Here's a stack trace of a call that is servicing a request for a wicket
static resource:
2012/12/23 23:16:24.607 ERROR - DefaultExceptionMapper - unexpected
exception when handling another exception: null
java.lang.NullPointerException
at
com.sas.av.model.context.EServerContext.establishSiteVisitorForCrawler(E
ServerContext.java:3055)
at
com.sas.av.model.context.EServerContext.initSession(EServerContext.java:
3585)
at
com.sas.av.ui.wicket.templates.WicketModelExposerApplication.newSession(
WicketModelExposerApplication.java:148)
at
org.apache.wicket.Application.fetchCreateAndSetSession(Application.java:
1557)
at org.apache.wicket.Session.get(Session.java:152)
at
org.apache.wicket.RestartResponseAtInterceptPageException$InterceptData.
get(RestartResponseAtInterceptPageException.java:146)
at
org.apache.wicket.RestartResponseAtInterceptPageException$1.matchedData(
RestartResponseAtInterceptPageException.java:211)
at
org.apache.wicket.RestartResponseAtInterceptPageException$1.getCompatibi
lityScore(RestartResponseAtInterceptPageException.java:179)
at
org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(Compou
ndRequestMapper.java:138)
at
org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(Reque
stCycle.java:183)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle
.java:208)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(Req
uestCycle.java:282)
at
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketF
ilter.java:244)
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter
.java:188)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:
267)
at
com.sas.av.ui.wicket.templates.original.PagebloomFilter.doFilter(Pageblo
omFilter.java:96)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:206)
at
com.sas.av.model.context.UrlRedirectorFilter.doFilter(UrlRedirectorFilte
r.java:93)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:206)
at
com.sas.framework.expojo.servlet.ExpojoServletFilter.doFilter(ExpojoServ
letFilter.java:137)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:206)
at
com.sas.util.web.StaticResponseHeaderFilter.doFilter(Unknown Source)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:102)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568
)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
86)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:84
5)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:662)
Yours sincerely,
Chris Colman
Re: Attempting to establish session for static resources in Wicket 6
Posted by Martin Grigorov <mg...@apache.org>.
I don't remember the details now.
Chris confirmed privately that he will re-test his scenario.
I'll be able to take a look at this soon.
On Thu, Dec 27, 2012 at 12:50 PM, Sven Meier <sv...@meiers.net> wrote:
> Sorry, I wasn't aware of this back and forth.
>
> It's not clear to me how 7a86fe3 'fixed' WICKET-4500 though:
> If there's no session, how does it help to create one and then looking for
> non-present meta data?
>
> Sven
>
>
> On 12/27/2012 09:55 AM, Martin Grigorov wrote:
>
>> The improvement made by Sven has been introduced earlier with 7beaa9f and
>> later reverted because of https://issues.apache.org/**
>> jira/browse/WICKET-4500<https://issues.apache.org/jira/browse/WICKET-4500>
>> (7a86fe3)
>> I.e. WICKET-4500 should be valid again.
>> @Chris Colman: Please retest it.
>>
>>
>> On Mon, Dec 24, 2012 at 2:09 AM, Chris Colman
>> <ch...@stepaheadsoftware.com>**wrote:
>>
>> Ah excellent! Thanks Sven.
>>>
>>> I was thinking about the creation of a simple test to be added to the
>>> test suite that would override WebApplication#newSession and then make a
>>> request for a static resource and then throw an exception if newSession
>>> gets called. This would help trap any future regression of this issue.
>>>
>>> Hi Chris,
>>>>
>>>> as already written, these are temporary sessions that should do no
>>>>
>>> harm.
>>>
>>>> Nevertheless I've added a check into
>>>> RestartResponseAtInterceptPage**Exception#InterceptData (which probes
>>>> every request to be able to restore post parameters from before an
>>>> intercept page) whether a session exists:
>>>>
>>>> public static InterceptData get()
>>>> {
>>>> - return Session.get().getMetaData(key)**;
>>>> + if (Session.exists())
>>>> + {
>>>> + return Session.get().getMetaData(key)**
>>>> ;
>>>> + }
>>>> + return null;
>>>> }
>>>>
>>>> Your particular stacktrace below should no longer trigger the creation
>>>> of a session now.
>>>>
>>>> Sven
>>>>
>>>>
>>>> On 12/23/2012 02:05 PM, Chris Colman wrote:
>>>>
>>>>> A while ago when working with Wicket 1.5 we raised issue 4334 that
>>>>>
>>>> dealt
>>>
>>>> with the problem of jsessoin ID's being present in static resource
>>>>>
>>>> URLs
>>>
>>>> for the initial request and this issue was fixed.
>>>>>
>>>>> Not requiring jsession ID in the URL meant there was no reason to
>>>>>
>>>> ever
>>>
>>>> establish a session during requests for static resources i.e.
>>>>> WebApplication#newSession was never called for static resource
>>>>>
>>>> requests.
>>>
>>>> This worked very well but we've just discovered that in Wicket 6,
>>>>>
>>>> even
>>>
>>>> though the URLs for static resources do not contain jsessionIDs there
>>>>>
>>>> is
>>>
>>>> some code that is calling getSession - unnecessarily we believe (we
>>>>>
>>>> hope
>>>
>>>> =] ).
>>>>>
>>>>> Is there any reason why WebApplicatoin#newSession is called when no
>>>>> session is required to service the static request? If not it would be
>>>>> great if that call could be avoided.
>>>>>
>>>>> Calling WebApplication#newSession on static resources becomes a
>>>>>
>>>> problem
>>>
>>>> when you employ OpenSessionInView/**OpenPersistenceManagerInView by
>>>>>
>>>> using
>>>
>>>> a filter to wrap all Wicket requests within the context of an open
>>>>> persistence session/manager. To optimize performance we use an
>>>>>
>>>> 'ignore
>>>
>>>> list' that avoids wrapping the request if it is for a resource that
>>>>> starts with a particular pattern (eg., /wicket/resource,/robots.txt)
>>>>>
>>>>> We override WebApplication#newSession and do some fancy things
>>>>>
>>>> whenever
>>>
>>>> a new session is established - this is intended for non static
>>>>>
>>>> resource
>>>
>>>> requests. Some of this code assumes that there is an
>>>>>
>>>> OpenSessionInView -
>>>
>>>> which fails in the case of static resources because their URLs are
>>>>>
>>>> part
>>>
>>>> of the ignore list and so the request was not wrapped within an open
>>>>> persistence session/manager.
>>>>>
>>>>> I was hoping that Wicket 6 could be fixed to avoid the call to
>>>>> newSession like Wicket 1.5 did after the resolution of 4334.
>>>>>
>>>>> Here's a stack trace of a call that is servicing a request for a
>>>>>
>>>> wicket
>>>
>>>> static resource:
>>>>>
>>>>> 2012/12/23 23:16:24.607 ERROR - DefaultExceptionMapper -
>>>>>
>>>> unexpected
>>>
>>>> exception when handling another exception: null
>>>>> java.lang.NullPointerException
>>>>> at
>>>>>
>>>>> com.sas.av.model.context.**EServerContext.**
>>> establishSiteVisitorForCrawler**(E
>>>
>>>> ServerContext.java:3055)
>>>>> at
>>>>>
>>>>> com.sas.av.model.context.**EServerContext.initSession(**
>>> EServerContext.java:
>>>
>>>> 3585)
>>>>> at
>>>>>
>>>>> com.sas.av.ui.wicket.**templates.**WicketModelExposerApplication.**
>>> newSession(
>>>
>>>> WicketModelExposerApplication.**java:148)
>>>>> at
>>>>>
>>>>> org.apache.wicket.Application.**fetchCreateAndSetSession(**
>>> Application.java:
>>>
>>>> 1557)
>>>>> at org.apache.wicket.Session.get(**Session.java:152)
>>>>> at
>>>>>
>>>>> org.apache.wicket.**RestartResponseAtInterceptPage**
>>> Exception$InterceptData.
>>>
>>>> get(**RestartResponseAtInterceptPage**Exception.java:146)
>>>>> at
>>>>>
>>>>> org.apache.wicket.**RestartResponseAtInterceptPage**
>>> Exception$1.matchedData(
>>>
>>>> RestartResponseAtInterceptPage**Exception.java:211)
>>>>> at
>>>>>
>>>>> org.apache.wicket.**RestartResponseAtInterceptPage**
>>> Exception$1.getCompatibi
>>>
>>>> lityScore(**RestartResponseAtInterceptPage**Exception.java:179)
>>>>> at
>>>>>
>>>>> org.apache.wicket.request.**mapper.CompoundRequestMapper.**
>>> mapRequest(Compou
>>>
>>>> ndRequestMapper.java:138)
>>>>> at
>>>>>
>>>>> org.apache.wicket.request.**cycle.RequestCycle.**
>>> resolveRequestHandler(Reque
>>>
>>>> stCycle.java:183)
>>>>> at
>>>>>
>>>>> org.apache.wicket.request.**cycle.RequestCycle.**
>>> processRequest(RequestCycle
>>>
>>>> .java:208)
>>>>> at
>>>>>
>>>>> org.apache.wicket.request.**cycle.RequestCycle.**
>>> processRequestAndDetach(Req
>>>
>>>> uestCycle.java:282)
>>>>> at
>>>>>
>>>>> org.apache.wicket.protocol.**http.WicketFilter.**
>>> processRequestCycle(WicketF
>>>
>>>> ilter.java:244)
>>>>> at
>>>>>
>>>>> org.apache.wicket.protocol.**http.WicketFilter.**
>>> processRequest(WicketFilter
>>>
>>>> .java:188)
>>>>> at
>>>>>
>>>>> org.apache.wicket.protocol.**http.WicketFilter.doFilter(**
>>> WicketFilter.java:
>>>
>>>> 267)
>>>>> at
>>>>>
>>>>> com.sas.av.ui.wicket.**templates.original.**PagebloomFilter.doFilter(
>>> **Pageblo
>>>
>>>> omFilter.java:96)
>>>>> at
>>>>>
>>>>> org.apache.catalina.core.**ApplicationFilterChain.**
>>> internalDoFilter(Applica
>>>
>>>> tionFilterChain.java:235)
>>>>> at
>>>>>
>>>>> org.apache.catalina.core.**ApplicationFilterChain.**
>>> doFilter(ApplicationFilt
>>>
>>>> erChain.java:206)
>>>>> at
>>>>>
>>>>> com.sas.av.model.context.**UrlRedirectorFilter.doFilter(**
>>> UrlRedirectorFilte
>>>
>>>> r.java:93)
>>>>> at
>>>>>
>>>>> org.apache.catalina.core.**ApplicationFilterChain.**
>>> internalDoFilter(Applica
>>>
>>>> tionFilterChain.java:235)
>>>>> at
>>>>>
>>>>> org.apache.catalina.core.**ApplicationFilterChain.**
>>> doFilter(ApplicationFilt
>>>
>>>> erChain.java:206)
>>>>> at
>>>>>
>>>>> com.sas.framework.expojo.**servlet.ExpojoServletFilter.**
>>> doFilter(ExpojoServ
>>>
>>>> letFilter.java:137)
>>>>> at
>>>>>
>>>>> org.apache.catalina.core.**ApplicationFilterChain.**
>>> internalDoFilter(Applica
>>>
>>>> tionFilterChain.java:235)
>>>>> at
>>>>>
>>>>> org.apache.catalina.core.**ApplicationFilterChain.**
>>> doFilter(ApplicationFilt
>>>
>>>> erChain.java:206)
>>>>> at
>>>>> com.sas.util.web.**StaticResponseHeaderFilter.**doFilter(Unknown
>>>>> Source)
>>>>> at
>>>>>
>>>>> org.apache.catalina.core.**ApplicationFilterChain.**
>>> internalDoFilter(Applica
>>>
>>>> tionFilterChain.java:235)
>>>>> at
>>>>>
>>>>> org.apache.catalina.core.**ApplicationFilterChain.**
>>> doFilter(ApplicationFilt
>>>
>>>> erChain.java:206)
>>>>> at
>>>>>
>>>>> org.apache.catalina.core.**StandardWrapperValve.invoke(**
>>> StandardWrapperValv
>>>
>>>> e.java:233)
>>>>> at
>>>>>
>>>>> org.apache.catalina.core.**StandardContextValve.invoke(**
>>> StandardContextValv
>>>
>>>> e.java:191)
>>>>> at
>>>>>
>>>>> org.apache.catalina.core.**StandardHostValve.invoke(**
>>> StandardHostValve.java
>>>
>>>> :128)
>>>>> at
>>>>>
>>>>> org.apache.catalina.valves.**ErrorReportValve.invoke(**
>>> ErrorReportValve.java
>>>
>>>> :102)
>>>>> at
>>>>>
>>>>> org.apache.catalina.valves.**AccessLogValve.invoke(**
>>> AccessLogValve.java:568
>>>
>>>> )
>>>>> at
>>>>>
>>>>> org.apache.catalina.core.**StandardEngineValve.invoke(**
>>> StandardEngineValve.
>>>
>>>> java:109)
>>>>> at
>>>>>
>>>>> org.apache.catalina.connector.**CoyoteAdapter.service(**
>>> CoyoteAdapter.java:2
>>>
>>>> 86)
>>>>> at
>>>>>
>>>>> org.apache.coyote.http11.**Http11Processor.process(**
>>> Http11Processor.java:84
>>>
>>>> 5)
>>>>> at
>>>>>
>>>>> org.apache.coyote.http11.**Http11Protocol$**Http11ConnectionHandler.*
>>> *process(
>>>
>>>> Http11Protocol.java:583)
>>>>> at
>>>>>
>>>>> org.apache.tomcat.util.net.**JIoEndpoint$Worker.run(**
>>> JIoEndpoint.java:447)
>>>
>>>> at java.lang.Thread.run(Thread.**java:662)
>>>>>
>>>>> Yours sincerely,
>>>>>
>>>>> Chris Colman
>>>>>
>>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>
Re: Attempting to establish session for static resources in Wicket
6
Posted by Sven Meier <sv...@meiers.net>.
Sorry, I wasn't aware of this back and forth.
It's not clear to me how 7a86fe3 'fixed' WICKET-4500 though:
If there's no session, how does it help to create one and then looking
for non-present meta data?
Sven
On 12/27/2012 09:55 AM, Martin Grigorov wrote:
> The improvement made by Sven has been introduced earlier with 7beaa9f and
> later reverted because of https://issues.apache.org/jira/browse/WICKET-4500
> (7a86fe3)
> I.e. WICKET-4500 should be valid again.
> @Chris Colman: Please retest it.
>
>
> On Mon, Dec 24, 2012 at 2:09 AM, Chris Colman
> <ch...@stepaheadsoftware.com>wrote:
>
>> Ah excellent! Thanks Sven.
>>
>> I was thinking about the creation of a simple test to be added to the
>> test suite that would override WebApplication#newSession and then make a
>> request for a static resource and then throw an exception if newSession
>> gets called. This would help trap any future regression of this issue.
>>
>>> Hi Chris,
>>>
>>> as already written, these are temporary sessions that should do no
>> harm.
>>> Nevertheless I've added a check into
>>> RestartResponseAtInterceptPageException#InterceptData (which probes
>>> every request to be able to restore post parameters from before an
>>> intercept page) whether a session exists:
>>>
>>> public static InterceptData get()
>>> {
>>> - return Session.get().getMetaData(key);
>>> + if (Session.exists())
>>> + {
>>> + return Session.get().getMetaData(key);
>>> + }
>>> + return null;
>>> }
>>>
>>> Your particular stacktrace below should no longer trigger the creation
>>> of a session now.
>>>
>>> Sven
>>>
>>>
>>> On 12/23/2012 02:05 PM, Chris Colman wrote:
>>>> A while ago when working with Wicket 1.5 we raised issue 4334 that
>> dealt
>>>> with the problem of jsessoin ID's being present in static resource
>> URLs
>>>> for the initial request and this issue was fixed.
>>>>
>>>> Not requiring jsession ID in the URL meant there was no reason to
>> ever
>>>> establish a session during requests for static resources i.e.
>>>> WebApplication#newSession was never called for static resource
>> requests.
>>>> This worked very well but we've just discovered that in Wicket 6,
>> even
>>>> though the URLs for static resources do not contain jsessionIDs there
>> is
>>>> some code that is calling getSession - unnecessarily we believe (we
>> hope
>>>> =] ).
>>>>
>>>> Is there any reason why WebApplicatoin#newSession is called when no
>>>> session is required to service the static request? If not it would be
>>>> great if that call could be avoided.
>>>>
>>>> Calling WebApplication#newSession on static resources becomes a
>> problem
>>>> when you employ OpenSessionInView/OpenPersistenceManagerInView by
>> using
>>>> a filter to wrap all Wicket requests within the context of an open
>>>> persistence session/manager. To optimize performance we use an
>> 'ignore
>>>> list' that avoids wrapping the request if it is for a resource that
>>>> starts with a particular pattern (eg., /wicket/resource,/robots.txt)
>>>>
>>>> We override WebApplication#newSession and do some fancy things
>> whenever
>>>> a new session is established - this is intended for non static
>> resource
>>>> requests. Some of this code assumes that there is an
>> OpenSessionInView -
>>>> which fails in the case of static resources because their URLs are
>> part
>>>> of the ignore list and so the request was not wrapped within an open
>>>> persistence session/manager.
>>>>
>>>> I was hoping that Wicket 6 could be fixed to avoid the call to
>>>> newSession like Wicket 1.5 did after the resolution of 4334.
>>>>
>>>> Here's a stack trace of a call that is servicing a request for a
>> wicket
>>>> static resource:
>>>>
>>>> 2012/12/23 23:16:24.607 ERROR - DefaultExceptionMapper -
>> unexpected
>>>> exception when handling another exception: null
>>>> java.lang.NullPointerException
>>>> at
>>>>
>> com.sas.av.model.context.EServerContext.establishSiteVisitorForCrawler(E
>>>> ServerContext.java:3055)
>>>> at
>>>>
>> com.sas.av.model.context.EServerContext.initSession(EServerContext.java:
>>>> 3585)
>>>> at
>>>>
>> com.sas.av.ui.wicket.templates.WicketModelExposerApplication.newSession(
>>>> WicketModelExposerApplication.java:148)
>>>> at
>>>>
>> org.apache.wicket.Application.fetchCreateAndSetSession(Application.java:
>>>> 1557)
>>>> at org.apache.wicket.Session.get(Session.java:152)
>>>> at
>>>>
>> org.apache.wicket.RestartResponseAtInterceptPageException$InterceptData.
>>>> get(RestartResponseAtInterceptPageException.java:146)
>>>> at
>>>>
>> org.apache.wicket.RestartResponseAtInterceptPageException$1.matchedData(
>>>> RestartResponseAtInterceptPageException.java:211)
>>>> at
>>>>
>> org.apache.wicket.RestartResponseAtInterceptPageException$1.getCompatibi
>>>> lityScore(RestartResponseAtInterceptPageException.java:179)
>>>> at
>>>>
>> org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(Compou
>>>> ndRequestMapper.java:138)
>>>> at
>>>>
>> org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(Reque
>>>> stCycle.java:183)
>>>> at
>>>>
>> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle
>>>> .java:208)
>>>> at
>>>>
>> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(Req
>>>> uestCycle.java:282)
>>>> at
>>>>
>> org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketF
>>>> ilter.java:244)
>>>> at
>>>>
>> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter
>>>> .java:188)
>>>> at
>>>>
>> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:
>>>> 267)
>>>> at
>>>>
>> com.sas.av.ui.wicket.templates.original.PagebloomFilter.doFilter(Pageblo
>>>> omFilter.java:96)
>>>> at
>>>>
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>>>> tionFilterChain.java:235)
>>>> at
>>>>
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>>>> erChain.java:206)
>>>> at
>>>>
>> com.sas.av.model.context.UrlRedirectorFilter.doFilter(UrlRedirectorFilte
>>>> r.java:93)
>>>> at
>>>>
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>>>> tionFilterChain.java:235)
>>>> at
>>>>
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>>>> erChain.java:206)
>>>> at
>>>>
>> com.sas.framework.expojo.servlet.ExpojoServletFilter.doFilter(ExpojoServ
>>>> letFilter.java:137)
>>>> at
>>>>
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>>>> tionFilterChain.java:235)
>>>> at
>>>>
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>>>> erChain.java:206)
>>>> at
>>>> com.sas.util.web.StaticResponseHeaderFilter.doFilter(Unknown Source)
>>>> at
>>>>
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>>>> tionFilterChain.java:235)
>>>> at
>>>>
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>>>> erChain.java:206)
>>>> at
>>>>
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
>>>> e.java:233)
>>>> at
>>>>
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
>>>> e.java:191)
>>>> at
>>>>
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
>>>> :128)
>>>> at
>>>>
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
>>>> :102)
>>>> at
>>>>
>> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568
>>>> )
>>>> at
>>>>
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
>>>> java:109)
>>>> at
>>>>
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
>>>> 86)
>>>> at
>>>>
>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:84
>>>> 5)
>>>> at
>>>>
>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
>>>> Http11Protocol.java:583)
>>>> at
>>>>
>> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>>>> at java.lang.Thread.run(Thread.java:662)
>>>>
>>>> Yours sincerely,
>>>>
>>>> Chris Colman
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Attempting to establish session for static resources in Wicket 6
Posted by Martin Grigorov <mg...@apache.org>.
The improvement made by Sven has been introduced earlier with 7beaa9f and
later reverted because of https://issues.apache.org/jira/browse/WICKET-4500
(7a86fe3)
I.e. WICKET-4500 should be valid again.
@Chris Colman: Please retest it.
On Mon, Dec 24, 2012 at 2:09 AM, Chris Colman
<ch...@stepaheadsoftware.com>wrote:
> Ah excellent! Thanks Sven.
>
> I was thinking about the creation of a simple test to be added to the
> test suite that would override WebApplication#newSession and then make a
> request for a static resource and then throw an exception if newSession
> gets called. This would help trap any future regression of this issue.
>
> >
> >Hi Chris,
> >
> >as already written, these are temporary sessions that should do no
> harm.
> >
> >Nevertheless I've added a check into
> >RestartResponseAtInterceptPageException#InterceptData (which probes
> >every request to be able to restore post parameters from before an
> >intercept page) whether a session exists:
> >
> > public static InterceptData get()
> > {
> >- return Session.get().getMetaData(key);
> >+ if (Session.exists())
> >+ {
> >+ return Session.get().getMetaData(key);
> >+ }
> >+ return null;
> > }
> >
> >Your particular stacktrace below should no longer trigger the creation
> >of a session now.
> >
> >Sven
> >
> >
> >On 12/23/2012 02:05 PM, Chris Colman wrote:
> >> A while ago when working with Wicket 1.5 we raised issue 4334 that
> dealt
> >> with the problem of jsessoin ID's being present in static resource
> URLs
> >> for the initial request and this issue was fixed.
> >>
> >> Not requiring jsession ID in the URL meant there was no reason to
> ever
> >> establish a session during requests for static resources i.e.
> >> WebApplication#newSession was never called for static resource
> requests.
> >> This worked very well but we've just discovered that in Wicket 6,
> even
> >> though the URLs for static resources do not contain jsessionIDs there
> is
> >> some code that is calling getSession - unnecessarily we believe (we
> hope
> >> =] ).
> >>
> >> Is there any reason why WebApplicatoin#newSession is called when no
> >> session is required to service the static request? If not it would be
> >> great if that call could be avoided.
> >>
> >> Calling WebApplication#newSession on static resources becomes a
> problem
> >> when you employ OpenSessionInView/OpenPersistenceManagerInView by
> using
> >> a filter to wrap all Wicket requests within the context of an open
> >> persistence session/manager. To optimize performance we use an
> 'ignore
> >> list' that avoids wrapping the request if it is for a resource that
> >> starts with a particular pattern (eg., /wicket/resource,/robots.txt)
> >>
> >> We override WebApplication#newSession and do some fancy things
> whenever
> >> a new session is established - this is intended for non static
> resource
> >> requests. Some of this code assumes that there is an
> OpenSessionInView -
> >> which fails in the case of static resources because their URLs are
> part
> >> of the ignore list and so the request was not wrapped within an open
> >> persistence session/manager.
> >>
> >> I was hoping that Wicket 6 could be fixed to avoid the call to
> >> newSession like Wicket 1.5 did after the resolution of 4334.
> >>
> >> Here's a stack trace of a call that is servicing a request for a
> wicket
> >> static resource:
> >>
> >> 2012/12/23 23:16:24.607 ERROR - DefaultExceptionMapper -
> unexpected
> >> exception when handling another exception: null
> >> java.lang.NullPointerException
> >> at
> >>
> com.sas.av.model.context.EServerContext.establishSiteVisitorForCrawler(E
> >> ServerContext.java:3055)
> >> at
> >>
> com.sas.av.model.context.EServerContext.initSession(EServerContext.java:
> >> 3585)
> >> at
> >>
> com.sas.av.ui.wicket.templates.WicketModelExposerApplication.newSession(
> >> WicketModelExposerApplication.java:148)
> >> at
> >>
> org.apache.wicket.Application.fetchCreateAndSetSession(Application.java:
> >> 1557)
> >> at org.apache.wicket.Session.get(Session.java:152)
> >> at
> >>
> org.apache.wicket.RestartResponseAtInterceptPageException$InterceptData.
> >> get(RestartResponseAtInterceptPageException.java:146)
> >> at
> >>
> org.apache.wicket.RestartResponseAtInterceptPageException$1.matchedData(
> >> RestartResponseAtInterceptPageException.java:211)
> >> at
> >>
> org.apache.wicket.RestartResponseAtInterceptPageException$1.getCompatibi
> >> lityScore(RestartResponseAtInterceptPageException.java:179)
> >> at
> >>
> org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(Compou
> >> ndRequestMapper.java:138)
> >> at
> >>
> org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(Reque
> >> stCycle.java:183)
> >> at
> >>
> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle
> >> .java:208)
> >> at
> >>
> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(Req
> >> uestCycle.java:282)
> >> at
> >>
> org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketF
> >> ilter.java:244)
> >> at
> >>
> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter
> >> .java:188)
> >> at
> >>
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:
> >> 267)
> >> at
> >>
> com.sas.av.ui.wicket.templates.original.PagebloomFilter.doFilter(Pageblo
> >> omFilter.java:96)
> >> at
> >>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
> >> tionFilterChain.java:235)
> >> at
> >>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> >> erChain.java:206)
> >> at
> >>
> com.sas.av.model.context.UrlRedirectorFilter.doFilter(UrlRedirectorFilte
> >> r.java:93)
> >> at
> >>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
> >> tionFilterChain.java:235)
> >> at
> >>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> >> erChain.java:206)
> >> at
> >>
> com.sas.framework.expojo.servlet.ExpojoServletFilter.doFilter(ExpojoServ
> >> letFilter.java:137)
> >> at
> >>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
> >> tionFilterChain.java:235)
> >> at
> >>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> >> erChain.java:206)
> >> at
> >> com.sas.util.web.StaticResponseHeaderFilter.doFilter(Unknown Source)
> >> at
> >>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
> >> tionFilterChain.java:235)
> >> at
> >>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> >> erChain.java:206)
> >> at
> >>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
> >> e.java:233)
> >> at
> >>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
> >> e.java:191)
> >> at
> >>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
> >> :128)
> >> at
> >>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
> >> :102)
> >> at
> >>
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568
> >> )
> >> at
> >>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
> >> java:109)
> >> at
> >>
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
> >> 86)
> >> at
> >>
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:84
> >> 5)
> >> at
> >>
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
> >> Http11Protocol.java:583)
> >> at
> >>
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> >> at java.lang.Thread.run(Thread.java:662)
> >>
> >> Yours sincerely,
> >>
> >> Chris Colman
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>
RE: Attempting to establish session for static resources in Wicket 6
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
Ah excellent! Thanks Sven.
I was thinking about the creation of a simple test to be added to the
test suite that would override WebApplication#newSession and then make a
request for a static resource and then throw an exception if newSession
gets called. This would help trap any future regression of this issue.
>
>Hi Chris,
>
>as already written, these are temporary sessions that should do no
harm.
>
>Nevertheless I've added a check into
>RestartResponseAtInterceptPageException#InterceptData (which probes
>every request to be able to restore post parameters from before an
>intercept page) whether a session exists:
>
> public static InterceptData get()
> {
>- return Session.get().getMetaData(key);
>+ if (Session.exists())
>+ {
>+ return Session.get().getMetaData(key);
>+ }
>+ return null;
> }
>
>Your particular stacktrace below should no longer trigger the creation
>of a session now.
>
>Sven
>
>
>On 12/23/2012 02:05 PM, Chris Colman wrote:
>> A while ago when working with Wicket 1.5 we raised issue 4334 that
dealt
>> with the problem of jsessoin ID's being present in static resource
URLs
>> for the initial request and this issue was fixed.
>>
>> Not requiring jsession ID in the URL meant there was no reason to
ever
>> establish a session during requests for static resources i.e.
>> WebApplication#newSession was never called for static resource
requests.
>> This worked very well but we've just discovered that in Wicket 6,
even
>> though the URLs for static resources do not contain jsessionIDs there
is
>> some code that is calling getSession - unnecessarily we believe (we
hope
>> =] ).
>>
>> Is there any reason why WebApplicatoin#newSession is called when no
>> session is required to service the static request? If not it would be
>> great if that call could be avoided.
>>
>> Calling WebApplication#newSession on static resources becomes a
problem
>> when you employ OpenSessionInView/OpenPersistenceManagerInView by
using
>> a filter to wrap all Wicket requests within the context of an open
>> persistence session/manager. To optimize performance we use an
'ignore
>> list' that avoids wrapping the request if it is for a resource that
>> starts with a particular pattern (eg., /wicket/resource,/robots.txt)
>>
>> We override WebApplication#newSession and do some fancy things
whenever
>> a new session is established - this is intended for non static
resource
>> requests. Some of this code assumes that there is an
OpenSessionInView -
>> which fails in the case of static resources because their URLs are
part
>> of the ignore list and so the request was not wrapped within an open
>> persistence session/manager.
>>
>> I was hoping that Wicket 6 could be fixed to avoid the call to
>> newSession like Wicket 1.5 did after the resolution of 4334.
>>
>> Here's a stack trace of a call that is servicing a request for a
wicket
>> static resource:
>>
>> 2012/12/23 23:16:24.607 ERROR - DefaultExceptionMapper -
unexpected
>> exception when handling another exception: null
>> java.lang.NullPointerException
>> at
>>
com.sas.av.model.context.EServerContext.establishSiteVisitorForCrawler(E
>> ServerContext.java:3055)
>> at
>>
com.sas.av.model.context.EServerContext.initSession(EServerContext.java:
>> 3585)
>> at
>>
com.sas.av.ui.wicket.templates.WicketModelExposerApplication.newSession(
>> WicketModelExposerApplication.java:148)
>> at
>>
org.apache.wicket.Application.fetchCreateAndSetSession(Application.java:
>> 1557)
>> at org.apache.wicket.Session.get(Session.java:152)
>> at
>>
org.apache.wicket.RestartResponseAtInterceptPageException$InterceptData.
>> get(RestartResponseAtInterceptPageException.java:146)
>> at
>>
org.apache.wicket.RestartResponseAtInterceptPageException$1.matchedData(
>> RestartResponseAtInterceptPageException.java:211)
>> at
>>
org.apache.wicket.RestartResponseAtInterceptPageException$1.getCompatibi
>> lityScore(RestartResponseAtInterceptPageException.java:179)
>> at
>>
org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(Compou
>> ndRequestMapper.java:138)
>> at
>>
org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(Reque
>> stCycle.java:183)
>> at
>>
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle
>> .java:208)
>> at
>>
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(Req
>> uestCycle.java:282)
>> at
>>
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketF
>> ilter.java:244)
>> at
>>
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter
>> .java:188)
>> at
>>
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:
>> 267)
>> at
>>
com.sas.av.ui.wicket.templates.original.PagebloomFilter.doFilter(Pageblo
>> omFilter.java:96)
>> at
>>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>> tionFilterChain.java:235)
>> at
>>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>> erChain.java:206)
>> at
>>
com.sas.av.model.context.UrlRedirectorFilter.doFilter(UrlRedirectorFilte
>> r.java:93)
>> at
>>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>> tionFilterChain.java:235)
>> at
>>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>> erChain.java:206)
>> at
>>
com.sas.framework.expojo.servlet.ExpojoServletFilter.doFilter(ExpojoServ
>> letFilter.java:137)
>> at
>>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>> tionFilterChain.java:235)
>> at
>>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>> erChain.java:206)
>> at
>> com.sas.util.web.StaticResponseHeaderFilter.doFilter(Unknown Source)
>> at
>>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>> tionFilterChain.java:235)
>> at
>>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>> erChain.java:206)
>> at
>>
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
>> e.java:233)
>> at
>>
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
>> e.java:191)
>> at
>>
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
>> :128)
>> at
>>
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
>> :102)
>> at
>>
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568
>> )
>> at
>>
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
>> java:109)
>> at
>>
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
>> 86)
>> at
>>
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:84
>> 5)
>> at
>>
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
>> Http11Protocol.java:583)
>> at
>>
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>> at java.lang.Thread.run(Thread.java:662)
>>
>> Yours sincerely,
>>
>> Chris Colman
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Attempting to establish session for static resources in Wicket
6
Posted by Sven Meier <sv...@meiers.net>.
Hi Chris,
as already written, these are temporary sessions that should do no harm.
Nevertheless I've added a check into
RestartResponseAtInterceptPageException#InterceptData (which probes
every request to be able to restore post parameters from before an
intercept page) whether a session exists:
public static InterceptData get()
{
- return Session.get().getMetaData(key);
+ if (Session.exists())
+ {
+ return Session.get().getMetaData(key);
+ }
+ return null;
}
Your particular stacktrace below should no longer trigger the creation
of a session now.
Sven
On 12/23/2012 02:05 PM, Chris Colman wrote:
> A while ago when working with Wicket 1.5 we raised issue 4334 that dealt
> with the problem of jsessoin ID's being present in static resource URLs
> for the initial request and this issue was fixed.
>
> Not requiring jsession ID in the URL meant there was no reason to ever
> establish a session during requests for static resources i.e.
> WebApplication#newSession was never called for static resource requests.
> This worked very well but we've just discovered that in Wicket 6, even
> though the URLs for static resources do not contain jsessionIDs there is
> some code that is calling getSession - unnecessarily we believe (we hope
> =] ).
>
> Is there any reason why WebApplicatoin#newSession is called when no
> session is required to service the static request? If not it would be
> great if that call could be avoided.
>
> Calling WebApplication#newSession on static resources becomes a problem
> when you employ OpenSessionInView/OpenPersistenceManagerInView by using
> a filter to wrap all Wicket requests within the context of an open
> persistence session/manager. To optimize performance we use an 'ignore
> list' that avoids wrapping the request if it is for a resource that
> starts with a particular pattern (eg., /wicket/resource,/robots.txt)
>
> We override WebApplication#newSession and do some fancy things whenever
> a new session is established - this is intended for non static resource
> requests. Some of this code assumes that there is an OpenSessionInView -
> which fails in the case of static resources because their URLs are part
> of the ignore list and so the request was not wrapped within an open
> persistence session/manager.
>
> I was hoping that Wicket 6 could be fixed to avoid the call to
> newSession like Wicket 1.5 did after the resolution of 4334.
>
> Here's a stack trace of a call that is servicing a request for a wicket
> static resource:
>
> 2012/12/23 23:16:24.607 ERROR - DefaultExceptionMapper - unexpected
> exception when handling another exception: null
> java.lang.NullPointerException
> at
> com.sas.av.model.context.EServerContext.establishSiteVisitorForCrawler(E
> ServerContext.java:3055)
> at
> com.sas.av.model.context.EServerContext.initSession(EServerContext.java:
> 3585)
> at
> com.sas.av.ui.wicket.templates.WicketModelExposerApplication.newSession(
> WicketModelExposerApplication.java:148)
> at
> org.apache.wicket.Application.fetchCreateAndSetSession(Application.java:
> 1557)
> at org.apache.wicket.Session.get(Session.java:152)
> at
> org.apache.wicket.RestartResponseAtInterceptPageException$InterceptData.
> get(RestartResponseAtInterceptPageException.java:146)
> at
> org.apache.wicket.RestartResponseAtInterceptPageException$1.matchedData(
> RestartResponseAtInterceptPageException.java:211)
> at
> org.apache.wicket.RestartResponseAtInterceptPageException$1.getCompatibi
> lityScore(RestartResponseAtInterceptPageException.java:179)
> at
> org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(Compou
> ndRequestMapper.java:138)
> at
> org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(Reque
> stCycle.java:183)
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle
> .java:208)
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(Req
> uestCycle.java:282)
> at
> org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketF
> ilter.java:244)
> at
> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter
> .java:188)
> at
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:
> 267)
> at
> com.sas.av.ui.wicket.templates.original.PagebloomFilter.doFilter(Pageblo
> omFilter.java:96)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
> tionFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> erChain.java:206)
> at
> com.sas.av.model.context.UrlRedirectorFilter.doFilter(UrlRedirectorFilte
> r.java:93)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
> tionFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> erChain.java:206)
> at
> com.sas.framework.expojo.servlet.ExpojoServletFilter.doFilter(ExpojoServ
> letFilter.java:137)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
> tionFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> erChain.java:206)
> at
> com.sas.util.web.StaticResponseHeaderFilter.doFilter(Unknown Source)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
> tionFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> erChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
> e.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
> e.java:191)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
> :128)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
> :102)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568
> )
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
> java:109)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
> 86)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:84
> 5)
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
> Http11Protocol.java:583)
> at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> at java.lang.Thread.run(Thread.java:662)
>
> Yours sincerely,
>
> Chris Colman
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Attempting to establish session for static resources in Wicket 6
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
>I don't remember quite well how it used to work with 1.5, but looking
at
>your stacktrace I see you used some kind of redirection policy that
>involves class RestartResponseAtInterceptPageException.
I had the same reaction when I first saw the redirect but I can assure
you that we're not doing any redirect. In fact I put a break point on
the constructor of RestartResponseAtInterceptPageException but none are
instantiated during this execution.
No instance of RestartResponseAtInterceptPageExtension is created but
rather an anonymous instance of an inner class defined within that
class, an instance of IRequestMapper, is being used.
When attempting to service a request for a static resource the following
loop is executed and at some stage 'mapper', the iteration variable,
becomes an instance of:
org.apache.wicket.RestartResponseAtInterceptPageException$1
for (IRequestMapper mapper : mappers)
{
int score =
mapper.getCompatibilityScore(request);
list.add(new MapperWithScore(mapper, score));
}
The anonymouse, inner class instance is defined as:
static IRequestMapper MAPPER = new IRequestMapper()
{
@Override
public int getCompatibilityScore(Request request)
{
return matchedData(request) != null ?
Integer.MAX_VALUE : 0;
}
@Override
public Url mapHandler(IRequestHandler requestHandler)
{
return null;
}
@Override
public IRequestHandler mapRequest(Request request)
{
InterceptData data = matchedData(request);
if (data != null)
{
if (data.postParameters.isEmpty() ==
false &&
request.getPostParameters()
instanceof IWritableRequestParameters)
{
IWritableRequestParameters
parameters = (IWritableRequestParameters)request.getPostParameters();
parameters.reset();
for (String s :
data.postParameters.keySet())
{
parameters.setParameterValues(s, data.postParameters.get(s));
}
}
InterceptData.clear();
}
return null;
}
private InterceptData matchedData(Request request)
{
InterceptData data = InterceptData.get();
if (data != null &&
data.originalUrl.equals(request.getOriginalUrl()))
{
return data;
}
return null;
}
};
> This class needs to build a permanent session as you can see in its
method
>InterceptData.set:
I'm not sure why it's going to all this effort to respond to a request
for a static resource. I guess at this point it's trying to exhaust all
possibilities that the request is for a page before it assumes that it
is a resource.
The one thing I'm pretty sure of is that it is in no way necessary for
Wicket to establish a session to serve a static resource. Wicket 1.5 was
able to achieve this and I think Wicket 6 should be able to also.
>
>public static void set()
> {
> Session session = Session.get();
> session.bind();
>
>So the creation of a new session is not a question of static resources,
>but rather a consequence of RestartResponseAtInterceptPageException.
>But as I said I don't remember if 1.5 works differently.
>> A while ago when working with Wicket 1.5 we raised issue 4334 that
dealt
>> with the problem of jsessoin ID's being present in static resource
URLs
>> for the initial request and this issue was fixed.
>>
>> Not requiring jsession ID in the URL meant there was no reason to
ever
>> establish a session during requests for static resources i.e.
>> WebApplication#newSession was never called for static resource
requests.
>> This worked very well but we've just discovered that in Wicket 6,
even
>> though the URLs for static resources do not contain jsessionIDs there
is
>> some code that is calling getSession - unnecessarily we believe (we
hope
>> =] ).
>>
>> Is there any reason why WebApplicatoin#newSession is called when no
>> session is required to service the static request? If not it would be
>> great if that call could be avoided.
>>
>> Calling WebApplication#newSession on static resources becomes a
problem
>> when you employ OpenSessionInView/OpenPersistenceManagerInView by
using
>> a filter to wrap all Wicket requests within the context of an open
>> persistence session/manager. To optimize performance we use an
'ignore
>> list' that avoids wrapping the request if it is for a resource that
>> starts with a particular pattern (eg., /wicket/resource,/robots.txt)
>>
>> We override WebApplication#newSession and do some fancy things
whenever
>> a new session is established - this is intended for non static
resource
>> requests. Some of this code assumes that there is an
OpenSessionInView -
>> which fails in the case of static resources because their URLs are
part
>> of the ignore list and so the request was not wrapped within an open
>> persistence session/manager.
>>
>> I was hoping that Wicket 6 could be fixed to avoid the call to
>> newSession like Wicket 1.5 did after the resolution of 4334.
>>
>> Here's a stack trace of a call that is servicing a request for a
wicket
>> static resource:
>>
>> 2012/12/23 23:16:24.607 ERROR - DefaultExceptionMapper -
unexpected
>> exception when handling another exception: null
>> java.lang.NullPointerException
>> at
>>
com.sas.av.model.context.EServerContext.establishSiteVisitorForCrawler(E
>> ServerContext.java:3055)
>> at
>>
com.sas.av.model.context.EServerContext.initSession(EServerContext.java:
>> 3585)
>> at
>>
com.sas.av.ui.wicket.templates.WicketModelExposerApplication.newSession(
>> WicketModelExposerApplication.java:148)
>> at
>>
org.apache.wicket.Application.fetchCreateAndSetSession(Application.java:
>> 1557)
>> at org.apache.wicket.Session.get(Session.java:152)
>> at
>>
org.apache.wicket.RestartResponseAtInterceptPageException$InterceptData.
>> get(RestartResponseAtInterceptPageException.java:146)
>> at
>>
org.apache.wicket.RestartResponseAtInterceptPageException$1.matchedData(
>> RestartResponseAtInterceptPageException.java:211)
>> at
>>
org.apache.wicket.RestartResponseAtInterceptPageException$1.getCompatibi
>> lityScore(RestartResponseAtInterceptPageException.java:179)
>> at
>>
org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(Compou
>> ndRequestMapper.java:138)
>> at
>>
org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(Reque
>> stCycle.java:183)
>> at
>>
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle
>> .java:208)
>> at
>>
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(Req
>> uestCycle.java:282)
>> at
>>
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketF
>> ilter.java:244)
>> at
>>
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter
>> .java:188)
>> at
>>
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:
>> 267)
>> at
>>
com.sas.av.ui.wicket.templates.original.PagebloomFilter.doFilter(Pageblo
>> omFilter.java:96)
>> at
>>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>> tionFilterChain.java:235)
>> at
>>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>> erChain.java:206)
>> at
>>
com.sas.av.model.context.UrlRedirectorFilter.doFilter(UrlRedirectorFilte
>> r.java:93)
>> at
>>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>> tionFilterChain.java:235)
>> at
>>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>> erChain.java:206)
>> at
>>
com.sas.framework.expojo.servlet.ExpojoServletFilter.doFilter(ExpojoServ
>> letFilter.java:137)
>> at
>>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>> tionFilterChain.java:235)
>> at
>>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>> erChain.java:206)
>> at
>> com.sas.util.web.StaticResponseHeaderFilter.doFilter(Unknown Source)
>> at
>>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>> tionFilterChain.java:235)
>> at
>>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>> erChain.java:206)
>> at
>>
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
>> e.java:233)
>> at
>>
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
>> e.java:191)
>> at
>>
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
>> :128)
>> at
>>
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
>> :102)
>> at
>>
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568
>> )
>> at
>>
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
>> java:109)
>> at
>>
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
>> 86)
>> at
>>
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:84
>> 5)
>> at
>>
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
>> Http11Protocol.java:583)
>> at
>>
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>> at java.lang.Thread.run(Thread.java:662)
>>
>> Yours sincerely,
>>
>> Chris Colman
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Attempting to establish session for static resources in Wicket
6
Posted by Andrea Del Bene <an...@gmail.com>.
I don't remember quite well how it used to work with 1.5, but looking at
your stacktrace I see you used some kind of redirection policy that
involves class RestartResponseAtInterceptPageException. This class needs
to build a permanent session as you can see in its method InterceptData.set:
public static void set()
{
Session session = Session.get();
session.bind();
So the creation of a new session is not a question of static resources,
but rather a consequence of RestartResponseAtInterceptPageException.
But as I said I don't remember if 1.5 works differently.
> A while ago when working with Wicket 1.5 we raised issue 4334 that dealt
> with the problem of jsessoin ID's being present in static resource URLs
> for the initial request and this issue was fixed.
>
> Not requiring jsession ID in the URL meant there was no reason to ever
> establish a session during requests for static resources i.e.
> WebApplication#newSession was never called for static resource requests.
> This worked very well but we've just discovered that in Wicket 6, even
> though the URLs for static resources do not contain jsessionIDs there is
> some code that is calling getSession - unnecessarily we believe (we hope
> =] ).
>
> Is there any reason why WebApplicatoin#newSession is called when no
> session is required to service the static request? If not it would be
> great if that call could be avoided.
>
> Calling WebApplication#newSession on static resources becomes a problem
> when you employ OpenSessionInView/OpenPersistenceManagerInView by using
> a filter to wrap all Wicket requests within the context of an open
> persistence session/manager. To optimize performance we use an 'ignore
> list' that avoids wrapping the request if it is for a resource that
> starts with a particular pattern (eg., /wicket/resource,/robots.txt)
>
> We override WebApplication#newSession and do some fancy things whenever
> a new session is established - this is intended for non static resource
> requests. Some of this code assumes that there is an OpenSessionInView -
> which fails in the case of static resources because their URLs are part
> of the ignore list and so the request was not wrapped within an open
> persistence session/manager.
>
> I was hoping that Wicket 6 could be fixed to avoid the call to
> newSession like Wicket 1.5 did after the resolution of 4334.
>
> Here's a stack trace of a call that is servicing a request for a wicket
> static resource:
>
> 2012/12/23 23:16:24.607 ERROR - DefaultExceptionMapper - unexpected
> exception when handling another exception: null
> java.lang.NullPointerException
> at
> com.sas.av.model.context.EServerContext.establishSiteVisitorForCrawler(E
> ServerContext.java:3055)
> at
> com.sas.av.model.context.EServerContext.initSession(EServerContext.java:
> 3585)
> at
> com.sas.av.ui.wicket.templates.WicketModelExposerApplication.newSession(
> WicketModelExposerApplication.java:148)
> at
> org.apache.wicket.Application.fetchCreateAndSetSession(Application.java:
> 1557)
> at org.apache.wicket.Session.get(Session.java:152)
> at
> org.apache.wicket.RestartResponseAtInterceptPageException$InterceptData.
> get(RestartResponseAtInterceptPageException.java:146)
> at
> org.apache.wicket.RestartResponseAtInterceptPageException$1.matchedData(
> RestartResponseAtInterceptPageException.java:211)
> at
> org.apache.wicket.RestartResponseAtInterceptPageException$1.getCompatibi
> lityScore(RestartResponseAtInterceptPageException.java:179)
> at
> org.apache.wicket.request.mapper.CompoundRequestMapper.mapRequest(Compou
> ndRequestMapper.java:138)
> at
> org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(Reque
> stCycle.java:183)
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle
> .java:208)
> at
> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(Req
> uestCycle.java:282)
> at
> org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketF
> ilter.java:244)
> at
> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter
> .java:188)
> at
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:
> 267)
> at
> com.sas.av.ui.wicket.templates.original.PagebloomFilter.doFilter(Pageblo
> omFilter.java:96)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
> tionFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> erChain.java:206)
> at
> com.sas.av.model.context.UrlRedirectorFilter.doFilter(UrlRedirectorFilte
> r.java:93)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
> tionFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> erChain.java:206)
> at
> com.sas.framework.expojo.servlet.ExpojoServletFilter.doFilter(ExpojoServ
> letFilter.java:137)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
> tionFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> erChain.java:206)
> at
> com.sas.util.web.StaticResponseHeaderFilter.doFilter(Unknown Source)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
> tionFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
> erChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
> e.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
> e.java:191)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
> :128)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
> :102)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568
> )
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
> java:109)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
> 86)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:84
> 5)
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
> Http11Protocol.java:583)
> at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> at java.lang.Thread.run(Thread.java:662)
>
> Yours sincerely,
>
> Chris Colman
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org