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 2013/08/06 16:58:03 UTC
Adding a "usage" service property to BindingsValuesProvider ?
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
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Carsten Ziegeler <cz...@apache.org>.
2013/8/7 Felix Meschberger <fm...@adobe.com>
>
> 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".
Exactly, that's my point - and unless we have a mechanism for this, marking
a BVP is useless.
> 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.
>
Right - but it fits exactly the needs at least in JSP of what is discussed
here. Instead of saying "I'm a workflow script" , the script uses the
workflow taglib.
Carsten
>
> 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 <ju...@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 <cziegeler@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 <ju...@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 <
> >>>> bdelacretaz@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
> >>> cziegeler@apache.org
> >>>
> >>
> >
> >
> >
> > --
> > Carsten Ziegeler
> > cziegeler@apache.org
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Aug 7, 2013 at 9:43 AM, Felix Meschberger <fm...@adobe.com> wrote:
> ...In fact having written my previous messages, I wonder, whether our default values we provide
> to scripts (request, response, etc.) should not really be provided by a BVP in the "request" (or such)
> scope/context/usage ;-)
Yes, we could mark our own BVPs with context=request from now on, but
the request processing script engines should also get any BVPs which
do not have a "context" service property, for backwards compatibility.
> ...Somehow I tend to get to the term "context" for this thing.
Ok, that was my first idea and Justin's as well, "context" sounds good
- I'll rephrase my proposal accordingly, coming up...
-Bertrand
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Felix Meschberger <fm...@adobe.com>.
Hi Bertrand
We don't really disagree at all ;-)
In fact having written my previous messages, I wonder, whether our default values we provide to scripts (request, response, etc.) should not really be provided by a BVP in the "request" (or such) scope/context/usage ;-)
Somehow I tend to get to the term "context" for this thing.
Regards
Felix
Am 07.08.2013 um 09:34 schrieb Bertrand Delacretaz:
> On Wed, Aug 7, 2013 at 9:04 AM, Felix Meschberger <fm...@adobe.com> wrote:
>> ...But there is not currently a way that a script could declare "I am an HC script" or
>> "I am a Request Processing script"...
>
> The missing piece here is that the HC scripts that I'm talking about
> (and probably the workflow ones that Justin mentioned) are *not* your
> usual Sling script, adapted from a Resource etc.
>
> In the HC case the (mini-)script is just an expression that's part of
> an OSGi config (see SLING-2987 for examples), as in:
>
> expression = jmx.attribute('java.lang:type=ClassLoading',
> 'LoadedClassCount') > 10
>
> so the separation between request processing scripts and HC scripts is
> obvious. They are executed in very different contexts, which warrant
> different script bindings.
>
> In the HC case, bindings need to be provided by OSGi services so as to
> be extensible - we have an existing API to do that
> (BindingValuesProviders), the proposal is simply to allow that API to
> indicate more specifically what the bindings are meant to be used for.
>
> Hardcoded bindings for HC are unnecessarily limitative, and inventing
> a different bindings provider API just for HC feels very wrong, so I
> have a hard time understanding the reluctance to this proposal.
>
> -Bertrand
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Aug 7, 2013 at 9:04 AM, Felix Meschberger <fm...@adobe.com> wrote:
> ...But there is not currently a way that a script could declare "I am an HC script" or
> "I am a Request Processing script"...
The missing piece here is that the HC scripts that I'm talking about
(and probably the workflow ones that Justin mentioned) are *not* your
usual Sling script, adapted from a Resource etc.
In the HC case the (mini-)script is just an expression that's part of
an OSGi config (see SLING-2987 for examples), as in:
expression = jmx.attribute('java.lang:type=ClassLoading',
'LoadedClassCount') > 10
so the separation between request processing scripts and HC scripts is
obvious. They are executed in very different contexts, which warrant
different script bindings.
In the HC case, bindings need to be provided by OSGi services so as to
be extensible - we have an existing API to do that
(BindingValuesProviders), the proposal is simply to allow that API to
indicate more specifically what the bindings are meant to be used for.
Hardcoded bindings for HC are unnecessarily limitative, and inventing
a different bindings provider API just for HC feels very wrong, so I
have a hard time understanding the reluctance to this proposal.
-Bertrand
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Felix Meschberger <fm...@adobe.com>.
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 <ju...@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 <cziegeler@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 <ju...@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 <
>>>> bdelacretaz@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
>>> cziegeler@apache.org
>>>
>>
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <ju...@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 <cziegeler@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 <ju...@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 <
> > > bdelacretaz@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
> > cziegeler@apache.org
> >
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Sep 6, 2013 at 10:43 PM, Felix Meschberger <fm...@adobe.com> wrote:
> Hmm, why not turning this around and ammed the BindingsValueProvider interface ?
>
>> public interface BindingsValuesProvider2 extends BindingsValueProvider {
>> void addBindings(Bindings bindings, ScriptEngineFactory, String context);
>> }
>>...
What we have now is clearer IMO:
BindingsValuesProvider always was and remains a simple provider of
Bindings, that can be marked via service properties to apply to
specific languages and contexts.
BindingsValuesProvidersByContext is a source of
BindingsValuesProvider, which takes context and languages into account
to select them. Clients can also select the BVPs themselves directly
based on their service properties, if that's more convenient or to
avoid having to require the latest scripting api.
What you're suggesting would be more confusing IMO, as having to use
instanceof is somewhat ugly.
-Bertrand
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Felix Meschberger <fm...@adobe.com>.
Hmm, why not turning this around and ammed the BindingsValueProvider interface ?
> public interface BindingsValuesProvider2 extends BindingsValueProvider {
> void addBindings(Bindings bindings, ScriptEngineFactory, String context);
> }
>
The BindingsValuesProvider2 is a marker interface to the BindginsValuesProvider service interface. A consumer would do
> BindingsValuesProvider[] bvps = getProviders();
> foreach (BindingsValuesProvider bvp: bvps) {
> if (bvp instanceof BindingsValuesProvider2) {
> // use with scope
> } else {
> // use without scope
> }
> }
>
Regards
Felix
Am 06.09.2013 um 06:04 schrieb Bertrand Delacretaz:
> On Thu, Sep 5, 2013 at 1:28 PM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>> ...Maybe
>>
>> addContextBindings(Bindings b, ScriptEngineFactory f, String context)
>> ...
>
> FYI I didn't do it like that in the end, as that would have caused
> more changes than I like to existing code. The new service API is at
> https://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/api/src/main/java/org/apache/sling/scripting/api/BindingsValuesProvidersByContext.java
>
> Apart from that this is now done, see SLING-3038 for details,
>
> -Bertrand
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
What about Import-Package version ? Which is why I poke at the @ConsumerType annotation.
@ConsumerType: We promise not to change the API unless we increase the major version of the export
@ProviderType: We promise not to change the API unless we increase the minor version of the export
Regards
Felix
Am 09.09.2013 um 16:24 schrieb Bertrand Delacretaz:
> Hi,
>
> On Mon, Sep 9, 2013 at 3:26 PM, Felix Meschberger <fm...@adobe.com> wrote:
>> Am 09.09.2013 um 11:45 schrieb Bertrand Delacretaz:
>>> ...done in revision 1521017
>> ...
>> You added a constant to the interface, so what will the export package version be ? and the compatibility consequences ? Is this interface @ConsumerType...
>
> I have already bumped the api package version to 2.2.0, from 2.1.0, in
> http://svn.apache.org/r1520565 (in the api module pom), after adding
> the new BindingsValuesProvidersByContext interface.
>
> I don't think adding new constants to BindingsValuesProviders has any
> consequences for implementing classes, they won't see any difference.
> or will they?
>
> -Bertrand
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Mon, Sep 9, 2013 at 3:26 PM, Felix Meschberger <fm...@adobe.com> wrote:
> Am 09.09.2013 um 11:45 schrieb Bertrand Delacretaz:
>>...done in revision 1521017
>...
> You added a constant to the interface, so what will the export package version be ? and the compatibility consequences ? Is this interface @ConsumerType...
I have already bumped the api package version to 2.2.0, from 2.1.0, in
http://svn.apache.org/r1520565 (in the api module pom), after adding
the new BindingsValuesProvidersByContext interface.
I don't think adding new constants to BindingsValuesProviders has any
consequences for implementing classes, they won't see any difference.
or will they?
-Bertrand
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 09.09.2013 um 11:45 schrieb Bertrand Delacretaz:
> On Fri, Sep 6, 2013 at 3:31 PM, Carsten Ziegeler <cz...@apache.org> wrote:
>> ...The constants should really be defined in the BVP class, this is the
>> service declaring them...
>
> Good point, done in revision 1521017
Hmm. While this makes sense, doesn't it introduce versioning problems ?
You added a constant to the interface, so what will the export package version be ? and the compatibility consequences ? Is this interface @ConsumerType
Regards
Felix
>
>>
>> ... I don't understand what you mean by "changes to existing code" - this is
>> new, isn't it?...
>
> Yes but existing code does use BindingsValuesProvider, and
> BindingsValuesProvidersByContext returning a Collection causes less
> changes to that existing code than the addContextBindings method that
> we discussed. I don't think one is better than the other anyway, it's
> just slightly different styles.
>
> -Bertrand
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Sep 6, 2013 at 3:31 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...The constants should really be defined in the BVP class, this is the
> service declaring them...
Good point, done in revision 1521017
>
>... I don't understand what you mean by "changes to existing code" - this is
> new, isn't it?...
Yes but existing code does use BindingsValuesProvider, and
BindingsValuesProvidersByContext returning a Collection causes less
changes to that existing code than the addContextBindings method that
we discussed. I don't think one is better than the other anyway, it's
just slightly different styles.
-Bertrand
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Carsten Ziegeler <cz...@apache.org>.
The constants should really be defined in the BVP class, this is the
service declaring them
I don't understand what you mean by "changes to existing code" - this is
new, isn't it?
Carsten
2013/9/6 Bertrand Delacretaz <bd...@apache.org>
> On Thu, Sep 5, 2013 at 1:28 PM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
> > ...Maybe
> >
> > addContextBindings(Bindings b, ScriptEngineFactory f, String context)
> > ...
>
> FYI I didn't do it like that in the end, as that would have caused
> more changes than I like to existing code. The new service API is at
>
> https://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/api/src/main/java/org/apache/sling/scripting/api/BindingsValuesProvidersByContext.java
>
> Apart from that this is now done, see SLING-3038 for details,
>
> -Bertrand
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Sep 5, 2013 at 1:28 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> ...Maybe
>
> addContextBindings(Bindings b, ScriptEngineFactory f, String context)
> ...
FYI I didn't do it like that in the end, as that would have caused
more changes than I like to existing code. The new service API is at
https://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/api/src/main/java/org/apache/sling/scripting/api/BindingsValuesProvidersByContext.java
Apart from that this is now done, see SLING-3038 for details,
-Bertrand
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Carsten Ziegeler <cz...@apache.org>.
As our api is in the api bundle, well api it is :)
The package version will be 2.2.0 as this is adding new api
Carsten
2013/9/5 Bertrand Delacretaz <bd...@apache.org>
> On Thursday, September 5, 2013, Carsten Ziegeler wrote:
>
> > If you need to know the language, can't we pass this as a string into the
> > service?...
>
> It's not only the language, some other ScriptEngineFactory metadata such as
> compatible.javax.script.name is used.
>
> Now, where should that new service interface go, scripting.api bundle or
> scripting.core?
>
> I'd say scripting.api, and we bump the API package's version to 2.1.1 (from
> the current 2.1.0).
>
> -Bertrand
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thursday, September 5, 2013, Carsten Ziegeler wrote:
> If you need to know the language, can't we pass this as a string into the
> service?...
It's not only the language, some other ScriptEngineFactory metadata such as
compatible.javax.script.name is used.
Now, where should that new service interface go, scripting.api bundle or
scripting.core?
I'd say scripting.api, and we bump the API package's version to 2.1.1 (from
the current 2.1.0).
-Bertrand
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Carsten Ziegeler <cz...@apache.org>.
If you need to know the language, can't we pass this as a string into the
service?
Other than that, add sounds good to me (don't know why I picked apply
anyway...)
Carsten
2013/9/5 Bertrand Delacretaz <bd...@apache.org>
> On Thu, Sep 5, 2013 at 10:14 AM, Carsten Ziegeler <cz...@apache.org>
> wrote:
> > What about defining a service (whatever name :) ) that has something
> like a:
> > applyBindings(Bindings b , String context)
> > method?...
>
> Maybe
>
> addContextBindings(Bindings b, ScriptEngineFactory f, String context)
>
> As the ScriptEngineFactory is needed to know what the current language
> is, and "add" for consistent naming with the existing
> BindingsValuesProvider.addBindings(Bindings b) method.
>
> WDYT?
>
> -Bertrand
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Sep 5, 2013 at 10:14 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> What about defining a service (whatever name :) ) that has something like a:
> applyBindings(Bindings b , String context)
> method?...
Maybe
addContextBindings(Bindings b, ScriptEngineFactory f, String context)
As the ScriptEngineFactory is needed to know what the current language
is, and "add" for consistent naming with the existing
BindingsValuesProvider.addBindings(Bindings b) method.
WDYT?
-Bertrand
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Carsten Ziegeler <cz...@apache.org>.
What about defining a service (whatever name :) ) that has something like a:
applyBindings(Bindings b , String context)
method?
Internally this service can do whatever magic it has to do, like looking up
all BVPs with the specified context attribute set etc.
You prefill your bindings with the objs you think that should be there
before calling that service.
If you want to support multiple contexts, simply call this method more than
once with the different context names.
Carsten
2013/9/5 Bertrand Delacretaz <bd...@apache.org>
> Hi Justin,
>
> On Tuesday, August 6, 2013, Justin Edelson wrote:
>
> > ...Whereas today you do:
> > ScriptEngineManager.getEngineByExtension("ecma")
> >
> > You could do
> > ScriptEngineManager.getEngineByExtension("ecma", ["healthcheck",
> "workflow"]) ...
>
> FYI, I'm getting back to this (SLING-3038) and the above won't work for my
> use case, as I need to setup some initial Bindings that provide context
> objects, before calling BindingValuesProvider.addBindings(...).
>
> The scenario that I'm considering is:
>
> String context = "healthcheck"; // I don't think we need multiple
> contexts??
> ScriptEngine engine = scriptEngineManager.getEngineByExtension("foo");
> Bindings b = engine.createBindings();
> b.put("bar", new SomethingThatOtherBindingsNeed());
> for(BindingValuesProvider bvp : someProvider.getBindings(engine, context))
> {
> bvp.addBindings(b);
> }
>
> where someProvider is a new service that I'm afraid might be called
> BindingValuesProviderProvider...suggestions welcome ;-)
>
> In the above loop, some BVPs use the "bar" object to create their bound
> objects, as we already do with the BVP that provides "currentNode" if
> there's a "resource" bound when it's called.
>
> -Bertrand
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Justin,
On Tuesday, August 6, 2013, Justin Edelson wrote:
> ...Whereas today you do:
> ScriptEngineManager.getEngineByExtension("ecma")
>
> You could do
> ScriptEngineManager.getEngineByExtension("ecma", ["healthcheck",
"workflow"]) ...
FYI, I'm getting back to this (SLING-3038) and the above won't work for my
use case, as I need to setup some initial Bindings that provide context
objects, before calling BindingValuesProvider.addBindings(...).
The scenario that I'm considering is:
String context = "healthcheck"; // I don't think we need multiple contexts??
ScriptEngine engine = scriptEngineManager.getEngineByExtension("foo");
Bindings b = engine.createBindings();
b.put("bar", new SomethingThatOtherBindingsNeed());
for(BindingValuesProvider bvp : someProvider.getBindings(engine, context)) {
bvp.addBindings(b);
}
where someProvider is a new service that I'm afraid might be called
BindingValuesProviderProvider...suggestions welcome ;-)
In the above loop, some BVPs use the "bar" object to create their bound
objects, as we already do with the BVP that provides "currentNode" if
there's a "resource" bound when it's called.
-Bertrand
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Felix Meschberger <fm...@adobe.com>.
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 <cz...@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 <ju...@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 <
>>> bdelacretaz@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
>> cziegeler@apache.org
>>
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Justin Edelson <ju...@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 <cz...@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 <ju...@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 <
> > bdelacretaz@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
> cziegeler@apache.org
>
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <ju...@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 <
> bdelacretaz@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
cziegeler@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Justin Edelson <ju...@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 <bdelacretaz@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
>
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Carsten Ziegeler <cz...@apache.org>.
And forgot to mention :) I think your current approach is fine, as these
objects are special objects for health checks, you have special execution
code and can handle it there.
Carsten
2013/8/6 Carsten Ziegeler <cz...@apache.org>
> I think if we would be in the jsp world, you would do a taglib for this -
> of course taglibs are not usable within other scripting languages - so
> depending on your script language you would have to come up with the
> equivalent.
> Taglibs in JSP allow exactly what you want - the BVP is more a way to make
> objects always available to all script engines; so apart from adding the
> optional node and session objects, we don't use this in Sling at all...
>
> Carsten
>
>
> 2013/8/6 Bertrand Delacretaz <bd...@apache.org>
>
>> On Tue, Aug 6, 2013 at 5:39 PM, Carsten Ziegeler <cz...@apache.org>
>> wrote:
>> > I guess this only works as you have a special script engine for health
>> > check, right?
>>
>> Not really a special script engine, but I'm using the
>> ScriptEngineManager directly instead of going through SlingScript.
>>
>> See code at [1] where bindings are hardcoded for now - I could invent
>> my own bindings providers interface but as we already have one why not
>> reuse it?
>>
>> >
>> > What if people want to use the same functionality if they write lets say
>> > workflow scripts or wcm scripts etc?
>>
>> The bindings service could be marked with
>> usage=healthcheck,workflow,wcm, or the consumers could be configured
>> to use bindings which are marked with usage=healthcheck.
>>
>> > As long as there is no way to make use of this in every script engine, I
>> > don't see the point of adding it. It's a special requirement for hc, so
>> it
>> > should have a hc solution.
>>
>> That's an option of course, that's why I'm asking for opinions.
>>
>> -Bertrand
>>
>> [1]
>> https://svn.apache.org/repos/asf/sling/branches/SLING-2987-healthcheck-redesign/hc-core/src/main/java/org/apache/sling/hc/impl/ScriptableHealthCheck.java
>>
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Carsten Ziegeler <cz...@apache.org>.
I think if we would be in the jsp world, you would do a taglib for this -
of course taglibs are not usable within other scripting languages - so
depending on your script language you would have to come up with the
equivalent.
Taglibs in JSP allow exactly what you want - the BVP is more a way to make
objects always available to all script engines; so apart from adding the
optional node and session objects, we don't use this in Sling at all...
Carsten
2013/8/6 Bertrand Delacretaz <bd...@apache.org>
> On Tue, Aug 6, 2013 at 5:39 PM, Carsten Ziegeler <cz...@apache.org>
> wrote:
> > I guess this only works as you have a special script engine for health
> > check, right?
>
> Not really a special script engine, but I'm using the
> ScriptEngineManager directly instead of going through SlingScript.
>
> See code at [1] where bindings are hardcoded for now - I could invent
> my own bindings providers interface but as we already have one why not
> reuse it?
>
> >
> > What if people want to use the same functionality if they write lets say
> > workflow scripts or wcm scripts etc?
>
> The bindings service could be marked with
> usage=healthcheck,workflow,wcm, or the consumers could be configured
> to use bindings which are marked with usage=healthcheck.
>
> > As long as there is no way to make use of this in every script engine, I
> > don't see the point of adding it. It's a special requirement for hc, so
> it
> > should have a hc solution.
>
> That's an option of course, that's why I'm asking for opinions.
>
> -Bertrand
>
> [1]
> https://svn.apache.org/repos/asf/sling/branches/SLING-2987-healthcheck-redesign/hc-core/src/main/java/org/apache/sling/hc/impl/ScriptableHealthCheck.java
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Aug 6, 2013 at 5:39 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> I guess this only works as you have a special script engine for health
> check, right?
Not really a special script engine, but I'm using the
ScriptEngineManager directly instead of going through SlingScript.
See code at [1] where bindings are hardcoded for now - I could invent
my own bindings providers interface but as we already have one why not
reuse it?
>
> What if people want to use the same functionality if they write lets say
> workflow scripts or wcm scripts etc?
The bindings service could be marked with
usage=healthcheck,workflow,wcm, or the consumers could be configured
to use bindings which are marked with usage=healthcheck.
> As long as there is no way to make use of this in every script engine, I
> don't see the point of adding it. It's a special requirement for hc, so it
> should have a hc solution.
That's an option of course, that's why I'm asking for opinions.
-Bertrand
[1] https://svn.apache.org/repos/asf/sling/branches/SLING-2987-healthcheck-redesign/hc-core/src/main/java/org/apache/sling/hc/impl/ScriptableHealthCheck.java
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Carsten Ziegeler <cz...@apache.org>.
I guess this only works as you have a special script engine for health
check, right?
What if people want to use the same functionality if they write lets say
workflow scripts or wcm scripts etc?
As long as there is no way to make use of this in every script engine, I
don't see the point of adding it. It's a special requirement for hc, so it
should have a hc solution.
Carsten
2013/8/6 Bertrand Delacretaz <bd...@apache.org>
> On Tue, Aug 6, 2013 at 5:13 PM, Carsten Ziegeler <cz...@apache.org>
> wrote:
> > I'm not sure if I understand this 100% - from a scripting pov, how could
> I
> > set the usage value, let's say in a JSP (or any other script)?
>
> You set the usage property when you create a BindingsValuesProvider,
> so for my jmx example I'd do:
>
> @Service
> @Property(name="usage", value="healthcheck")
> public class BindingsValuesProvider {
> public void addBindings(Bindings b) {
> b.put("jmx", new SomeObjectThatsSeenAsJmxFromHealthCheckScripts());
> }
> }
>
> that "jmx" object is then available in health check scripts, but not
> in general Sling rendering scripts.
>
> -Bertrand
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Aug 6, 2013 at 5:13 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> I'm not sure if I understand this 100% - from a scripting pov, how could I
> set the usage value, let's say in a JSP (or any other script)?
You set the usage property when you create a BindingsValuesProvider,
so for my jmx example I'd do:
@Service
@Property(name="usage", value="healthcheck")
public class BindingsValuesProvider {
public void addBindings(Bindings b) {
b.put("jmx", new SomeObjectThatsSeenAsJmxFromHealthCheckScripts());
}
}
that "jmx" object is then available in health check scripts, but not
in general Sling rendering scripts.
-Bertrand
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Carsten Ziegeler <cz...@apache.org>.
I'm not sure if I understand this 100% - from a scripting pov, how could I
set the usage value, let's say in a JSP (or any other script)?
Carsten
2013/8/6 Bertrand Delacretaz <bd...@apache.org>
> 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
cziegeler@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Aug 7, 2013 at 11:47 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...scripts run with the usual Sling script resolution will always just use
> BVPs not marked for any context and BVPs marked for the context request...
That's exactly the idea - no change for existing request processing
scripts, and the ability to use scripts in different contexts, without
polluting the "request" scripting context with useless or potentially
dangerous bound objects.
> I still fail to see the usefulness - but as you all seem to go crazy about
> it, I wont block this..
thanks!
-Bertrand
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Carsten Ziegeler <cz...@apache.org>.
Hmm, this doesn't really convince me. So this means there is no way to set
the context apart from creating/retrieving a script engine by hand (java
code)?
So scripts run with the usual Sling script resolution will always just use
BVPs not marked for any context and BVPs marked for the context request.
I still fail to see the usefulness - but as you all seem to go crazy about
it, I wont block this
Carsten
2013/8/7 Bertrand Delacretaz <bd...@apache.org>
> On Wed, Aug 7, 2013 at 10:26 AM, Carsten Ziegeler <cz...@apache.org>
> wrote:
> > Again, I'm still missing a suggestion on how to mark a script to run in a
> > given context...
>
> You don't.
>
> There are request processing scripts, the ones we have and always had
> - there's no change for those, except that with this change they won't
> get any BVPs which are marked for a context that is not "request".
> Existing BVPs are not marked like that so no change. There's no way
> and no need to mark those scripts for a different context, they are
> "request" processing scripts.
>
> Then there are new health check (mini-)scripts which are different
> animals: they are provided in OSGi configs as shown earlier in this
> thread. Their context is hardcoded to "healthcheck", there's no need
> to change that.
>
> Another way to look at this, and maybe I should have phrased my
> proposal like that, is that the goal is to setup different script
> engines: currently we're just using a "request processing" script
> engine, I need a "healtcheck" script engine with different bindings,
> and it makes sense to generalize the idea.
>
> -Bertrand
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Aug 7, 2013 at 10:26 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Again, I'm still missing a suggestion on how to mark a script to run in a
> given context...
You don't.
There are request processing scripts, the ones we have and always had
- there's no change for those, except that with this change they won't
get any BVPs which are marked for a context that is not "request".
Existing BVPs are not marked like that so no change. There's no way
and no need to mark those scripts for a different context, they are
"request" processing scripts.
Then there are new health check (mini-)scripts which are different
animals: they are provided in OSGi configs as shown earlier in this
thread. Their context is hardcoded to "healthcheck", there's no need
to change that.
Another way to look at this, and maybe I should have phrased my
proposal like that, is that the goal is to setup different script
engines: currently we're just using a "request processing" script
engine, I need a "healtcheck" script engine with different bindings,
and it makes sense to generalize the idea.
-Bertrand
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Carsten Ziegeler <cz...@apache.org>.
Again, I'm still missing a suggestion on how to mark a script to run in a
given context.
Carsten
2013/8/7 Bertrand Delacretaz <bd...@apache.org>
> On Wed, Aug 7, 2013 at 10:09 AM, Felix Meschberger <fm...@adobe.com>
> wrote:
> > ...In fact I would say, that BVPs without the property should just be
> used anywhere....
>
> that might work - I was going to say that [1] for example makes no
> sense in my health check context, but that provider is being careful
> to not add anything if the "resource" binding is not available so
> we're fine.
>
> >> ...3. Provide a service to collect relevant BVPs when setting up
> >> scripting, based on a set of context values.
> >
> > Since the selection is so easy with a service selection filter or target
> attribute on a @Reference annotation, such a service would be overkill
> ;-)...
>
> Ok, I'm not a fan of the LDAP-like filter syntax but it's workable,
> and except for the DefaultSlingScript which needs to take care of
> backwards compatibility the filters should be simple.
>
> -Bertrand
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Aug 7, 2013 at 10:09 AM, Felix Meschberger <fm...@adobe.com> wrote:
> ...In fact I would say, that BVPs without the property should just be used anywhere....
that might work - I was going to say that [1] for example makes no
sense in my health check context, but that provider is being careful
to not add anything if the "resource" binding is not available so
we're fine.
>> ...3. Provide a service to collect relevant BVPs when setting up
>> scripting, based on a set of context values.
>
> Since the selection is so easy with a service selection filter or target attribute on a @Reference annotation, such a service would be overkill ;-)...
Ok, I'm not a fan of the LDAP-like filter syntax but it's workable,
and except for the DefaultSlingScript which needs to take care of
backwards compatibility the filters should be simple.
-Bertrand
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Basically sounds good.
Am 07.08.2013 um 09:55 schrieb Bertrand Delacretaz:
> Here's my revised proposal based on this thread's discussions:
>
> 1. Add a "context" service property to our existing
> BindingValuesProvider (BVP) implementations, value="request". The
> context property can have multiple values.
This would be a service reference filter of
(|(context=request)(!(context=*)))
(I think)
>
> 2. Modify the scripting setup in DefaultSlingScript so that any BVP
> which has a "context" service property which doesn't include a
> "request" value is ignored. Maybe warn if a BVP with no "context"
> property is found, as we'd like people to add this property from now
> on.
When using the service reference filter (or target on the @Reference annotation) we don't really care. Not sure, whether we should really warn ...
In fact I would say, that BVPs without the property should just be used anywhere.
The problem is that BVP is a @ConsumerType service interface in the Sling API. We must take extreme care to change it or its semantics.
>
> 3. Provide a service to collect relevant BVPs when setting up
> scripting, based on a set of context values.
Since the selection is so easy with a service selection filter or target attribute on a @Reference annotation, such a service would be overkill ;-)
Regards
Felix
>
> -Bertrand
Re: Adding a "usage" service property to BindingsValuesProvider ?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Here's my revised proposal based on this thread's discussions:
1. Add a "context" service property to our existing
BindingValuesProvider (BVP) implementations, value="request". The
context property can have multiple values.
2. Modify the scripting setup in DefaultSlingScript so that any BVP
which has a "context" service property which doesn't include a
"request" value is ignored. Maybe warn if a BVP with no "context"
property is found, as we'd like people to add this property from now
on.
3. Provide a service to collect relevant BVPs when setting up
scripting, based on a set of context values.
-Bertrand