Closed mfreeman-xtivia closed 8 years ago
You can close this one--I came up with a way to create a system extension to expose the nashorn api as an OSGi bundle. One thing perhaps for future consideration is the removal of the dependency on the Nashorn internal API--apparently used in only one file for access to the ECMAException class--since this is part of the internal Nashorn API I chose to fork the source for now and instead throw a ScriptException since I was moderately uncomfortable exposing the internal API through the OSGi classloader system.
I can have a look at this when I get some time, but if you have a suitable modification in your own fork I'll gladly accept a pull request :)
So this is more of a question than a bug per se, I guess.
At the moment it doesn't appear that the framework is usable in OSGi-based server environments because of the dependency on the jdk.nashorn.api.scripting package, because of the reference to the NashornScriptEngine class.
Typically the classloaders for OSGi bundles (and really the framework's parent loader) have filtered/restricted access to the classes in the bootloader/JDK. So attempts to reference jdk.* packages are not likely to work without some orchestration, perhaps even having to fiddle with the OSGi framework initialization configuration itself (which would be a non-starter for many clients)
So the larger question is why the dependency on the NashornEngine itself exists vs just a conventional reference to javax.script.ScriptEngine...and also, how hard (impossible?) would it be to undo said dependency in lieu of the standard ScriptEngine class...??