I'm not totally against this, but just adhoc adding this property without a
complete concept seems wrong to me. Defining the technical selection
process (e.g. as you describe it) is one part, but the other equally
important part, how to select from a script dev point of view. How can I
write a JSP and "tag" this as a "healtcheck" script? And how does this work
for other scripting languages?
Can we find a generic way that works in all / most scripting languages?
Do we really have different existing use cases apart from hc or is this
just a "it would be nice"?
As said, for JSPs we have taglibs which would solve the problem and doesn't
require a BVP, I think for javascript is something equivalent. Of course as
a provider of such support you have to provide different implementations (a
taglib, a javascript lib etc.) - and maybe we should tackle it from this
angle.
Carsten
2013/8/6 Justin Edelson <jus...@justinedelson.com>
> 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
> >
>
--
Carsten Ziegeler
cziege...@apache.org
