Watter wrote:
>
>
> Jean-Baptiste Quenot-3 wrote:
>>
>> That's very interesting. It may be caused by some page
>> deserialization not using the right classloader, when Wicket pulls
>> pages out of the second-level cache. May be worth trying with
>> org.apache.wicket.util.lang.Objects.setObjectStreamFactory(new
>> WicketObjectStreamFactory())
>>
> When I do this, I get "Page Expired" errors after using my back button and
> then clicking a link. This happens regardless of what I'm doing with
> reloading (i.e. disabled or enabled). When I switch to the default JDK
> serialization or just don't specify anything for serialization, things
> work as expected with reloading disabled but I get the same
> ClassCastException as before with reloading enabled.
>
> Does the fact that I'm seeing Page Expired errors with
> WicketObjectStreamFactory indicate that I have another issue that's
> unrelated to the reloading filter that I need to fix?
>
Ok, after a week of trying to develop without use of the
ReloadingWicketFilter I'm pulling my hair out. Once you've experienced the
beauty that is easy hot reloading of the classes and HTML files, it's
impossible to go back. So here I am trying again to solve this issue. I've
noticed a few things that may or may not be helpful.
1) I realized that "ContextLoader" which is the reported as the classloader
when I do a Session.class.getClassloader() right before the error occurs is
actually a Spring class. For some reason I was thinking that it was a
standard Java class loader. I am using Spring in my application, but from
the web tier, I only access my Spring beans using the approved @SpringBean
annotation. Does that fact that this is a Spring class tell me anything
useful?
2) I tried the
"org.apache.wicket.util.lang.Objects.setObjectStreamFactory(new
WicketObjectStreamFactory())" suggestion again and this time I had different
results. It all worked fine until the same point where I had previously
gotten the ClassCastErrors on my Session object. With this
WicketObjectStreamFactory() change I instead get the following exception at
that same point:
java.lang.NullPointerException
at
org.apache.wicket.util.io.ClassStreamHandler.createObject(ClassStreamHandler.java:304)
at
org.apache.wicket.util.io.WicketObjectInputStream.readObjectOverride(WicketObjectInputStream.java:93)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
at
org.apache.wicket.util.io.ClassStreamHandler$ObjectFieldAndIndex.readField(ClassStreamHandler.java:872)
at
org.apache.wicket.util.io.ClassStreamHandler.readFields(ClassStreamHandler.java:417)
at
org.apache.wicket.util.io.WicketObjectInputStream.defaultReadObject(WicketObjectInputStream.java:164)
at
org.apache.wicket.protocol.http.FilePageStore$PageSerializer.deserializePage(FilePageStore.java:874)
at org.apache.wicket.Page.readObject(Page.java:1260)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.wicket.util.io.ClassStreamHandler.invokeReadMethod(ClassStreamHandler.java:492)
at
org.apache.wicket.util.io.WicketObjectInputStream.readObjectOverride(WicketObjectInputStream.java:96)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342)
at
org.apache.wicket.util.lang.Objects.byteArrayToObject(Objects.java:396)
at
org.apache.wicket.protocol.http.FilePageStore.readPage(FilePageStore.java:541)
at
org.apache.wicket.protocol.http.FilePageStore.getPage(FilePageStore.java:455)
at
org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.get(SecondLevelCacheSessionStore.java:192)
at org.apache.wicket.Session.getPage(Session.java:725)
at
org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:427)
at
org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1090)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1176)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:499)
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:257)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:127)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:198)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
at
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:751)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
3) This all used to work. I know, I know. That's not exactly helpful.
Jean-Baptiste Quenot said in WICKET-685:
"And about Wicket making your usecase fail suddenly is because the internal
handling of classes has slightly changed recently, but what you encounter is
just a side effect of the misconfigured include/exclude patterns in the
first place. "
Ok, so a change was made and I'm not suggesting in any way that it was a bad
change, but since my setup used to work and it now doesn't perhaps if I knew
a little more about that change I might be able to better diagnose what's
wrong with my configuration.
------------------
Any general suggestions or debugging advice would be appreciated. Is there
some way for me to use my debugger to trace back to where the class was
loaded when I'm stepping through a class that was loaded by
ReloadingClassLoader but is now being loaded by ContextLoader?
Thanks!
Matt
--
View this message in context:
http://www.nabble.com/Has-something-changed-in-markup-inheritance--tf3963374.html#a11532314
Sent from the Wicket - User mailing list archive at Nabble.com.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
