You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2007/10/31 12:47:43 UTC
Script engines as plugins?
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
Re: Script engines as plugins?
Posted by Lars Trieloff <la...@trieloff.net>.
Hi Bertrand,
In my opinion, adding script engines is the point where microsling
users should boot the big sling. We should, however, make the
migration path as smooth as possible.
Lars
Am 31.10.2007 um 12:47 schrieb Bertrand Delacretaz:
> 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
>
Re: Script engines as plugins?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/31/07, Thomas Mueller <th...@gmail.com> wrote:
> > 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.
>
> java.security, javax.sound, javax.crypto, javax.naming, and
> javax.print use this mechanism as well. ...
Ok, but what I meant is there's no general utility class that provides
this mechanism.
> ...In JDK 1.6, additionally
> java.sql (JDBC 3.0), javax.script, and javax.tools....
Actually, as someone indicated on the
ADVANCED-JAVA@discuss.develop.com list, JDK 1.6 includes
java.util.ServiceLoader, which is what I was looking for: a general
service loader utility.
But that's 1.6, so if we go this route,
javax.imageio.spi.ServiceRegistry is probably good enough.
-Bertrand
Re: Script engines as plugins?
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
> 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.
java.security, javax.sound, javax.crypto, javax.naming, and
javax.print use this mechanism as well. In JDK 1.6, additionally
java.sql (JDBC 3.0), javax.script, and javax.tools.
Thomas
Re: Script engines as plugins?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/31/07, David Nuescheler <da...@day.com> wrote:
> ....(3) how about using the workspace itself as an extension mechanism...
>
> something like:
>
> /.microsling/script-engines/esp
> /.microsling/script-engines/fm
> /.microsling/script-engines/rb
>
> ... which would host all the mapping information also allow for
> dynamic extension and distribution/installation as a content package....
That might be good once people grasp the JCR way of doing things, but
if we want people to be able to test the Velocity ScriptEngine in 20
minutes, the standard 15 minutes for microsling leave only 5 minutes
to install and test the VelocityScriptEngine.
I think microsling beginners will find it easier to drop a jar file somewhere.
-Bertrand
Re: Script engines as plugins?
Posted by Padraic Hannon <pi...@wasabicowboy.com>.
Perhaps then the servlet init method is best. I would rather edit the
web.xml than re-compile the script engine and all of the plugin
mechanism seem to overblown for what microsling is tackling.
-paddy
On Oct 31, 2007, at 12:18 PM, Felix Meschberger wrote:
> Hi,
>
> Am Mittwoch, den 31.10.2007, 15:37 +0100 schrieb David Nuescheler:
>> maybe thats a stupid idea and i am not sure if i even want
>> to bring up this option ;) :
>
> This idea is probably not stupid at all, but not appropriate for
> microsling, maybe.
>
>> (3) how about using the workspace itself as an extension mechanism...
>>
>> something like:
>>
>> /.microsling/script-engines/esp
>> /.microsling/script-engines/fm
>> /.microsling/script-engines/rb
>>
>> ... which would host all the mapping information also allow for
>> dynamic extension
>> and distribution/installation as a content package.
>
> Sounds really easy, but has some implications which make it
> inappropriate for microsling (keep in mind that microsling stands for
> small, limited, easy to understand, quick to fire-up): It needs class
> loader trickery as either the libraries are loaded through a JCR
> ClassLoader or are copied to some filesystem location to try to load
> them from there. Second phase is then "update": What happens if a
> library is updated or removed in the repository ?
>
> So, I would say, that for microsling, we should not use this.
>
> Regards
> Felix
>
Re: Script engines as plugins?
Posted by Padraic Hannon <pi...@wasabicowboy.com>.
Now that I have started to implement functionality to support using
jcr to store the classes and mapping for script extensions I see what
Felix is saying regarding adding complexity to microsling :-)
-paddy
On Oct 31, 2007, at 12:18 PM, Felix Meschberger wrote:
> Hi,
>
> Am Mittwoch, den 31.10.2007, 15:37 +0100 schrieb David Nuescheler:
>> maybe thats a stupid idea and i am not sure if i even want
>> to bring up this option ;) :
>
> This idea is probably not stupid at all, but not appropriate for
> microsling, maybe.
>
>> (3) how about using the workspace itself as an extension mechanism...
>>
>> something like:
>>
>> /.microsling/script-engines/esp
>> /.microsling/script-engines/fm
>> /.microsling/script-engines/rb
>>
>> ... which would host all the mapping information also allow for
>> dynamic extension
>> and distribution/installation as a content package.
>
> Sounds really easy, but has some implications which make it
> inappropriate for microsling (keep in mind that microsling stands for
> small, limited, easy to understand, quick to fire-up): It needs class
> loader trickery as either the libraries are loaded through a JCR
> ClassLoader or are copied to some filesystem location to try to load
> them from there. Second phase is then "update": What happens if a
> library is updated or removed in the repository ?
>
> So, I would say, that for microsling, we should not use this.
>
> Regards
> Felix
>
Re: Script engines as plugins?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Mittwoch, den 31.10.2007, 15:37 +0100 schrieb David Nuescheler:
> maybe thats a stupid idea and i am not sure if i even want
> to bring up this option ;) :
This idea is probably not stupid at all, but not appropriate for
microsling, maybe.
> (3) how about using the workspace itself as an extension mechanism...
>
> something like:
>
> /.microsling/script-engines/esp
> /.microsling/script-engines/fm
> /.microsling/script-engines/rb
>
> ... which would host all the mapping information also allow for
> dynamic extension
> and distribution/installation as a content package.
Sounds really easy, but has some implications which make it
inappropriate for microsling (keep in mind that microsling stands for
small, limited, easy to understand, quick to fire-up): It needs class
loader trickery as either the libraries are loaded through a JCR
ClassLoader or are copied to some filesystem location to try to load
them from there. Second phase is then "update": What happens if a
library is updated or removed in the repository ?
So, I would say, that for microsling, we should not use this.
Regards
Felix
Re: Script engines as plugins?
Posted by David Nuescheler <da...@day.com>.
> 1) Our own simple "jar service provider" mechanism
> 2) List of script engine class names as a MicroslingMainServlet init parameter
maybe thats a stupid idea and i am not sure if i even want
to bring up this option ;) :
(3) how about using the workspace itself as an extension mechanism...
something like:
/.microsling/script-engines/esp
/.microsling/script-engines/fm
/.microsling/script-engines/rb
... which would host all the mapping information also allow for
dynamic extension
and distribution/installation as a content package.
regards,
david
Re: Script engines as plugins?
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote:
> On 10/31/07, Padraic Hannon <pi...@wasabicowboy.com> wrote:
>
>> ...I thought David's suggestion seemed spot on. Let's use JCR to register
>> script types, this way the project becomes extremely simple, ...
>
>> ...If people agree I can have
>> something a patch put together as an example?..
>
> Why not...my concern is that this might be a bit foreign for people
> seeing JCR in action for the first time through microsling, but if you
> can provide a patch with a small effort, that would give us a concrete
> decision basis.
>
I'm not sure if this is the right approach for microsling. I'm not against
registering the engines in the repository, but this requires some mechanism
to actually registering an engine in the repository which would make
microsling bigger.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Script engines as plugins?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/31/07, Padraic Hannon <pi...@wasabicowboy.com> wrote:
> ...I thought David's suggestion seemed spot on. Let's use JCR to register
> script types, this way the project becomes extremely simple, ...
>...If people agree I can have
> something a patch put together as an example?..
Why not...my concern is that this might be a bit foreign for people
seeing JCR in action for the first time through microsling, but if you
can provide a patch with a small effort, that would give us a concrete
decision basis.
-Bertrand
Re: Script engines as plugins?
Posted by Padraic Hannon <pi...@wasabicowboy.com>.
I thought David's suggestion seemed spot on. Let's use JCR to register
script types, this way the project becomes extremely simple, if you
want a new script engine simply register it within the repository. If
we provide documentation and a few examples this should be enough for
beginners to understand how things work. If people agree I can have
something a patch put together as an example?
-paddy
On Oct 31, 2007, at 8:28 AM, Thomas Mueller wrote:
> Hi,
>
> It seems that javax.imageio.spi.ServiceRegistry is even supported by
> GNU Classpath:
> http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath.html
>
> I don't suggest to use GNU Classpath or to say it is supported, but if
> it's supported there, then chances are good it works everywhere.
>
> I agree ServiceRegistry is in the wrong package, that's why I was
> confused first. See also:
> See also: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4640520
>
> Thomas
>
> On 10/31/07, Marcel Reutegger <ma...@day.com> wrote:
>> Bertrand Delacretaz wrote:
>>> Are javax classes guaranteed to be provided in all VMs?
>>>
>>> The class in question is javax.imageio.spi.ServiceRegistry, and I'm
>>> not sure what the rules for javax classes are. So it might be easier
>>> to write those 10 lines than to find out, but if you have an
>>> authoritative reference on that I'm all ears!
>>
>> see: http://java.sun.com/products/jdk/faq/faq-sun-packages.html
>>
>> regards
>> marcel
>>
Re: Script engines as plugins?
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
It seems that javax.imageio.spi.ServiceRegistry is even supported by
GNU Classpath:
http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath.html
I don't suggest to use GNU Classpath or to say it is supported, but if
it's supported there, then chances are good it works everywhere.
I agree ServiceRegistry is in the wrong package, that's why I was
confused first. See also:
See also: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4640520
Thomas
On 10/31/07, Marcel Reutegger <ma...@day.com> wrote:
> Bertrand Delacretaz wrote:
> > Are javax classes guaranteed to be provided in all VMs?
> >
> > The class in question is javax.imageio.spi.ServiceRegistry, and I'm
> > not sure what the rules for javax classes are. So it might be easier
> > to write those 10 lines than to find out, but if you have an
> > authoritative reference on that I'm all ears!
>
> see: http://java.sun.com/products/jdk/faq/faq-sun-packages.html
>
> regards
> marcel
>
Re: Script engines as plugins?
Posted by Marcel Reutegger <ma...@day.com>.
Bertrand Delacretaz wrote:
> Are javax classes guaranteed to be provided in all VMs?
>
> The class in question is javax.imageio.spi.ServiceRegistry, and I'm
> not sure what the rules for javax classes are. So it might be easier
> to write those 10 lines than to find out, but if you have an
> authoritative reference on that I'm all ears!
see: http://java.sun.com/products/jdk/faq/faq-sun-packages.html
regards
marcel
Re: Script engines as plugins?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/31/07, Marcel Reutegger <ma...@day.com> wrote:
> Bertrand Delacretaz wrote:
> > 1) Our own simple "jar service provider" mechanism
> > microsling looks for jar files providing a file like [1] , using our
> > own simple ServiceLoader class (like Felix suggests, that's about 10
> > lines of code).
>
> just curious, why would you write those 10 lines if the JDK already provides
> what you are looking for?...
Are javax classes guaranteed to be provided in all VMs?
The class in question is javax.imageio.spi.ServiceRegistry, and I'm
not sure what the rules for javax classes are. So it might be easier
to write those 10 lines than to find out, but if you have an
authoritative reference on that I'm all ears!
-Bertrand
Re: Script engines as plugins?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/31/07, Marcel Reutegger <ma...@day.com> wrote:
> javax.imageio.spi.ServiceRegistry is in my opinion clearly specified and
> supported by all compliant JVMs.
>
> I'd rather say the class is in the wrong package. not a single aspect of the
> class is related to imageio!...
Agreed, the choice of package name looks wrong, but the class itself
is clearly specified.
-Bertrand
Re: Script engines as plugins?
Posted by Marcel Reutegger <ma...@day.com>.
Felix Meschberger wrote:
> Because using sun.misc is not an option (portability) and using
> javax.imageio is misusing an API, which is not the best of all options.
javax.imageio.spi.ServiceRegistry is in my opinion clearly specified and
supported by all compliant JVMs.
I'd rather say the class is in the wrong package. not a single aspect of the
class is related to imageio!
regards
marcel
Re: Script engines as plugins?
Posted by Felix Meschberger <fm...@gmail.com>.
Am Mittwoch, den 31.10.2007, 15:37 +0100 schrieb Marcel Reutegger:
> Bertrand Delacretaz wrote:
> > 1) Our own simple "jar service provider" mechanism
> > microsling looks for jar files providing a file like [1] , using our
> > own simple ServiceLoader class (like Felix suggests, that's about 10
> > lines of code).
>
> just curious, why would you write those 10 lines if the JDK already provides
> what you are looking for?
Because using sun.misc is not an option (portability) and using
javax.imageio is misusing an API, which is not the best of all options.
The problem in fact is, that the sun.misc.Service class (or
functionality if you wish) has not been defined as a API utility for far
too long.
Regards
Felix
Re: Script engines as plugins?
Posted by Marcel Reutegger <ma...@day.com>.
Bertrand Delacretaz wrote:
> 1) Our own simple "jar service provider" mechanism
> microsling looks for jar files providing a file like [1] , using our
> own simple ServiceLoader class (like Felix suggests, that's about 10
> lines of code).
just curious, why would you write those 10 lines if the JDK already provides
what you are looking for?
regards
marcel
Re: Script engines as plugins?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/31/07, Bertrand Delacretaz <bd...@apache.org> wrote:
> ...Which plugin mechanism do you suggest?...
I think we have two options at this point, I'll summarize here and
wait a bit in case more people want to make suggestions.
1) Our own simple "jar service provider" mechanism
microsling looks for jar files providing a file like [1] , using our
own simple ServiceLoader class (like Felix suggests, that's about 10
lines of code).
This is my favorite for now, it's clean and simple to implement, and
we can prepare ready-to-drop jar files of the ScriptEngines, which can
be OSGi bundles as well, for Sling OSGi.
2) List of script engine class names as a MicroslingMainServlet init parameter
microsling tries to load each engine, and if that fails forgets about
that engine.
Adding more engines is a bit less practical as one needs to edit web.xml.
[1] https://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-core/src/main/resources/META-INF/services/org.apache.jackrabbit.core.query.QueryTreeBuilder
Re: Script engines as plugins?
Posted by Michael Marth <mm...@day.com>.
>
>
> If you mean plugins written in Java, that would be Sling OSGi I
> guess...it might seem like a big beast now, but once refactored to the
> new sling-api, Sling OSGi shouldn't be much harder to use than
> microsling for simple things. So we could assume that people with that
> kind of needs would "graduate" to Sling OSGi,
>
> OTOH if by plugins you mean scripts that can be reused as software
> components in other scripts, that's a different topic, that might be
> interesting to explore...a bit later maybe ;-)
>
>
Well, I deliberately stayed away from the question how an application-level
plugin mechanism should be implemented. But, yes, I meant scripts that can
be reused (but not necessarily just visual components).
I agree, this discussion is probably a bit too early.
Re: Script engines as plugins?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/31/07, Michael Marth <mm...@day.com> wrote:
> ...A slightly off-topic side remark: at a later point it would be great to have
> application-level plugins that provide certain app infrastructure that is
> often needed (think web stats, a poll module, etc). These should be easy
> easy enough to implement for an app developer. It just occurred to me that
> this *ahem* requirement might influence this discussion....
If you mean plugins written in Java, that would be Sling OSGi I
guess...it might seem like a big beast now, but once refactored to the
new sling-api, Sling OSGi shouldn't be much harder to use than
microsling for simple things. So we could assume that people with that
kind of needs would "graduate" to Sling OSGi,
OTOH if by plugins you mean scripts that can be reused as software
components in other scripts, that's a different topic, that might be
interesting to explore...a bit later maybe ;-)
-Bertrand
Re: Script engines as plugins?
Posted by Michael Marth <mm...@day.com>.
Bertrand,
my (user perspective) vote goes to "only (1 engine) in the core, and make
all other engines plugins". ESP is fine with me (many people know JS and
it's easy enough to learn if they don't). I could also live with no plugin
mechanism and just one engine.
I agree with your comment that for starting a sling ecosystem it is
beneficial to focus on one language. It makes explaining concepts etc much
easier.
A slightly off-topic side remark: at a later point it would be great to have
application-level plugins that provide certain app infrastructure that is
often needed (think web stats, a poll module, etc). These should be easy
easy enough to implement for an app developer. It just occurred to me that
this *ahem* requirement might influence this discussion.
Cheers
Michael
On 10/31/07, Bertrand Delacretaz <bd...@apache.org> 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
>
Re: Script engines as plugins?
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote:
> On 10/31/07, Carsten Ziegeler <cz...@apache.org> wrote:
>
>> ...One simple solution would
>> be to have all script engines in microsling but make them optional....
>> ...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...
>
> That might be good enough, but you'd need a list of class names for
> potential ScriptEngines, right?
>
> That list might be an init parameter for the MicroslingMainServlet, so
> that people who need other scripting languages just need to add the
> corresponding class names to that parameter, and make the engine
> classes available.
Ah, yes, we could have a default value for that parameter and if people
really want to plugin their own one they have to provide this parameter.
Yepp, simple and works.
>
> We don't need to make scripting engines plugins super-easy in
> microsling, I agree that such a mechanism would be sufficient, and
> it's very easy to implement and understand.
>
Yepp, and the default impl comes with several engines, but we focus for
the samples one one.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Script engines as plugins?
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> Hmm, what this boils down to. So we currently have two options to decide
> on: The Jar Service provider mechanism and the servlet init-param
> listing classes.
>
> In the light of having a real Sling supporting OSGi extension model, I
> would not make it too easy for microsling to be extensible and implement
> a separate extension model (Jar Service provider) and hence stick with
> the init-param method.
>
> On the other hand, if we create the microsling-core only containing
> JavaScript and have a microsling-scripting-ext which contains a bunch of
> other scripting engines. What would go in the microsling-webapp ? Do we
> include microsling-scripting-ext or not ? I would say, we include and
> have a web app with everything but concentrate on the microsling-core
> project and just have microsling-scripting-ext as a by-product where we
> can dump scripting engines over time.
Yepp, that was my intention.
>
> On the other hand we could create a separate project for each scripting
> engine (probably outside of microsling inside a sling-scripting
> container. These would be implemented such as to provide easy use in the
> real sling. To be used in microsling, the microsling-webapp would have
> to be manually modified.
I'm not sure if we should create one project with all additional engines
or one project per engine. But in any case, we can add all engines to the
init parameter of the microsling-webapp. If one project contains all
additional engines, we have just to change this parameter in web.xml; if
there's one project per engine, we have to change the parameter and add
the dep to the pom. That doesn't look like too much work.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Script engines as plugins?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/31/07, Felix Meschberger <fm...@gmail.com> wrote:
> ...On the other hand we could create a separate project for each scripting
> engine (probably outside of microsling inside a sling-scripting
> container. These would be implemented such as to provide easy use in the
> real sling. ...
That's my preferred option: create one OSGi-compatible bundle jar for
each ScriptEngine, that can be used in microsling as well. That
implies a separate Maven module for each engine, under
sling-script/engines maybe.
> ...To be used in microsling, the microsling-webapp would have
> to be manually modified....
Not necessarily: we can list all known engines in the default webapp,
so that people just have to drop a jar file in the right place to
activate those engines.
> ...Ultimately, I still like the init-param based method best for
> microsling....
I'd be fine with that, if we list all current engines in web.xml.
-Bertrand
Re: Script engines as plugins?
Posted by Felix Meschberger <fm...@gmail.com>.
Hmm, what this boils down to. So we currently have two options to decide
on: The Jar Service provider mechanism and the servlet init-param
listing classes.
In the light of having a real Sling supporting OSGi extension model, I
would not make it too easy for microsling to be extensible and implement
a separate extension model (Jar Service provider) and hence stick with
the init-param method.
On the other hand, if we create the microsling-core only containing
JavaScript and have a microsling-scripting-ext which contains a bunch of
other scripting engines. What would go in the microsling-webapp ? Do we
include microsling-scripting-ext or not ? I would say, we include and
have a web app with everything but concentrate on the microsling-core
project and just have microsling-scripting-ext as a by-product where we
can dump scripting engines over time.
On the other hand we could create a separate project for each scripting
engine (probably outside of microsling inside a sling-scripting
container. These would be implemented such as to provide easy use in the
real sling. To be used in microsling, the microsling-webapp would have
to be manually modified.
Ultimately, I still like the init-param based method best for
microsling....
Regards
Felix
Am Mittwoch, den 31.10.2007, 14:50 +0100 schrieb Bertrand Delacretaz:
> On 10/31/07, Carsten Ziegeler <cz...@apache.org> wrote:
>
> > ...One simple solution would
> > be to have all script engines in microsling but make them optional....
> > ...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...
>
> That might be good enough, but you'd need a list of class names for
> potential ScriptEngines, right?
>
> That list might be an init parameter for the MicroslingMainServlet, so
> that people who need other scripting languages just need to add the
> corresponding class names to that parameter, and make the engine
> classes available.
>
> We don't need to make scripting engines plugins super-easy in
> microsling, I agree that such a mechanism would be sufficient, and
> it's very easy to implement and understand.
>
> -Bertrand
Re: Script engines as plugins?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/31/07, Carsten Ziegeler <cz...@apache.org> wrote:
> ...One simple solution would
> be to have all script engines in microsling but make them optional....
> ...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...
That might be good enough, but you'd need a list of class names for
potential ScriptEngines, right?
That list might be an init parameter for the MicroslingMainServlet, so
that people who need other scripting languages just need to add the
corresponding class names to that parameter, and make the engine
classes available.
We don't need to make scripting engines plugins super-easy in
microsling, I agree that such a mechanism would be sufficient, and
it's very easy to implement and understand.
-Bertrand
Re: Script engines as plugins?
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: Script engines as plugins?
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
> > jar service provider mechanism
> it has one serious drawback:
> The implementation is based on an internal class and thus not part of
> the Java API.
FYI it is available in JDK 1.6, but not yet in JDK 1.5:
http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html
Thomas
Re: Script engines as plugins?
Posted by Felix Meschberger <fm...@gmail.com>.
Am Mittwoch, den 31.10.2007, 14:46 +0100 schrieb Bertrand Delacretaz:
> On 10/31/07, Felix Meschberger <fm...@gmail.com> wrote:
>
> > >... 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:
> >
> > The mechanism is good and is in fact as Thomas points out used
> > throughout Sun's own implementations. But it has one serious drawback:
> > The implementation is based on an internal class and thus not part of
> > the Java API....
>
> You mean javax.imageio.spi.ServiceRegistry (which is what Jackrabbit
> uses) might not be available on non-Sun VMs, due to the "javax"
> prefix?
No, this class is available on all Java runtimes compliant to Java API
spec 1.4 and above. But using this is of course misusing a class :-)
Though it perfectly works.
>
> And you mention that BSF has its own implementation, I found this one:
>
> https://svn.apache.org/repos/asf/jakarta/bsf/trunk/bsf3/bsf-api/src/main/java/javax/script/ScriptEngineManager.java
>
> but that uses sun.misc.Service, which is probably what you mean by an
> internal class.
This is the internal class, I was referring to. I would, contrary to
Jackrabbit, opt for implementing a very simple implementation of the
sun.misc.Service class to implement the plugin mechanism. By simple I
mean: Just find the files using the class loader resource enumeration,
read those files, taking each line as a fully qualified ScriptEngine
class name (unless the line's first character is "#" or the line is
empty). This is really just a very short method of around 10 lines of
code.
Regards
Felix
Re: Script engines as plugins?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/31/07, Felix Meschberger <fm...@gmail.com> wrote:
> >... 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:
>
> The mechanism is good and is in fact as Thomas points out used
> throughout Sun's own implementations. But it has one serious drawback:
> The implementation is based on an internal class and thus not part of
> the Java API....
You mean javax.imageio.spi.ServiceRegistry (which is what Jackrabbit
uses) might not be available on non-Sun VMs, due to the "javax"
prefix?
And you mention that BSF has its own implementation, I found this one:
https://svn.apache.org/repos/asf/jakarta/bsf/trunk/bsf3/bsf-api/src/main/java/javax/script/ScriptEngineManager.java
but that uses sun.misc.Service, which is probably what you mean by an
internal class.
-Bertrand
Re: Script engines as plugins?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Mittwoch, den 31.10.2007, 12:47 +0100 schrieb Bertrand Delacretaz:
> 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.
+1
> 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.
+1
> 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.
+1
> 1) Use BSF, the Bean Scripting Framework
The BSFManager has two options to register: Explicit registration
calling a method and discovery of a BSFEngines by listing them in a
certain file in the JAR (same idea as the Jar service provider
mechanism)
> 2) Use the JDK 1.6 scripting framework
Also uses the Jar Service provider in the background. In fact, the
SlingScriptEngine interface is a small subset of the Java Scripting
ScriptEngine/ScriptEngineFactory interfaces.
> 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:
The mechanism is good and is in fact as Thomas points out used
throughout Sun's own implementations. But it has one serious drawback:
The implementation is based on an internal class and thus not part of
the Java API. Hence, if we use the mechanism we should either implement
it ourselves or use BSF, which also has an implementation. We should at
all cost NOT use the implementation used by the Java 6 javax.script e.a.
> WDYT, do we agree on keeping just javascript/ESP in the core, yet
> support script engine plugins in microsling?
+1
> Which plugin mechanism do you suggest?
Have a simple implementation of the Service Provider Mechanism.
Regards
Felix