Classloaders and ScriptBuilder

[Greg Ludington <gl...@gmail.com>]

Is there a means to have camel's script builder look at other classloaders
besides the one in which ScriptBuilder was loaded?  We have a scenario with
a core camel container, into which people deploy their own applications in
private classloaders.  (As part of the tooling, camel-script is part of
this core container.  The issue arises when a user needs to compile a
groovy script against custom java services they have written an added to
their particular deployment container.  Adding a classloader to the core
PackageScanClassResolver has no effect, presumably because in
ScriptBuilder.java, the first attempt to create a ScriptEngine here:

https://github.com/apache/camel/blob/master/components/camel-script/src/main/java/org/apache/camel/builder/script/ScriptBuilder.java#L336

It defaults to using the classloader that loaded ScriptBuilder, rather than
the Camel Context or the current Thread's classloader, and all pathways I
have found initializing through the xml dialect, e.g.
<camel:script><camel:groovy/></camel:script> seem, when creating routes, to
go through ScriptBuilder#supportScriptEngine, which then initializes the
engine as above. Is there any point before which a Classloader can be
specified for the script engines that I may be missing?

Thanks,
Greg

Re: Classloaders and ScriptBuilder

[Greg Ludington <gl...@gmail.com>]

Answering my own question for the list, registering a singleton equivalent
to this snippet in my spring context appears to have solved it:

GroovyShellFactory gsf = new GroovyShellFactory() {
    public GroovyShell createGroovyShell(Exchange exchange) {
        return new GroovyShell(appClassLoader);
    }
};

Is there an equivalent factory for for each JSR scripting engine/would the
equivalent be needed for other engines?  If so, is there a technical or
historical reason that script engines do not default to using the same
Classloader as the containing camel context?

On Mon, Feb 19, 2018 at 8:18 PM, Greg Ludington <gl...@gmail.com>
wrote:

> Is there a means to have camel's script builder look at other classloaders
> besides the one in which ScriptBuilder was loaded?  We have a scenario with
> a core camel container, into which people deploy their own applications in
> private classloaders.  (As part of the tooling, camel-script is part of
> this core container.  The issue arises when a user needs to compile a
> groovy script against custom java services they have written an added to
> their particular deployment container.  Adding a classloader to the core
> PackageScanClassResolver has no effect, presumably because in
> ScriptBuilder.java, the first attempt to create a ScriptEngine here:
>
> https://github.com/apache/camel/blob/master/components/
> camel-script/src/main/java/org/apache/camel/builder/
> script/ScriptBuilder.java#L336
>
> It defaults to using the classloader that loaded ScriptBuilder, rather
> than the Camel Context or the current Thread's classloader, and all
> pathways I have found initializing through the xml dialect, e.g.
> <camel:script><camel:groovy/></camel:script> seem, when creating routes,
> to go through ScriptBuilder#supportScriptEngine, which then initializes
> the engine as above. Is there any point before which a Classloader can be
> specified for the script engines that I may be missing?
>
> Thanks,
> Greg
>