You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Martin Grigorov (JIRA)" <ji...@apache.org> on 2018/05/26 12:53:00 UTC

[jira] [Updated] (WICKET-6519) Internal destroy tries to load classes after WAR is removed.

     [ https://issues.apache.org/jira/browse/WICKET-6519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Grigorov updated WICKET-6519:
------------------------------------
    Priority: Minor  (was: Major)

> Internal destroy tries to load classes after WAR is removed.
> ------------------------------------------------------------
>
>                 Key: WICKET-6519
>                 URL: https://issues.apache.org/jira/browse/WICKET-6519
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 7.9.0
>         Environment: Tomcat 9.0.2, Ubuntu 16.04, Java 1.8
>            Reporter: Richard O'Sullivan
>            Priority: Minor
>              Labels: destroy, leak, undeploy
>
> When undeploying a Wicket web application from Tomcat by _removing the war file_ from the deploy sub-directory (in other words, a hot undeploy), a FileNotFoundException prevents Wicket from shutting down properly.
> The exception is caused when Wicket's internalDestroy() method needs classes that have _not yet been loaded_ and the class loader attempts to load them from the (now) undeployed war file.
> A work around is to preload the classes that Wicket will need during the destroy phase. I was able to resolve the issue using these class loader statements in the init() method of my Wicket WebApplication implementation:
> {code:java}
> getClass().getClassLoader().loadClass("org.apache.wicket.ApplicationListenerCollection$2");
> getClass().getClassLoader().loadClass("org.apache.wicket.core.util.lang.PropertyResolver");
> getClass().getClassLoader().loadClass("org.apache.wicket.core.util.lang.PropertyResolver$IPropertyLocator");
> {code}
> The internalDestroy() method is called from org.apache.wicket.protocol.http.WicketFilter.destroy() in a 'try...finally' block that does not log the Exception. Wicket discourages overwriting this method but doing so allows the stack trace to be logged, as follows:
> {code:java}
> @Override
> public void internalDestroy()
> {
>     log.info("internalDestroy: ENTER");
>     try
>     {
>         super.internalDestroy();
>     }
>     catch ( Exception ex )
>     {
>         ex.printStackTrace();
>         throw ex;
>     }
>     log.info("internalDestroy: EXIT");
> }
> {code}
> Note: For additional troubleshooting, Tomcat provides a 'find leaks' feature on its 'Application Manager' page that reports issues when Wicket fails to undeploy properly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)