You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "Gary Clayburg (JIRA)" <ji...@apache.org> on 2018/09/21 19:30:00 UTC

[jira] [Created] (GROOVY-8805) GroovyScriptEngine reload fails when dependent class is deleted

Gary Clayburg created GROOVY-8805:
-------------------------------------

             Summary: GroovyScriptEngine reload fails when dependent class is deleted
                 Key: GROOVY-8805
                 URL: https://issues.apache.org/jira/browse/GROOVY-8805
             Project: Groovy
          Issue Type: Bug
          Components: GroovyScriptEngine
    Affects Versions: 2.5.2, 2.4.15
            Reporter: Gary Clayburg


When using GroovyScriptEngine.loadScriptByName(scriptName), the reloading will fail with a groovy.util.ResourceException if a dependent class has been removed from the script root filesystem.  To reproduce this issue, start with a script and a dependent class:

ClassA.groovy
{code:java}
DependentClass ic = new DependentClass(){code}
 

 DependentClass.groovy

 
{code:java}
 class DependentClass {}
 
{code}
 

When these classes are initially compiled with GroovyScriptEngine, things work fine.  There are no errors when loading the script like this:

 
{code:java}
gse.loadScriptByName('ClassA.groovy'){code}
 

However, once DependentClass.groovy is completely removed from the filesystem and ClassA is modified to remove the reference, the same gse.loadScriptByName('ClassA.groovy') will fail with a groovy.utilResourceExeption. 

 

It appears GroovyScriptEngine keeps a dependency cache and gets confused in this case.  The line that fails is a check for lastModifedTime of this dependency.  The dependency of course no longer exists, but the check for lastModiedTime occurs before ClassA compile has been attempted.

 

I am working on a PR that fixes this.  It seems to me that inside gse.isSourceNewer(entry), it can just treat a ResourceException during getLastModifed(scriptName) as an indication to just attempt a recompile instead of throwing the exception.

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)