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

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

[~bht] you keep on making assumptions which are not true. We, for example, use 
WildFly to run our applications. We do however not redeploy applications in a 
running server, because of the problems you mentioned. IMHO redeploying 
applications in a running server is a failed concept due to the various leaks. 
You can find references about this all over the internet caused by many 
different frameworks. If Glassfish is holding you back from upgrading to a more 
recent and still supported Java version, have you considered migrating to 
Paraya?

> 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