[
https://issues.jboss.org/browse/WFCORE-3103?page=com.atlassian.jira.plugi...
]
Brian Stansberry reassigned WFCORE-3103:
----------------------------------------
Assignee: Ken Wills (was: Brian Stansberry)
[~luck3y] I'm going to pass this one over to you.
https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO... has my
experiment on that, but the testsuite does not pass. To get meaningful behavior with it
you have to run with David's jboss-modules branch with the MODULES-301 commit in it.
For sure
https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO...
or something like it has to happen, otherwise we close the boot module loader which is
wrongness. But when I make that change things blow up.
Embedded server doesn't close open file handles
-----------------------------------------------
Key: WFCORE-3103
URL:
https://issues.jboss.org/browse/WFCORE-3103
Project: WildFly Core
Issue Type: Bug
Components: CLI, Modules
Reporter: Jan Blizňák
Assignee: Ken Wills
When embedded server is started programatically (eg. via CLI wrapper) with specified
jboss home, JARs from that path are opened via classloader. But these open handles are
never released even after embedded server is stopped.
This causes problem in situation eg. when you want to delete that jboss home. This is
exactly one of the scenarios used in EAP installer, you are not allowed to delete open
files on Windows - see JBEAP-1404.
I created a simple project that reproduce the issue with arbitrary EAP/WF distribution
https://github.com/jbliznak/embedded-server-filelocking
Run it with:
mvn clean test "-Dwildfly.home=C:\dev\jboss-eap-7.1"
"-Denforcer.skip" -Dtest=ModulesFileLockingTestCase
Manual steps to reproduce in Java code:
* start a CLI wrapper
* start embed-server from given server path
* stop embed-server
* terminate CLI wrapper
* try to delete given server path
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)