You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Alexander Klimetschek <ak...@adobe.com> on 2014/04/24 21:23:09 UTC
ResourceResolver.clone(null) sharing same JCR session?
Hi,
I have a case where I need to open a new JCR session / resource resolver from an existing one for a task that runs in a separate thread. I am using ResourceResolver.clone(null) for that. Documentation gives the impression it is a new one (since you assume a 1:1 between resource resolver instance and JCR session in general). But it seems the same session is returned.
I can't debug the issue, but looking at the code of the JcrResourceProviderFactory [2] it seems that if the original AuthenticationInfo is based on a JCR session explicitly passed with JcrResourceConstants.AUTHENTICATION_INFO_SESSION, this one will be returned. And not cloned through impersonation to itself.
Would it be necessary to explicitly use USER_IMPERSONATION (using the current user) on the authInfo?
[1] http://sling.apache.org/apidocs/sling6/org/apache/sling/api/resource/ResourceResolver.html#clone(java.util.Map)
[2] http://svn.apache.org/repos/asf/sling/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrResourceProviderFactory.java
Cheers,
Alex
Re: ResourceResolver.clone(null) sharing same JCR session?
Posted by Alexander Klimetschek <ak...@adobe.com>.
I wanted to get some opinions on this first. Created https://issues.apache.org/jira/browse/SLING-3524
Cheers,
Alex
On 27.04.2014, at 04:43, Carsten Ziegeler <cz...@apache.org> wrote:
> Well, I'm just stating the docs, feel free to open an issue to get this
> changed.
>
> Thanks
> Carsten
>
>
> 2014-04-25 21:43 GMT+02:00 Alexander Klimetschek <ak...@adobe.com>:
>
>> On 25.04.2014, at 00:21, Carsten Ziegeler <cz...@apache.org> wrote:
>>
>>> The documentation of clone clearly states that if "null" is passed in:
>> "the
>>> same credential data is used as was used to create this instance." which
>> in
>>> turn means, if the initlal resolver was created based on a session, this
>>> one will share the session.
>>
>> There are a few problems with this:
>> - seeing the session object itself as "credential data" is unintuitive
>> - in my code, I have no idea what the original credential data was, so I
>> don't know what kind of credential data it was to make the right decision
>> - since sharing a JCR session is to be avoided at all times, the resource
>> resolver should prevent one from this
>>
>> Are there any cases where you want a cloned resolver to share the session?
>>
>>> So in your case, you have to create a new session and pass this into the
>>> clone method - or you can also call the resource resolver factory
>> directly.
>>
>> Which is A LOT of boilerplate given there already is a clone() method. It
>> is not so much if using the USER_IMPERSONATION, but still, clone(null)
>> would be great to reflect a session clone = impersonate itself.
>>
>> Cheers,
>> Alex
>>
>>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: ResourceResolver.clone(null) sharing same JCR session?
Posted by Carsten Ziegeler <cz...@apache.org>.
Well, I'm just stating the docs, feel free to open an issue to get this
changed.
Thanks
Carsten
2014-04-25 21:43 GMT+02:00 Alexander Klimetschek <ak...@adobe.com>:
> On 25.04.2014, at 00:21, Carsten Ziegeler <cz...@apache.org> wrote:
>
> > The documentation of clone clearly states that if "null" is passed in:
> "the
> > same credential data is used as was used to create this instance." which
> in
> > turn means, if the initlal resolver was created based on a session, this
> > one will share the session.
>
> There are a few problems with this:
> - seeing the session object itself as "credential data" is unintuitive
> - in my code, I have no idea what the original credential data was, so I
> don't know what kind of credential data it was to make the right decision
> - since sharing a JCR session is to be avoided at all times, the resource
> resolver should prevent one from this
>
> Are there any cases where you want a cloned resolver to share the session?
>
> > So in your case, you have to create a new session and pass this into the
> > clone method - or you can also call the resource resolver factory
> directly.
>
> Which is A LOT of boilerplate given there already is a clone() method. It
> is not so much if using the USER_IMPERSONATION, but still, clone(null)
> would be great to reflect a session clone = impersonate itself.
>
> Cheers,
> Alex
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: ResourceResolver.clone(null) sharing same JCR session?
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 25.04.2014, at 12:43, Alexander Klimetschek <ak...@adobe.com> wrote:
> Which is A LOT of boilerplate given there already is a clone() method. It is not so much if using the USER_IMPERSONATION
Using USER_IMPERSONATION like this
final ResourceResolver clonedResolver = resolver.clone(new HashMap<String, Object>() {{
put(ResourceResolverFactory.USER_IMPERSONATION, resolver.getUserID());
}});
does NOT work, as the JcrResourceProviderFactory tries to be clever and avoids self-impersonation [1]. It reuses the original session :(
[1] https://github.com/apache/sling/blob/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrResourceProviderFactory.java#L364
Cheers,
Alex
Re: ResourceResolver.clone(null) sharing same JCR session?
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 25.04.2014, at 00:21, Carsten Ziegeler <cz...@apache.org> wrote:
> The documentation of clone clearly states that if "null" is passed in: "the
> same credential data is used as was used to create this instance." which in
> turn means, if the initlal resolver was created based on a session, this
> one will share the session.
There are a few problems with this:
- seeing the session object itself as "credential data" is unintuitive
- in my code, I have no idea what the original credential data was, so I don't know what kind of credential data it was to make the right decision
- since sharing a JCR session is to be avoided at all times, the resource resolver should prevent one from this
Are there any cases where you want a cloned resolver to share the session?
> So in your case, you have to create a new session and pass this into the
> clone method - or you can also call the resource resolver factory directly.
Which is A LOT of boilerplate given there already is a clone() method. It is not so much if using the USER_IMPERSONATION, but still, clone(null) would be great to reflect a session clone = impersonate itself.
Cheers,
Alex
Re: ResourceResolver.clone(null) sharing same JCR session?
Posted by Carsten Ziegeler <cz...@apache.org>.
The documentation of clone clearly states that if "null" is passed in: "the
same credential data is used as was used to create this instance." which in
turn means, if the initlal resolver was created based on a session, this
one will share the session.
So in your case, you have to create a new session and pass this into the
clone method - or you can also call the resource resolver factory directly.
Regards
Carsten
2014-04-24 21:23 GMT+02:00 Alexander Klimetschek <ak...@adobe.com>:
> Hi,
>
> I have a case where I need to open a new JCR session / resource resolver
> from an existing one for a task that runs in a separate thread. I am using
> ResourceResolver.clone(null) for that. Documentation gives the impression
> it is a new one (since you assume a 1:1 between resource resolver instance
> and JCR session in general). But it seems the same session is returned.
>
> I can't debug the issue, but looking at the code of the
> JcrResourceProviderFactory [2] it seems that if the original
> AuthenticationInfo is based on a JCR session explicitly passed with
> JcrResourceConstants.AUTHENTICATION_INFO_SESSION, this one will be
> returned. And not cloned through impersonation to itself.
>
> Would it be necessary to explicitly use USER_IMPERSONATION (using the
> current user) on the authInfo?
>
> [1]
> http://sling.apache.org/apidocs/sling6/org/apache/sling/api/resource/ResourceResolver.html#clone(java.util.Map)
> [2]
> http://svn.apache.org/repos/asf/sling/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrResourceProviderFactory.java
>
> Cheers,
> Alex
--
Carsten Ziegeler
cziegeler@apache.org