Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
latest CVS head, mac 10.3.2, java 1.4.2
Description
I admit this one is really obscure and it took me a long time to find, but it has screwed up my application.
I would like to evaluate files that contain groovy code. I use GroovyShell.evaluate(File) to do this.
Normally this works, but I don't do things normal 
In my application, I have these groovy files scattered about the file system. The files contain one line that look like this:
new Snap(x:1, y:2, z:3)
The properties don't really matter, but each file has different values for the properties.
Here is the kicker: all these files have the same name: "snap.tor". They live in different locations of the directory heirarchy, so there is no conflict.
When I evaluate the first file, all is well. The object returned from the evaluate() call has the right properties. When I evaluate any subsequent ones, the new objects have the same properties as the first, even if the file has them as different.
After lots of tests and experiments and poking in the code, I discovered that the evaluate(File) makes use of the groovy class loader, so if we just loaded the file /a/b/snap.tor, it'll ignore any attempts to load the file snap.tor from anywhere else in the heirarchy after that. But these aren't classes. They are just files with groovy code in them! They shouldn't be "cached" like this.
So, in short, the bug seems to be that evaluate() uses the classloader when in fact evaluate() is not loading in classes, but rather plain old groovy code. I think groovy needs to keep these two ideas distinct. We have the java-like class loading which does a lot of magic, and we have the scripty-like file sourcing that should not assume it is loading in class definitions.
So, please make evaluate not make use of the classloader. Just suck the text in and parse that. (My work around is in fact to use evaluate(String) instead of evaluate(File)).
Thanks for listening!