Hi > Am 23.01.2015 um 15:11 schrieb Rob Ryan <[email protected]>: > > 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:[email protected]] > Sent: Friday, January 23, 2015 5:58 AM > To: [email protected] > 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 <[email protected]>: >> >> 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 >
