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 <>

> 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
>, the first attempt to create a ScriptEngine here:
> camel-script/src/main/java/org/apache/camel/builder/
> script/
> 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

Reply via email to