[jira] [Commented] (SLING-4352) The ResourceResolver passed to SlingScripts should not be closeable
[
https://issues.apache.org/jira/browse/SLING-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936513#comment-14936513
]
Carsten Ziegeler commented on SLING-4352:
-
While trying to implement this I noticed that a proxy (or wrapper) is not
sufficient. We would need to wrap each and every resource returned as well.
Otherwise the real resource resolver leaks through any resource returned by it.
I'm wondering if all this is really worth the effort. For reference I've
attached a patch for creating the proxy (not sure if it's complete though)
> The ResourceResolver passed to SlingScripts should not be closeable
> ---
>
> Key: SLING-4352
> URL: https://issues.apache.org/jira/browse/SLING-4352
> Project: Sling
> Issue Type: Bug
> Components: Servlets
>Reporter: Radu Cotescu
>Assignee: Carsten Ziegeler
> Fix For: Servlets Resolver 2.3.8
>
>
> The {{SlingServletResolver}} uses an administrative resource resolver
> ({{sharedScriptResolver}}) for script resolution. This same resolver is
> passed to SlingScripts when a resource is adapted to a {{SlingScript}} in
> {{SlingServletResolver#findScript}} (see
> {{SlingScriptAdapterFactory#getAdapter}}).
> Since this resolver is made available to scripts in the {{ScriptContext}}
> (see the implementation of {{DefaultSlingScript#call}}), the resolver should
> be protected against accidental closing from downstream callers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4352) The ResourceResolver passed to SlingScripts should not be closeable
[
https://issues.apache.org/jira/browse/SLING-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934764#comment-14934764
]
Dirk Rudolph commented on SLING-4352:
-
What about adding a ResourceResolverWrapper to both API and servlet resolver
marking the second one as deprecated and switching to the API one when the
dependency to the API gets updated next time?
I'm not completely sure about the use of reflection in that use case and the
overhead it introduces for just replacing one method.
> The ResourceResolver passed to SlingScripts should not be closeable
> ---
>
> Key: SLING-4352
> URL: https://issues.apache.org/jira/browse/SLING-4352
> Project: Sling
> Issue Type: Bug
> Components: Servlets
>Reporter: Radu Cotescu
>Assignee: Carsten Ziegeler
> Fix For: Servlets Resolver 2.3.8
>
>
> The {{SlingServletResolver}} uses an administrative resource resolver
> ({{sharedScriptResolver}}) for script resolution. This same resolver is
> passed to SlingScripts when a resource is adapted to a {{SlingScript}} in
> {{SlingServletResolver#findScript}} (see
> {{SlingScriptAdapterFactory#getAdapter}}).
> Since this resolver is made available to scripts in the {{ScriptContext}}
> (see the implementation of {{DefaultSlingScript#call}}), the resolver should
> be protected against accidental closing from downstream callers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4352) The ResourceResolver passed to SlingScripts should not be closeable
[
https://issues.apache.org/jira/browse/SLING-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934968#comment-14934968
]
Carsten Ziegeler commented on SLING-4352:
-
I think nowadays the overhead of reflection/proxy are nearly not noticible, in
addition this resource resolver should only be used on first access of a
servlet (like for the jsp compilation), from that one it should not be used
anymore. So I think we can ignore performance considerations.
Even if we go with adding the wrapper to the servlet api as well, we can't get
rid of it. As soon as we would we are again tied to the latest Sling API. And
we don't really have a need for the wrapper in general.
> The ResourceResolver passed to SlingScripts should not be closeable
> ---
>
> Key: SLING-4352
> URL: https://issues.apache.org/jira/browse/SLING-4352
> Project: Sling
> Issue Type: Bug
> Components: Servlets
>Reporter: Radu Cotescu
>Assignee: Carsten Ziegeler
> Fix For: Servlets Resolver 2.3.8
>
>
> The {{SlingServletResolver}} uses an administrative resource resolver
> ({{sharedScriptResolver}}) for script resolution. This same resolver is
> passed to SlingScripts when a resource is adapted to a {{SlingScript}} in
> {{SlingServletResolver#findScript}} (see
> {{SlingScriptAdapterFactory#getAdapter}}).
> Since this resolver is made available to scripts in the {{ScriptContext}}
> (see the implementation of {{DefaultSlingScript#call}}), the resolver should
> be protected against accidental closing from downstream callers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4352) The ResourceResolver passed to SlingScripts should not be closeable
[
https://issues.apache.org/jira/browse/SLING-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934631#comment-14934631
]
Carsten Ziegeler commented on SLING-4352:
-
Yes we could do a wrapper and we've also discussed adding such a thing some
time ago and decided against it (can't remember the details). Now for this
case, if we would go that way, we would tie the servlet resolver to the latest
Sling API and it wouldn't work with the older api. Therefore with a proxy we
can make sure that it still runs with older api versions.
> The ResourceResolver passed to SlingScripts should not be closeable
> ---
>
> Key: SLING-4352
> URL: https://issues.apache.org/jira/browse/SLING-4352
> Project: Sling
> Issue Type: Bug
> Components: Servlets
>Reporter: Radu Cotescu
>Assignee: Carsten Ziegeler
> Fix For: Servlets Resolver 2.3.8
>
>
> The {{SlingServletResolver}} uses an administrative resource resolver
> ({{sharedScriptResolver}}) for script resolution. This same resolver is
> passed to SlingScripts when a resource is adapted to a {{SlingScript}} in
> {{SlingServletResolver#findScript}} (see
> {{SlingScriptAdapterFactory#getAdapter}}).
> Since this resolver is made available to scripts in the {{ScriptContext}}
> (see the implementation of {{DefaultSlingScript#call}}), the resolver should
> be protected against accidental closing from downstream callers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4352) The ResourceResolver passed to SlingScripts should not be closeable
[
https://issues.apache.org/jira/browse/SLING-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933592#comment-14933592
]
Carsten Ziegeler commented on SLING-4352:
-
We should create a dynamic proxy which simply ignores calls to close() and pass
this on.
A dynamic proxy allows us to run with any version of the resource resolver api
and avoids updating the servlet resolver bundle each time the resource resolver
api changes.
> The ResourceResolver passed to SlingScripts should not be closeable
> ---
>
> Key: SLING-4352
> URL: https://issues.apache.org/jira/browse/SLING-4352
> Project: Sling
> Issue Type: Bug
> Components: Servlets
>Reporter: Radu Cotescu
>Assignee: Carsten Ziegeler
> Fix For: Servlets Resolver 2.3.8
>
>
> The {{SlingServletResolver}} uses an administrative resource resolver
> ({{sharedScriptResolver}}) for script resolution. This same resolver is
> passed to SlingScripts when a resource is adapted to a {{SlingScript}} in
> {{SlingServletResolver#findScript}} (see
> {{SlingScriptAdapterFactory#getAdapter}}).
> Since this resolver is made available to scripts in the {{ScriptContext}}
> (see the implementation of {{DefaultSlingScript#call}}), the resolver should
> be protected against accidental closing from downstream callers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4352) The ResourceResolver passed to SlingScripts should not be closeable
[
https://issues.apache.org/jira/browse/SLING-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933895#comment-14933895
]
Dirk Rudolph commented on SLING-4352:
-
You could als expose an abstract ResourceResolverWrapper in the API which
implements the actual ResourceResolver interface with delegation. The
implementation would then only replace the close method. In that case both,
servlet resolver and resource resolver API are still decoupled but without
introducing reflection and without intercepting any method invocation.
And maybe ResourceResolverWrapper would be useful in other use-cases as well.
> The ResourceResolver passed to SlingScripts should not be closeable
> ---
>
> Key: SLING-4352
> URL: https://issues.apache.org/jira/browse/SLING-4352
> Project: Sling
> Issue Type: Bug
> Components: Servlets
>Reporter: Radu Cotescu
>Assignee: Carsten Ziegeler
> Fix For: Servlets Resolver 2.3.8
>
>
> The {{SlingServletResolver}} uses an administrative resource resolver
> ({{sharedScriptResolver}}) for script resolution. This same resolver is
> passed to SlingScripts when a resource is adapted to a {{SlingScript}} in
> {{SlingServletResolver#findScript}} (see
> {{SlingScriptAdapterFactory#getAdapter}}).
> Since this resolver is made available to scripts in the {{ScriptContext}}
> (see the implementation of {{DefaultSlingScript#call}}), the resolver should
> be protected against accidental closing from downstream callers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4352) The ResourceResolver passed to SlingScripts should not be closeable
[
https://issues.apache.org/jira/browse/SLING-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933272#comment-14933272
]
Dirk Rudolph commented on SLING-4352:
-
This is an urgent issue at least with AEM 6.1 base on Servlet Resolver 2.3.6.
It happens that when the internal Cache of the Servlet resolver is flushed and
multiple concurrent requests are handled by the same Servlet/Script the
perThreadResolver is reused in different Threads and causes a ISE within
ResourceResolver#checkClosed when the Requests that initially got the
ScriptResource has been finished but the perThreadResolver is still in the
ScriptContext of another Thread.
> The ResourceResolver passed to SlingScripts should not be closeable
> ---
>
> Key: SLING-4352
> URL: https://issues.apache.org/jira/browse/SLING-4352
> Project: Sling
> Issue Type: Bug
> Components: Servlets
>Reporter: Radu Cotescu
> Fix For: Servlets Resolver 2.3.8
>
>
> The {{SlingServletResolver}} uses an administrative resource resolver
> ({{sharedScriptResolver}}) for script resolution. This same resolver is
> passed to SlingScripts when a resource is adapted to a {{SlingScript}} in
> {{SlingServletResolver#findScript}} (see
> {{SlingScriptAdapterFactory#getAdapter}}).
> Since this resolver is made available to scripts in the {{ScriptContext}}
> (see the implementation of {{DefaultSlingScript#call}}), the resolver should
> be protected against accidental closing from downstream callers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-4352) The ResourceResolver passed to SlingScripts should not be closeable
[
https://issues.apache.org/jira/browse/SLING-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14680091#comment-14680091
]
Carsten Ziegeler commented on SLING-4352:
-
I think this is also true for the RR passed to SlingScript/ScriptContext in
general. So I have the feeling that we maybe should solve this in a general
solution in DefaultSlingScript.
The ResourceResolver passed to SlingScripts should not be closeable
---
Key: SLING-4352
URL: https://issues.apache.org/jira/browse/SLING-4352
Project: Sling
Issue Type: Bug
Components: Servlets
Reporter: Radu Cotescu
Fix For: Servlets Resolver 2.3.8
The {{SlingServletResolver}} uses an administrative resource resolver
({{sharedScriptResolver}}) for script resolution. This same resolver is
passed to SlingScripts when a resource is adapted to a {{SlingScript}} in
{{SlingServletResolver#findScript}} (see
{{SlingScriptAdapterFactory#getAdapter}}).
Since this resolver is made available to scripts in the {{ScriptContext}}
(see the implementation of {{DefaultSlingScript#call}}), the resolver should
be protected against accidental closing from downstream callers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
