[Sightly] provide access to the Script Resource Resolver in RenderContext

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Sightly] provide access to the Script Resource Resolver in RenderContext

Radu Cotescu-3
Hi,

There are cases when Sightly RuntimeExtensions might need to access the
repository. Since creating multiple ResourceResolvers is not a cheap
operation, especially with Jackrabbit, wouldn't it be better to enhance the
RenderContext to make it provide the ResourceResolver available in the
ScriptContext?

This ResourceResolver is already used by the Sightly engine for script
rendering, so IMO it could also be passed down to RuntimeExtensions:

final ResourceResolver scriptResourceResolver = (ResourceResolver)
scriptContext.getAttribute(SlingScriptConstants.ATTR_SCRIPT_RESOURCE_RESOLVER,
SlingScriptConstants.SLING_SCOPE); // line 78
of org.apache.sling.scripting.sightly.impl.engine.SightlyScriptEngine

WDYT?

Cheers,
Radu
Reply | Threaded
Open this post in threaded view
|

Re: [Sightly] provide access to the Script Resource Resolver in RenderContext

Felix Meschberger-3
Hi

I am a bit hesitant with shipping ResourceResolver instances around. But since this is for an extension of the scripting language, this might make sense. We just have to properly document that this is not the request processing ResourceResolver but the ServletResolver’s ResourceResolver which is only intended to be used for script resolution tasks.

Regards
Felix

> Am 22.01.2015 um 14:21 schrieb Radu Cotescu <[hidden email]>:
>
> Hi,
>
> There are cases when Sightly RuntimeExtensions might need to access the
> repository. Since creating multiple ResourceResolvers is not a cheap
> operation, especially with Jackrabbit, wouldn't it be better to enhance the
> RenderContext to make it provide the ResourceResolver available in the
> ScriptContext?
>
> This ResourceResolver is already used by the Sightly engine for script
> rendering, so IMO it could also be passed down to RuntimeExtensions:
>
> final ResourceResolver scriptResourceResolver = (ResourceResolver)
> scriptContext.getAttribute(SlingScriptConstants.ATTR_SCRIPT_RESOURCE_RESOLVER,
> SlingScriptConstants.SLING_SCOPE); // line 78
> of org.apache.sling.scripting.sightly.impl.engine.SightlyScriptEngine
>
> WDYT?
>
> Cheers,
> Radu

Reply | Threaded
Open this post in threaded view
|

RE: [Sightly] provide access to the Script Resource Resolver in RenderContext

Rob Ryan
I share Felix's concern. If the ServletResolver's resolver is passed around, please ensure it is a service user with minimal permissions required for ServletResolver's needs.

We do *not* want to allow a resolver passed around from the ServletResolver to be abused for accessing general content. If Slightly RuntimeExtensions need more access than the ServletResolver they should manage a resolver themselves.

Also, this sounds like premature optimization.

If ResourceResolver creation is slow the ROI on making it faster is likely significant as multi-thread usage of a session in Oak degrades performance rapidly.
-Rob


-----Original Message-----
From: Felix Meschberger [mailto:[hidden email]]
Sent: Friday, January 23, 2015 5:58 AM
To: [hidden email]
Subject: Re: [Sightly] provide access to the Script Resource Resolver in RenderContext

Hi

I am a bit hesitant with shipping ResourceResolver instances around. But since this is for an extension of the scripting language, this might make sense. We just have to properly document that this is not the request processing ResourceResolver but the ServletResolver’s ResourceResolver which is only intended to be used for script resolution tasks.

Regards
Felix

> Am 22.01.2015 um 14:21 schrieb Radu Cotescu <[hidden email]>:
>
> Hi,
>
> There are cases when Sightly RuntimeExtensions might need to access
> the repository. Since creating multiple ResourceResolvers is not a
> cheap operation, especially with Jackrabbit, wouldn't it be better to
> enhance the RenderContext to make it provide the ResourceResolver
> available in the ScriptContext?
>
> This ResourceResolver is already used by the Sightly engine for script
> rendering, so IMO it could also be passed down to RuntimeExtensions:
>
> final ResourceResolver scriptResourceResolver = (ResourceResolver)
> scriptContext.getAttribute(SlingScriptConstants.ATTR_SCRIPT_RESOURCE_R
> ESOLVER, SlingScriptConstants.SLING_SCOPE); // line 78 of
> org.apache.sling.scripting.sightly.impl.engine.SightlyScriptEngine
>
> WDYT?
>
> Cheers,
> Radu

Reply | Threaded
Open this post in threaded view
|

Re: [Sightly] provide access to the Script Resource Resolver in RenderContext

Felix Meschberger-3
Hi

> Am 23.01.2015 um 15:11 schrieb Rob Ryan <[hidden email]>:
>
> I share Felix's concern. If the ServletResolver's resolver is passed around, please ensure it is a service user with minimal permissions required for ServletResolver's needs.

That’s a good point: This resource resolver should really be limited to only have read-only access to the locations the ServletResolver is expected to read scripts from …

>
> We do *not* want to allow a resolver passed around from the ServletResolver to be abused for accessing general content. If Slightly RuntimeExtensions need more access than the ServletResolver they should manage a resolver themselves.
>
> Also, this sounds like premature optimization.
>
> If ResourceResolver creation is slow the ROI on making it faster is likely significant as multi-thread usage of a session in Oak degrades performance rapidly.

From some measurements I have done a few months back on Oak creating a session comes with quite some penalty.

Regards
Felix

> -Rob
>
>
> -----Original Message-----
> From: Felix Meschberger [mailto:[hidden email]]
> Sent: Friday, January 23, 2015 5:58 AM
> To: [hidden email]
> Subject: Re: [Sightly] provide access to the Script Resource Resolver in RenderContext
>
> Hi
>
> I am a bit hesitant with shipping ResourceResolver instances around. But since this is for an extension of the scripting language, this might make sense. We just have to properly document that this is not the request processing ResourceResolver but the ServletResolver’s ResourceResolver which is only intended to be used for script resolution tasks.
>
> Regards
> Felix
>
>> Am 22.01.2015 um 14:21 schrieb Radu Cotescu <[hidden email]>:
>>
>> Hi,
>>
>> There are cases when Sightly RuntimeExtensions might need to access
>> the repository. Since creating multiple ResourceResolvers is not a
>> cheap operation, especially with Jackrabbit, wouldn't it be better to
>> enhance the RenderContext to make it provide the ResourceResolver
>> available in the ScriptContext?
>>
>> This ResourceResolver is already used by the Sightly engine for script
>> rendering, so IMO it could also be passed down to RuntimeExtensions:
>>
>> final ResourceResolver scriptResourceResolver = (ResourceResolver)
>> scriptContext.getAttribute(SlingScriptConstants.ATTR_SCRIPT_RESOURCE_R
>> ESOLVER, SlingScriptConstants.SLING_SCOPE); // line 78 of
>> org.apache.sling.scripting.sightly.impl.engine.SightlyScriptEngine
>>
>> WDYT?
>>
>> Cheers,
>> Radu
>

Reply | Threaded
Open this post in threaded view
|

Re: [Sightly] provide access to the Script Resource Resolver in RenderContext

Radu Cotescu-2
In reply to this post by Rob Ryan
Hi Rob,

The RuntimeExtensions are meant to process the outcome of a Sightly
expression. If such an extension would need to perform some processing
based on component resolution it's fair to pass it the same resolver that
the ServletResolver used.

I'll document in the RenderContext that this resolver should only be used
for component resolution, explicitly specifying that for content resolution
the request's resolver (available from the RenderContext#getBindings)
should be used.

An extension can be called multiple times during the rendering of the same
page; if this extension would be called 20 times for the rendering of one
page and if the extension needs a resource resolver to handle its
processing, I'd *really* like to avoid creating 20 resource resolvers if I
could just use the ServletResolver RR, which is passed down anyways to
script engines, through the ScriptContext.

Regards,
Radu


On Fri, Jan 23, 2015 at 4:11 PM, Rob Ryan <[hidden email]> wrote:

> We do *not* want to allow a resolver passed around from the
> ServletResolver to be abused for accessing general content. If Slightly
> RuntimeExtensions need more access than the ServletResolver they should
> manage a resolver themselves.
>
> Also, this sounds like premature optimization.
>
> If ResourceResolver creation is slow the ROI on making it faster is likely
> significant as multi-thread usage of a session in Oak degrades performance
> rapidly.
>