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_RESOLVER, > SlingScriptConstants.SLING_SCOPE); // line 78 > of org.apache.sling.scripting.sightly.impl.engine.SightlyScriptEngine > > WDYT? > > Cheers, > Radu
