[
https://issues.apache.org/jira/browse/WICKET-6809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17171255#comment-17171255
]
Bernard commented on WICKET-6809:
---------------------------------
Wicket 7 introduced a bug discovered by WebSphere Liberty that was resolved by
using a buggy ServiceLoader API which now breaks something in ALL application
servers. That file leak does not actually have a bad impact because
re-deployment is possible - only a clean build fails because the jar cannot be
deleted.
I would think that only a minority of developers use Java EE servers. And it is
a fact that only a minority of the large number of developers still using
Tomcat even know know what classloader leaks are.
We have a survey of a population of these developers who mostly don't use Java
EE servers, and who mostly don't know what classloader leaks are. No surprise
there to find that they prefer to develop on Jetty if they do not even know the
benefits of re-deployment into a running container. I have seen a multi-million
dollar project switch to Jetty because the developers thought that the Eclipse
Tomcat server plugin was broken where in fact it was a classloader leak caused
by a library maintained by a one man band - lambdaj - stuffing a ThreadLocal
into a framework class variable. See
https://java.jiderhamn.se/category/classloader-leaks/
And it is no surprise either knowing the sad fact that outdated Tomcat, still
the most popular servlet container (talking about legacy), does not even
support re-deployment in their admin console (see bug
https://bz.apache.org/bugzilla/show_bug.cgi?id=58935).
How can we conclude that "redeploying applications in a running server is a
failed concept due to the various leaks" ? Based on the use of outdated
software? Based on the opinion of lightweight developers?
I can tell you, that based on Wicket and GlassFish, if I run into a problem of
a bad component hierarchy which is what some novice Wicket developers seem to
hate, I just relax and fix these problems one by one following my nose reading
the error messages between sub-second re-deployments. Failed concept? No way.
Things look fairly ok in Wicket and Java EE land.
> wicket-core-8.9.0.jar not closed when Application is undeployed from an
> application server
> ------------------------------------------------------------------------------------------
>
> Key: WICKET-6809
> URL: https://issues.apache.org/jira/browse/WICKET-6809
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
> Affects Versions: 8.9.0
> Environment: Windows 7
> java version "1.8.0_201"
> Reporter: Bernard
> Assignee: Sven Meier
> Priority: Critical
> Attachments: Testcase.zip
>
>
> How to reproduce:
> - Use the attached quickstart
> - deploy it on the GlassFish server with directory deployment (I use
> NetBeans which is easy) but Windows command files are provided
> - open the application in the browser
> - undeploy the application
> - try to execute the maven clean goal or try to delete the target dir
> Maven error: Failed to delete ... WEB-INF\lib\wicket-core-8.9.0.jar
> Please inspect for WICKET-4458 for how to use the ZipFileMonitor tool which
> is included in the attached quickstart. The output of the show command is as
> follows:
> ..Opened by hashCode object 3192 from:
> java.util.jar.JarFile.<init>(java\util\jar\JarFile.java:168)
> java.util.jar.JarFile.<init>(java\util\jar\JarFile.java:103)
>
> sun.net.www.protocol.jar.URLJarFile.<init>(sun\net\www\protocol\jar\URLJarFile.java:93)
>
> sun.net.www.protocol.jar.URLJarFile.getJarFile(sun\net\www\protocol\jar\URLJarFile.java:69)
>
> sun.net.www.protocol.jar.JarFileFactory.get(sun\net\www\protocol\jar\JarFileFactory.java:94)
>
> sun.net.www.protocol.jar.JarURLConnection.connect(sun\net\www\protocol\jar\JarURLConnection.java:122)
>
> sun.net.www.protocol.jar.JarURLConnection.getInputStream(sun\net\www\protocol\jar\JarURLConnection.java:152)
> java.net.URL.openStream(java\net\URL.java:1045)
> java.util.ServiceLoader.parse(java\util\ServiceLoader.java:304)
> java.util.ServiceLoader.access$200(java\util\ServiceLoader.java:185)
>
> java.util.ServiceLoader$LazyIterator.hasNextService(java\util\ServiceLoader.java:357)
>
> java.util.ServiceLoader$LazyIterator.hasNext(java\util\ServiceLoader.java:393)
> java.util.ServiceLoader$1.hasNext(java\util\ServiceLoader.java:474)
>
> org.apache.wicket.Application.initInitializers(org\apache\wicket\Application.java:568)
>
> org.apache.wicket.Application.initApplication(org\apache\wicket\Application.java:782)
>
> org.apache.wicket.protocol.http.WicketFilter.init(org\apache\wicket\protocol\http\WicketFilter.java:444)
>
> org.apache.wicket.protocol.http.WicketFilter.init(org\apache\wicket\protocol\http\WicketFilter.java:368)
>
> org.apache.catalina.core.ApplicationFilterConfig.getFilter(org\apache\catalina\core\ApplicationFilterConfig.java:226)
> This indicates that we may have a similar problem or a regression. It should
> be somewhat easier now to fix.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
