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)