John Engelman created GROOVY-10519:
--------------------------------------
Summary: v9 ClassFinder closes existing FileSystems that it
doesn't own
Key: GROOVY-10519
URL: https://issues.apache.org/jira/browse/GROOVY-10519
Project: Groovy
Issue Type: Bug
Components: groovy-runtime
Affects Versions: 4.0.1, 3.0.10
Reporter: John Engelman
{noformat}
org.codehaus.groovy.vmplugin.v9.ClassFinder
private static FileSystem newFileSystem(URI uri) throws IOException {
try {
return FileSystems.newFileSystem(uri, Collections.emptyMap());
} catch (FileSystemAlreadyExistsException e) {
return FileSystems.getFileSystem(uri);
}
}
private static Map<String, Set<String>> find(URI uri, String prefix, String
packageName, boolean recursive) {
boolean wfs = "file".equals(uri.getScheme());
if (wfs) prefix = prefix.replace("/", File.separator);
final String sepPatten = Pattern.quote(wfs ? File.separator : "/");
final int prefixElemCnt = prefix.trim().isEmpty() ? 0 :
prefix.split(sepPatten).length;
Map<String, Set<String>> result = new LinkedHashMap<>();
try (FileSystem fs = newFileSystem(uri)) {
//...
}
//...
}{noformat}
The current implementation of {{ClassFinder}} will close a {{FileSystem}} that
was opened prior to loading Groovy classes. Specifically, if an application
opens a {{FileSystem}} for a JAR on the classpath that contains Groovy classes
and then subsequently loads a Groovy class contained within, then the
underlying {{ZipFileSystem}} is closed by {{ClassFinder}} and the original
application receives a {{java.nio.file.ClosedFileSystemException}} on
subsequent operations.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
