Jochen Theodorou commented on GROOVY-8348:
Ok, let me try to explain this in a bit more detail. With GroovyClassloader#loadClass(String name, boolean lookupScriptFiles, boolean preferClassOverScript, boolean resolve), you have a way to load scripts from the resource paths (lookupScriptFiles=true and preferClassOverScript=true). In this mode you can let the GroovyClassLoder look for a .groovy file, which is then compiled and loaded, if the classloader classpath does not contain the class. Normally Java uses loadClass(String,bolean), which is delegating to the mentioned longer version in case of GroovyClassloader. but the important point here is that this is done with lookupScriptFiles=true. So it can lookup script files and compile them at runtime on request.
The Groovy compiler now requires under certain circumstances to compile a set of source files and lookup further files as well as doing some ordinary reflection based classloading. the compiler always uses a GroovyClassloader for this, but always with lookupScriptFiles=false to avoid a compilation spawning further compilations that then may in turn spawn more and so on. Let us call this GroovyClassloader the compilation classloader.
Now, what if the compilation classloader has another GroovyClassloader as parent? Then it can happen, that during the search for a class this parent tries to load a script file and spawns a new compilation. If this compilation fails, then you get the message above, that the compiler is irritated, that somebody else tried to compile something, even though he should be the only one right now. let us call this parent class loader the environment loader
For the case here it means InitContentMissive.groovy was not given to the compiler to compile it as part of the groovy compilation you started for another class. Instead we end up in the environment loader, which does not know about a class of that name (also not the parents of that loader), but find a resource, that fits InitContentMissive.groovy and then tries to compile it. That leads to two simple solutions:
(1) make InitContentMissive part of the compilation
(2) do not put InitContentMissive on the class pather or somewhere else, where the environment loader can find it.
I have to mention, that in option 2 you would currently most likely end up in a compilation failure, because no InitContentMassive class can be found then anymore. So imho 2 requires 1.
The Groovy compiler from our distribution does not use that kind of setup afaik. Thus it is most likely how SOAP UI is doing the setup. And SOAP UI is beyond our control. Since I never used it, I can also not support you here.
> BUG! exception in phase 'semantic analysis' in source unit
> Key: GROOVY-8348
> URL: https://issues.apache.org/jira/browse/GROOVY-8348 > Project: Groovy
> Issue Type: Bug
> Components: GroovyScriptEngine
> Affects Versions: 2.4.12
> Environment: SOAP-UI
> Reporter: Greg
> I have a probleme executing an existing SOAPUI project containing groovy scripts.
> Here is the executed script
> import initialize.others.*
> def initializeur=new InitContentMissive(testRunner,log,context)
> And the not explicit error message i got:
> BUG! exception in phase 'semantic analysis' in source unit 'Script4.groovy' The lookup for initialize.others.InitContentMissive caused a failed compilaton. There should not have been any compilation from this call.
> I have absolutely no idea where does it come from. Tried to browse other "semantic analysis" issues here but found no solution.
> Updated groovy-all-2.4.12.jar in ..\SoapUI-5.3.0\lib, updated java to last version.
> Thanks for your help
This message was sent by Atlassian JIRA