[jira] [Commented] (SLING-3524) ResourceResolver.clone(null) should not share the same JCR session

["Csaba Varga (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16458477#comment-16458477 ] 

Csaba Varga commented on SLING-3524:
------------------------------------

I believe the problem is really about the statefulness of the authentication info. The clone() method assumes that none of the authentication info has any state, so just copying the references into a new map will give you a suitable new authentication info. This works well most of the time when you authenticate using strings, but breaks down with a JCR session object because it's _very_ stateful.

I'm working on a proposed patch that lets individual resource providers work around this limitation by letting them distinguish a clone operation from a regular login. In case of clone, stateful things like JCR sessions can be properly cloned to avoid any inadvertent shared state between the old and new resolvers. Providers that don't use stateful objects in their login info can just keep working without any changes.

> ResourceResolver.clone(null) should not share the same JCR session
> ------------------------------------------------------------------
>
>                 Key: SLING-3524
>                 URL: https://issues.apache.org/jira/browse/SLING-3524
>             Project: Sling
>          Issue Type: Improvement
>          Components: JCR, ResourceResolver
>    Affects Versions: Resource Resolver 1.0.6
>            Reporter: Alexander Klimetschek
>            Priority: Major
>
> {{ResourceResolver.clone()}} will reuse the same JCR session in case it was created by passing an existing session using {{JcrResourceConstants.AUTHENTICATION_INFO_SESSION}}. If you need a clone of the resource resolver to pass into a new, separate thread, and use {{ResourceResolver.clone(null)}}, you will actually share the session, but this is not obvious. The problem is that a JCR session cannot be shared across threads.
> The javadocs of clone() say "the same credential data is used as was used to create this instance".
> 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
> A solution would be if a plain {{ResourceResolver.clone(null)}} would return a session that impersonated itself, abstracting this from the resource resolver user. Additionally, it might be worth looking that clone always returns a new session, unless specifically stated.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)