[
https://issues.apache.org/jira/browse/SLING-6165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15601197#comment-15601197
]
Radu Cotescu commented on SLING-6165:
-------------------------------------
Thanks for the quick review! Yes, I forgot to clean {{ThreadLocal}}. I guess we
can safely use the {{SlingRequestEvent}} for the request-bound resolvers since
the {{SlingServletResolver}} uses the same mechanism now:
https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L523
In fact I think we should switch the {{SlingServletResolver}} to use this new
{{ScriptingResourceResolverFactory}} that's now exposed for other bundles. We
could also provide a lazily instantiated resolver for services that are not
request-bound, but for the servlet resolver and most scripting engines that we
have in Sling we need the request-bound one.
There's no change for {{javax.scripting}} formally. Before my changes the
package exports were defined in the {{pom.xml}} file, but I've now switched the
bundle to {{package-info.java}} files
I have nothing against moving this "factory" somewhere else, but the service
user that it needs should be transparent and I think that it should be the
{{sling-scripting}} one. In retrospect I also don't see much benefit having the
second {{#getResourceResolver()}} method, except for already having it mapped
to the same service user.
> Expose a service for Sling Scripting that provides request-scoped Resource
> Resolvers for scripting dependencies
> ---------------------------------------------------------------------------------------------------------------
>
> Key: SLING-6165
> URL: https://issues.apache.org/jira/browse/SLING-6165
> Project: Sling
> Issue Type: New Feature
> Components: Scripting
> Reporter: Radu Cotescu
> Assignee: Radu Cotescu
> Fix For: Scripting Core 2.0.42, Scripting API 2.1.10
>
>
> A new Sling Scripting service ({{ScriptingResourceResolverFactory}}) should
> be implemented in order to provide access to request-based
> {{ResourceResolvers}} for solving script dependencies.
> The following two methods should be available:
> {noformat}
> /**
> * Provides a request-scoped {@link ResourceResolver} with only read access
> to the search paths. This resolver should be used for script
> * resolution in the context of the same request rendering process. The
> {@code ResourceResolver} should not be closed by consumers (calling
> * {@link ResourceResolver#close} doesn't do anything), since this service
> will handle the closing operation automatically. The
> * {@code ResourceResolver} will be shared between scripting dependencies
> that render parts of the response for the same request.
> */
> ResourceResolver getRequestScopedResourceResolver()
> /**
> * Provides a {@link ResourceResolver} with only read access to the search
> paths. Once you're done processing {@link Resource}s with this
> * {@code ResourceResolver} make sure to close it.
> */
> ResourceResolver getResourceResolver()
> {noformat}
> [sling-dev email
> thread|https://lists.apache.org/thread.html/db2a78249baf2d6234a4549a5aff8b5474256add9829f86ac78d1c56@%3Cdev.sling.apache.org%3E]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
