[
https://issues.apache.org/jira/browse/WICKET-6519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16491645#comment-16491645
]
Martin Grigorov commented on WICKET-6519:
-----------------------------------------
I've changed the priority to "Minor" because this issue could happen only for
unused application, i.e. it is started and then immediately undeployed. If a
page is loaded at least once then those classes will be loaded and there won't
be such issue.
In addition
{code}
getClass().getClassLoader().loadClass("org.apache.wicket.ApplicationListenerCollection$2");
{code}
should not be needed in Wicket 8 because the anonymous classes are replaced
with lambdas there.
> 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)
