[jira] [Commented] (GROOVY-12404) GroovyScriptEngine resource loader leaks URLConnections and ignores a custom ResourceConnector

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

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

ASF GitHub Bot commented on GROOVY-12404:
-----------------------------------------

daniellansun opened a new pull request, #2928:
URL: https://github.com/apache/groovy/pull/2928

   https://issues.apache.org/jira/browse/GROOVY-12404




> GroovyScriptEngine resource loader leaks URLConnections and ignores a custom ResourceConnector
> ----------------------------------------------------------------------------------------------
>
>                 Key: GROOVY-12404
>                 URL: https://issues.apache.org/jira/browse/GROOVY-12404
>             Project: Groovy
>          Issue Type: Bug
>            Reporter: Daniel Sun
>            Priority: Major
>
> {{groovy.util.GroovyScriptEngine}} resolves dependent sources through {{ResourceConnector.getResourceConnection}}, but several call sites keep only the URL and never close the {{URLConnection}}.
> {{URLConnection}} has no {{close()}} method. The engine already has {{forceClose}} for this (see GROOVY-7186) and uses it from {{loadScriptByName}}. The resource-loader path does not. {{ClassNodeResolver.findClassNode}} only closes the connection when the source is newer; the cache-hit path leaks. Long-running hosts that resolve many scripts can exhaust file descriptors.
> The same resource loader has two further gaps:
> # When the parent class loader is a {{GroovyClassLoader}}, {{ScriptClassLoader}} never calls {{setResLoader()}}. {{new GroovyScriptEngine(rc, new GroovyClassLoader())}} then ignores {{rc}} for {{loadClass}} / {{Class.forName}}.
> # Packaged names are mapped with {{File.separatorChar}}. On Windows the resource name uses a backslash as the separator instead of {{com/example/Foo.groovy}}, which is what {{ClassNodeResolver}} and {{GroovyClassLoader}} already use.
> h3. How to reproduce
> h4. Custom ResourceConnector ignored
> {code:java}
> File dir = File.createTempDir()
> new File(dir, 'Helper.groovy').text = 'class Helper { def ping() { "pong" } }'
> ResourceConnector rc = { String name ->
>     File f = new File(dir, name)
>     if (!f.exists()) throw new ResourceException('missing ' + name)
>     f.toURI().toURL().openConnection()
> }
> def engine = new GroovyScriptEngine(rc, new GroovyClassLoader())
> engine.groovyClassLoader.loadClass('Helper')
> {code}
> h4. Resource-loader connection not closed
> With {{Foo.groovy}} present, install a {{ResourceConnector}} whose {{URLConnection.getInputStream()}} records that it was called, then:
> {code:java}
> engine.groovyClassLoader.resourceLoader.loadGroovySource('Foo')
> {code}
> {{getInputStream()}} is never invoked, so {{forceClose}} did not run.
> h3. Expected result
> * Connections obtained only for their URL are closed with {{forceClose}}.
> * A custom {{ResourceConnector}} is used even when the parent is a {{GroovyClassLoader}}.
> * Resource names for packaged classes use a forward slash on every platform.
> h3. Actual result
> * The resource-loader {{URLConnection}} is left open.
> * {{loadClass('Helper')}} throws {{ClassNotFoundException}} even though {{Helper.groovy}} is visible to the connector.
> * On Windows, connectors that do not rewrite backslashes to slashes fail to find packaged scripts.
> h3. See also
> GROOVY-7186 addressed a similar leak in {{getResourceConnection}} and added {{forceClose}}. The resource-loader path and the cache-hit branch of {{findClassNode}} were not covered.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)