[
https://issues.apache.org/jira/browse/WICKET-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998428#comment-12998428
]
Mark Thomas commented on WICKET-3470:
-------------------------------------
Re-reading this, I see the Tomcat bug referred to a Servlet whereas Wicket is
actually using a Filter. That does change things since the the Servlet
specification is less clear on the Filter lifecycle. However, having re-read
the section SRV.6 of both the Servlet 2.5 and Servlet 3.0 specifications it
appears that containers have a fair amount of leeway in how they initialise and
destroy filters. For example, from reading the spec it appears to be
specification compliant (although performance would be truly awful) to create
and destroy filters per request.
Since the specification offers no guidance on the correct ordering then I am
not inclined to change the order for the benefit of a single application. There
may well be other applications that depend on the current ordering. Regardless
of what applications exist or don't exist that depend on a particular order, if
the specification does not define an order then an application should not
depend on an order.
I think Wicket would be better off using a ServletContextListener. From section
11.3.4 of the Servlet 3.0. spec "On application shutdown, listeners are
notified in reverse order to their declarations with notifications to session
listeners preceding notifications to context listeners. Session listeners must
be notified of session invalidations prior to context listeners being notified
of application shutdown.". That should ensure the ordering that Wicket requires.
> Can't write session to disk with tomcat : Servlet is destroyed before
> serialization
> -----------------------------------------------------------------------------------
>
> Key: WICKET-3470
> URL: https://issues.apache.org/jira/browse/WICKET-3470
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5-RC1
> Environment: Windows 7 x64
> apache-tomcat-6.0.32-windows-x86
> (Running from Eclipse view, Faceted project)
> Reporter: SegFault
> Labels: persistent, session, storage, tomcat
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> Hi,
> When I stop my tomcat, I have the following error :
> GRAVE: Exception au déchargement des sessions vers le stockage persistant
> (persistent storage)
> java.lang.IllegalStateException: PageManager for application wicket not
> registered.
> at
> lm.lbx.application.PersistentPageManager$SessionEntry.getPageStore(PersistentPageManager.java:86)
> at
> lm.lbx.application.PersistentPageManager$SessionEntry.writeObject(PersistentPageManager.java:197)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> at java.io.ObjectOutputStream.writeObject(Unknown Source)
> at
> org.apache.catalina.session.StandardSession.writeObject(StandardSession.java:1561)
> at
> org.apache.catalina.session.StandardSession.writeObjectData(StandardSession.java:1004)
> at
> org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:528)
> at
> org.apache.catalina.session.StandardManager.unload(StandardManager.java:469)
> at
> org.apache.catalina.session.StandardManager.stop(StandardManager.java:678)
> at
> org.apache.catalina.core.StandardContext.stop(StandardContext.java:4875)
> at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1106)
> at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1106)
> at org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:468)
> at
> org.apache.catalina.core.StandardService.stop(StandardService.java:604)
> at org.apache.catalina.core.StandardServer.stop(StandardServer.java:788)
> at org.apache.catalina.startup.Catalina.stop(Catalina.java:662)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:629)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
> After a little digging, it's because tomcat first unload the servlet mapping
> and destroy the servlet, and then, ask for serialization. I'm not sure it's a
> wiket bug, tell me if i have to report it against tomcat.
> Here is the trace of the destroy :
> Thread [main] (Suspended (breakpoint at line 357 in PersistentPageManager))
> PersistentPageManager.destroy() line: 357
> PageAccessSynchronizer$1(PageManagerDecorator).destroy() line: 86
> LibellexApplication(Application).internalDestroy() line: 658
> LibellexApplication(WebApplication).internalDestroy() line: 470
> WicketFilter.destroy() line: 456
> ApplicationFilterConfig.release() line: 357
> StandardContext.filterStop() line: 4106
> StandardContext.stop() line: 4869
> StandardHost(ContainerBase).stop() line: 1106
> StandardEngine(ContainerBase).stop() line: 1106
> StandardEngine.stop() line: 468
> StandardService.stop() line: 604
> StandardServer.stop() line: 788
> Catalina.stop() line: 662
> Catalina.start() line: 629
> NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
> available [native method]
> NativeMethodAccessorImpl.invoke(Object, Object[]) line: not available
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: not
> available
> Method.invoke(Object, Object...) line: not available
> Bootstrap.start() line: 289
> Bootstrap.main(String[]) line: 414
> And the trace requesting serialization :
> Thread [main] (Suspended (breakpoint at line 83 in
> PersistentPageManager$SessionEntry))
> PersistentPageManager$SessionEntry.getPageStore() line: 83
> PersistentPageManager$SessionEntry.writeObject(ObjectOutputStream)
> line: 197
> NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
> available [native method]
> NativeMethodAccessorImpl.invoke(Object, Object[]) line: not available
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: not
> available
> Method.invoke(Object, Object...) line: not available
> ObjectStreamClass.invokeWriteObject(Object, ObjectOutputStream) line:
> not available
> ObjectOutputStream.writeSerialData(Object, ObjectStreamClass) line: not
> available
> ObjectOutputStream.writeOrdinaryObject(Object, ObjectStreamClass,
> boolean) line: not available
> ObjectOutputStream.writeObject0(Object, boolean) line: not available
> ObjectOutputStream.writeObject(Object) line: not available
> StandardSession.writeObject(ObjectOutputStream) line: 1561
> StandardSession.writeObjectData(ObjectOutputStream) line: 1004
> StandardManager.doUnload() line: 528
> StandardManager.unload() line: 469
> StandardManager.stop() line: 678
> StandardContext.stop() line: 4875
> StandardHost(ContainerBase).stop() line: 1106
> StandardEngine(ContainerBase).stop() line: 1106
> StandardEngine.stop() line: 468
> StandardService.stop() line: 604
> StandardServer.stop() line: 788
> Catalina.stop() line: 662
> Catalina.start() line: 629
> NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
> available [native method]
> NativeMethodAccessorImpl.invoke(Object, Object[]) line: not available
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: not
> available
> Method.invoke(Object, Object...) line: not available
> Bootstrap.start() line: 289
> Bootstrap.main(String[]) line: 414
> Well at this time, a simple dirty hack is to bypass destroy chain to avoid
> removal of app from managers properties of class PersistentPageManager. But I
> would like to have a real clean solution.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
