I'm not sure if we really need a real plugin mechanism for microsling. I think we should keep it as simple as possible. One simple solution would be to have all script engines in microsling but make them optional. For example if rhino is available, the js engine can be used. If rhino is not in the classpath, the engine is not available.
The detection if the required stuff is available in the classpath could be done by just trying to instantiate the engine always. If instantiation fails, its not an error, but the engine is not available. Not very sophisticated but I think its sufficient. Carsten Bertrand Delacretaz wrote: > Hi, > > (ouch - more than five lines once again) > > We have now three script engines in microsling, and some ideas > floating around for more (SLING-90). > > While I find it good to let people experiment with their favorite > scripting language (especially with the "playground" bias of > microsling), I think we need to focus a small number of languages for > our examples, and keep our microsling distribution size slow. I'd keep > only javascript / ESP in the core, and make all other engines plugins. > > Script engines as plugins will be easy to do in Sling OSGi, but we > need some lightweight mechanism for microsling. The same engine jars > should be usable in both microsling and sling. > > My requirements for microsling would be that any script engine jar > file found in the microsling servlet classpath is activated at > startup, including discovery of the file extensions supported by the > engine. > > - o - > > Here are some options, I have not used any of them before so comments > are welcome. > > 1) Use BSF, the Bean Scripting Framework > See http://jakarta.apache.org/bsf/, that's well-known and stable. > > Not sure if and how BSF would help us make script engine plugins. > > 2) Use the JDK 1.6 scripting framework > > http://java.sun.com/javase/6/docs/technotes/guides/scripting/programmer_guide/index.html > > And that might work for JDK 1.5 as well: > > http://www.oreillynet.com/onjava/blog/2007/09/scripting_api_for_everyone.html > > 3) Keep our existing interfaces an use the jar service provider mechanism > Jackrabbit uses that for query syntax plugins, a plugin jar needs a > text file like this one: > > https://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-core/src/main/resources/META-INF/services/org.apache.jackrabbit.core.query.QueryTreeBuilder > > which allows this class to discover the query engines: > > https://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/query/QueryTreeBuilderRegistry.java > > The spec is here: > > http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service%20Provider > > Surprisingly, it seems like javax.imageio.spi.ServiceRegistry is the > only public JDK class that implements this lookup method. > > - o - > > WDYT, do we agree on keeping just javascript/ESP in the core, yet > support script engine plugins in microsling? > > Which plugin mechanism do you suggest? > > -Bertrand > -- Carsten Ziegeler [EMAIL PROTECTED]
