GroovyScriptEngine does not let you specify parent ClassLoader for GroovyClassLoader

Here's a patch that should fix the problem.

I think it is probably a bad idea to allow the parent classloader to be changed at runtime as per Azubuko's path which has getter and setter for the parent classloader - surely this introducing threading issues whereas the rest of this class is threadsafe.

I suggest addition of an overloaded run method that takes a ClassLoader parameter, so that you can still do per-execution classloader control without introducing new threading issues.

I will post a fix along with another related issue.

Marc, I don't think the threading issues are that bad. There is the possibility that one thread might modify the parent classloader right when another thread is about to execute a script but that can be fixed by tossing in a few synchronized blocks to ensure nobody messes with the parent classloader while the run() method is being evaluated. Also, adding an overloaded run() method would be bad from an api-design pov. The purpose of the class, I think, is to provide a 'script execution context'. To run a script users shouldn't have to provide much more than a script name and the bindings. If the concern is that great, let's overload the constructor and keep the run methods simple.

On another note I don't think this class should even be threadsafe. I can't imagine why you would possibly want a threadsafe scripting engine. In a multithreaded scenario, where you have many threads each evaluating their own script, you're going to give each one its own scripting engine in the first place. Or maybe I'm missing something and only considering the client-server model...

I don't care much how its done, but the code I submitted for GROOVY-1187 has overloaded methods. Your argument that all you should have to supply is scriptname / binding is true - but if you don't need to supply a classloader you call the overloaded method that doesn't need it.

Having a threadsafe GroovyScriptEngine is important because you can (and should) use one script engine instance in your application, and if multiple threads execute the same scripts (such as you might in an application server) you will benefit from the cached Groovy class definitions. Otherwise you waste memory and CPU re-parsing groovy scripts for each thread.

Now able to set the parent classloader through constructors or even through a setter.