Hi
Am 06.08.2013 um 20:26 schrieb Justin Edelson:
> 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"]);
I don't think the SlingScript is the place to set the scope/usage on: The
script is provided with the bindings and executes code. In other words: The
Script does not manage its context or scope or usage itself. [Yes the code
currently does but this is an implementation detail and the actual BVPs are
provided by the SlingScriptAdapterFactory -- so in fact the
SlingScriptAdapterFactory currently does it]
Additionally, in SLING-2993 I proposed SlingScript to be @ConsumerType, so
extending this interface would require a major version update of the package
version.
Other options would be to set the scope on the ScriptEngineManager:
ScriptEngineManager sem = // service Reference
if (sem instanceof SlingScopeSupport) {
((SlingScopeSupport) sem).setScope(...);
}
ScriptEngine se = sem.getEngine....
Sling's ScriptEngineManager could then for example create proxy ScriptEngine
objects which would make sure the BVPs are called for script execution.
Regards
Felix
>
> 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 <[email protected]>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 <[email protected]>
>>
>>> 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 <
>>> [email protected]
>>>> 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
>> [email protected]
>>
