Hi

Am 07.08.2013 um 07:46 schrieb Carsten Ziegeler:

> 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?

I think this is not the question here. A script is a script is a script. It has 
to cope with the bindings it gets and if there would be missing bindings, it 
would have to cope.

The interesting thing would be a request processing script expecting e.g. the 
default request binding while this will not be provided by HealthCheck context. 
Such a request processing script would of course just fail with an NPE sooner 
or later.

A Healthcheck script could fail more gracefully by just checking for required 
bindings.

> 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"?

I would not bite my teeth into the scripts or some particular language. This is 
a dead end IMHO.

A script, at the end of the day, executes some action and might or might not 
expect some bindings (global variables in some languages). The script would 
have to cope with them missing or of the wrong type or such... But there is not 
currently a way that a script could declare "I am an HC script" or "I am a 
Request Processing script". Not even a taglib can do that -- at the end of the 
day a TagLib is syntactic sugar for functionality, which must also be usable 
otherwise.

Regards
Felix

> 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

Reply via email to