groovy

GroovyResourceLoader not used when loading Groovy class from .groovy source

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.0-JSR-3
  • Fix Version/s: 1.0-JSR-5
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    1

Description

It looks like GroovyResourceLoader is not used when attempting to load a .groovy class when parsing a .groovy source.

Consider the followowing .groovy sources:

<snip filename="/Test.groovy">
class Test
extends TestSupport
{
}
</snip>

<snip filename="/TestSupport.groovy">
class TestSupport
{
void test()

{ System.out.println("Testing") }

}
</snip>

Creating a new GCL, and attaching a GRL that prints the attempt to load the source URL, and then parsing /Test.groovy does not show the GRL being asked to load the "Test" class.

Instead an exception is thrown:

<snip>
Caused by: java.lang.ClassNotFoundException: Failed to parse groovy file: Test
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:679)
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:705)
at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
at org.codehaus.plexus.component.factory.groovy.GroovyComponentFactory.newInstance(GroovyComponentFactory.java:110)
... 51 more
Caused by: script1132538786147.groovy: 1: unable to resolve class TestSupport
@ line 1, column 1.
1 Error

at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:325)
at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:895)
at org.codehaus.groovy.control.CompilationUnit.semanticAnalysis(CompilationUnit.java:626)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:470)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:286)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:248)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:243)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:229)
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:674)
... 54 more
</snip>

The GRL does print the request to load /Test.groovy, but does not show the attempt to load /TestSupport.groovy.

If instead asking to just parse the /Test.groovy resource, the GRL does not show any output.

I also tried installing the GCL w/ the custom GRL as the TCL before parseClass() or loadClass() with the same results.

It appears that classes discovered in a .groovy source that are being attempted to be loaded do not go through the same GCL and thus do not get passed through the attached GRL for resource resolution.

I don't have any leads as to how to fix this, but I'd imagine that some GCL created during parsing the .groovy should probably delegate loading of the resource to its parent if its parent is a GCL... but I'm not sure.

W/o this working correctly to load sources... GRL is not very usable IMO.

I will dig somemore but if someone who knows this code better could take a look I would appreciate it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jason Dillon added a comment -

This seems to be caused by:

<snip filename="ResolveVisitor.java">
426: // NOTE: it's important to do no lookup against script files
427: // here since the GroovyClassLoader would create a new
428: // CompilationUnit
429: cls = loader.loadClass(name,false,true);
</snip>

Calling `loader.loadClass(name,true,true);` appears to resolve this problem... but I'm unsure about the fix due to the comment.

Show
Jason Dillon added a comment - This seems to be caused by: <snip filename="ResolveVisitor.java"> 426: // NOTE: it's important to do no lookup against script files 427: // here since the GroovyClassLoader would create a new 428: // CompilationUnit 429: cls = loader.loadClass(name,false,true); </snip> Calling `loader.loadClass(name,true,true);` appears to resolve this problem... but I'm unsure about the fix due to the comment.
Hide
Permalink
blackdrag blackdrag added a comment -

class A extends B

let us assume that A is parsed and B is a B.groovy file somehwere where the RessourceLoader is able to find it. If the Ressourceloader wouldn't be asked, then parsing for A fails because B can not be resolved. But then this would never work, and I confirm that it does work. So it has to be a special case I don't know. Look at ResolveVisitor#resolveToScript line 276:

url = gcl.getResourceLoader().loadGroovySource(name);

so ResourceLoader is asked for sure!

About the case you mentione in your secound comment:
As the comment says we don't want to lookup for scripts here! resolveToScript has to do this.

Show
blackdrag blackdrag added a comment - class A extends B let us assume that A is parsed and B is a B.groovy file somehwere where the RessourceLoader is able to find it. If the Ressourceloader wouldn't be asked, then parsing for A fails because B can not be resolved. But then this would never work, and I confirm that it does work. So it has to be a special case I don't know. Look at ResolveVisitor#resolveToScript line 276: url = gcl.getResourceLoader().loadGroovySource(name); so ResourceLoader is asked for sure! About the case you mentione in your secound comment: As the comment says we don't want to lookup for scripts here! resolveToScript has to do this.
Hide
Permalink
Jason Dillon added a comment -

I will check again, and create a better testcase. I am running in to the problem of A extends B, A is parsed and B.groovy exists somewhere that GRL can find it... and parseClass() fails because it can not locate the "B" class.

This is the same scenario you describe above, but for me it gives me no love.

Show
Jason Dillon added a comment - I will check again, and create a better testcase. I am running in to the problem of A extends B, A is parsed and B.groovy exists somewhere that GRL can find it... and parseClass() fails because it can not locate the "B" class. This is the same scenario you describe above, but for me it gives me no love.
Hide
Permalink
Jason Dillon added a comment -

NOTE: The description I put is wrong... and I can't edit the issue so I'm amending it here.

Currently reads:

Creating a new GCL, and attaching a GRL that prints the attempt to load the source URL, and then parsing /Test.groovy does not show the GRL being asked to load the "Test" class.

Should read:

Creating a new GCL, and attaching a GRL that prints the attempt to load the source URL, and then parsing /Test.groovy does not show the GRL being asked to load the "TestSupport" class.

  • * *

You may want to consider allowing the issue reporter perms to edit the issue they created.

Show
Jason Dillon added a comment - NOTE: The description I put is wrong... and I can't edit the issue so I'm amending it here. Currently reads: Creating a new GCL, and attaching a GRL that prints the attempt to load the source URL, and then parsing /Test.groovy does not show the GRL being asked to load the "Test" class. Should read: Creating a new GCL, and attaching a GRL that prints the attempt to load the source URL, and then parsing /Test.groovy does not show the GRL being asked to load the "TestSupport" class. * * You may want to consider allowing the issue reporter perms to edit the issue they created.
Hide
Permalink
Jason Dillon added a comment -

Attached is a Maven1 project, that illustrates the problem that I am seeing with GCL+GRL.

Unpack, `cd groovy-1149 && maven test` to run the tests. This project has A.groovy and B.groovy as detailed above, and attempts to parseClass(), and loadClass() for "A" and "B" using a GRL to load the resource.

Attempts to parse/load B pass, attempts to parse/load A fail.

This is using the latest Groovy 1.0-jsr-04-SNAPSHOT as of about 20 minutes ago.

Show
Jason Dillon added a comment - Attached is a Maven1 project, that illustrates the problem that I am seeing with GCL+GRL. Unpack, `cd groovy-1149 && maven test` to run the tests. This project has A.groovy and B.groovy as detailed above, and attempts to parseClass(), and loadClass() for "A" and "B" using a GRL to load the resource. Attempts to parse/load B pass, attempts to parse/load A fail. This is using the latest Groovy 1.0-jsr-04-SNAPSHOT as of about 20 minutes ago.
Hide
Permalink
Jason Dillon added a comment -

I should also not that this problem is with pre 1.0-JSR-4, as GRL does not exist in 1.0-JSR-3

Show
Jason Dillon added a comment - I should also not that this problem is with pre 1.0-JSR-4, as GRL does not exist in 1.0-JSR-3
Hide
Permalink
blackdrag blackdrag added a comment -

it seems the problem was that if there is no class of that name was found, then the cache got the entry NO_CLASS. This caused resolveToScript to skip the lookup for a script. The result is that the script is not parsed. That's fixed now

Show
blackdrag blackdrag added a comment - it seems the problem was that if there is no class of that name was found, then the cache got the entry NO_CLASS. This caused resolveToScript to skip the lookup for a script. The result is that the script is not parsed. That's fixed now
Hide
Permalink
Jason Dillon added a comment -

Awesome!

Show
Jason Dillon added a comment - Awesome!
Hide
Permalink
blackdrag blackdrag added a comment -

btw, it's better to use GCL#parseClass(InputStream,String) if you wish a to see the correct name in the stack trace

Show
blackdrag blackdrag added a comment - btw, it's better to use GCL#parseClass(InputStream,String) if you wish a to see the correct name in the stack trace

People

  • Assignee:
    Unassigned
    Reporter:
    Jason Dillon
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: