>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-unsubscr...@wicket.apache.org
>For additional commands, e-mail: users-h...@wicket.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to