Best practices: Scripting languages

[Patrick Forhan <pf...@muddyhorse.com>]

I'm in a bit of a pickle with regards to using a scripting language
with OSGi.  Nothing insurmountable, but it is time consuming and I
want to do it right.

I'm using the ScriptEngineManager API (JSR-223) to discover
ScriptEngines.  It does this via the JAR file service provider style:
http://java.sun.com/javase/6/docs/technotes/guides/jar/jar.html#Service%20Provider

... In this case, it loads all resources named
META-INF/services/javax.script.ScriptEngineFactory

Consider the following set of bundles:

javafx -- ScriptEngine implementation, has the ScriptEngineFactory
file and some scripts
gui -- the main UI bundle, whose scripts reference scripts in widgets.
widgets -- some supplimental scripts

So, several bits of classloader magic here:
1) Finding the ScriptEngineFactory file
2) Finding the implementation the above points to
3) finding my scripts
4) finding the scripts in widgets and javafx.

What is the best mix of exports, imports and (the new-to-me)
DynamicImport-Package) in this case?  I seem to be finding myself
setting up classloaders and all sorts of things just to get parts of
the above working.  However, I tend to die on step 1 even though I can
manually ask the classloader to find the file for me.  Do I need to
list resources like scripts or the ScriptEngineFactory present as
exported packages?

Thanks,

Pat.
-- 
Defy mediocrity.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Best practices: Scripting languages

[Felix Meschberger <fm...@gmail.com>]

Hi Patrick,

Am Montag, den 17.09.2007, 14:25 -0500 schrieb Patrick Forhan:
> I'm using the ScriptEngineManager API (JSR-223) to discover
> ScriptEngines.  It does this via the JAR file service provider style:
> http://java.sun.com/javase/6/docs/technotes/guides/jar/jar.html#Service%20Provider

IIRC the manager also allows for explicit registration of ScriptEngines.
The JAR file service provider stuff is fine for traditional Java
applications but does not properly work in OSGi frameworks.

Given that your ScriptEngine implementations will come bundleized, I
suggest you implement a simple BundleListener in the javafx bundle,
which checks newly installed bundles for the respective
META-INF/services/javax.script.ScriptEngineFactory entries and manually
register the contents with the manager. When the bundle goes away, you
unregister the factory.

The ScriptEngine bundles would import the JSR-223 API. To instantiate
the factories from the bundles, you would use the
Bundle.loadClass(String) method of the providing bundle.


> So, several bits of classloader magic here:
> 1) Finding the ScriptEngineFactory file
> 2) Finding the implementation the above points to

See above for both, no class loader magic required

> 3) finding my scripts

I would use a similar approach as above: Define a special Manifest
header, which may help locate script files in bundles. As bundles are
registered/unregistered the respective locations from the Manifest
headers is added or removed from your script locator.

This is called the Extender Pattern by Peter Kriens. See [1] and [2] for
more information.

> 4) finding the scripts in widgets and javafx.

I am not actually fluent, how the different script interpreters resolve
additional scripts. But given the above mechanism of script
registration, you might build a resolver, which might be used by the
script interpreters.

Best of all: This all should run mostly without any class laoder
magic .. except perhaps setting up class loaders such that scripts may
resolve classes from bundles in which the scripts are contained...

Hope this helps.

Regards
Felix

[1] http://www.osgi.org/blog/2007/02/osgi-extender-model.html
[2] http://www.aqute.biz/Snippets/Extender


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org