[ 
https://issues.apache.org/jira/browse/WICKET-6809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17169941#comment-17169941
 ] 

Emond Papegaaij commented on WICKET-6809:
-----------------------------------------

[~bht] I understand that issues like these can be frustrating, but in this 
case, Wicket uses an API provided by the jdk in the way it is supposed to be 
used for the propose it is meant for. Do you have a solution for this problem? 
The old behavior was a custom service loader, which we really will not go back 
to. If you can provide us with a PR that fixes this issue, without breaking 
behavior on newer platforms, we will certainly take a look.

Have you consider contacting Oracle for a fix in jdk 8 or Glassfish? The bug is 
in their code, they can fix it.

> 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)

Reply via email to