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 <gluding...@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 >