Hi Carsten,
I can't speak for exactly what Bertrand is thinking, but when I was
thinking about it, the scope/usage was an orthogonal concern to which
engine is selected.
Whereas today you do:
ScriptEngineManager.getEngineByExtension("ecma")
You could do
ScriptEngineManager.getEngineByExtension("ecma", ["healthcheck",
"workflow"])
(of course, we can't actually do that as ScriptEngineManager is a JDK
class; we'd have to create an extension)
Alternatively, this could be done after SlingScript object is created:
SlingScript script = resource.adaptTo(SlingScript.class);
script.setUsage(["healthcheck"]);
When creating the SlingBindings for the script to execute, the following
BindingsValuesProviders would be consulted (in order):
* the generic BVPs (which apply to all scripting languages)
* the BVPs tagged with the value of the script engine factory's
compatible.javax.script.name property
* the BVPs tagged with the script engine factory's name
* the BVPs tagged with the scope/usage property
Or something like that...
The significant advantage of doing this vs. hardcoding the usage-specific
bindings at the point of script engine access is that it doesn't allow for
downstream customization. Which is important IMHO in the case of
healthcheck - we want to enable custom hc rules which may benefit from a
custom BVP. This is also true in a workflow engine.
Justin
On Tue, Aug 6, 2013 at 1:41 PM, Carsten Ziegeler <cziege...@apache.org>wrote:
> Ok, just to make it clear, as long as there is no support in all script
> engines, I'm -1
>
> Carsten
>
>
> 2013/8/6 Justin Edelson <jus...@justinedelson.com>
>
> > Hi Bertrand,
> > FWIW, I was thinking about something very similar (although I was
> thinking
> > of calling it 'scope', not 'usage'), but never got around to implementing
> > it.
> >
> > +1 for me.
> >
> > Justin
> >
> >
> >
> > On Tue, Aug 6, 2013 at 10:58 AM, Bertrand Delacretaz <
> > bdelacre...@apache.org
> > > wrote:
> >
> > > Hi,
> > >
> > > I'd like to use BindingsValuesProvider services in my health check
> > > module, to provide bindings like "jmx" for scripted health checks,
> > > which should be ignored for general Sling scripting (or not - some
> > > providers might apply to both general scripting and health checks).
> > >
> > > I'm thinking of adding an optional "usage" service property to
> > > BindingsValuesProvider services, does anyone see a problem with that?
> > >
> > > The Sling script engine would then consider only
> > > BindingsValuesProvider which have no usage property (for backwards
> > > compatibility) or which have usage=scripting.
> > >
> > > And my health checks would consider only BindingsValuesProvider which
> > > have usage=healthcheck.
> > >
> > > -Bertrand
> > >
> >
>
>
>
> --
> Carsten Ziegeler
> cziege...@apache.org
>
