Hello,
If this thread is of any interest to anyone (perhaps to a list subscriber
or perhaps via a search engine and the mailing list archives...), here's
the solution I applied. With Nashorn in Java 8, you simply need to set the
context classloader before instantiating the ScriptEngine, as follows:
ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
thread.setContextClassLoader(MyApiInterface.class.getClassLoader());
ScriptEngine engine = scriptEngineManager.getEngineByName("nashorn");
thread.setContextClassLoader(contextClassLoader);
...where "MyApiInterface" is a reference to a class loaded from another
bundle (defining an API). Note that the ScriptEngineManager fails to find
the "nashorn" engine if instantiated after setting the context classloader.
A full discussion can be found here:
http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-February/004177.html
...including an alternative approach that involves injecting a "class
finder" function into the script binding, which provides additional
flexibility.
Hope that helps somebody,
Christopher
On 5 February 2015 at 23:46, Christopher BROWN <br...@reflexe.fr> wrote:
> Hello,
>
> Does anyone have any experience combining OSGi with the "nashorn"
> scripting engine?
>
> The specific use-case I'm trying to figure out would use the Java.type()
> then the Java.extend() syntax described here:
> https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions
>
> ...to define (on the JavaScript side) an implementation of an interface
> loaded from a bundle, and not from the main application classloader. There
> doesn't seem to be any problem passing IN an instance of interfaces via a
> Binding, it's defining the implementation and passing it OUT (or just using
> it inside the script) that seems undocumented. The ScriptEngine API
> doesn't seem to provide a standard way to specify one or more classloaders.
>
> Thanks,
> Christopher
>
>
