Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of anchela@adobe.com designates
 64.18.1.237 as permitted sender)
From: Angela Schreiber <anchela@adobe.com>
To: "oak-dev@jackrabbit.apache.org" <oak-dev@jackrabbit.apache.org>
Date: Tue, 6 Aug 2013 10:51:53 +0100
Subject: Re: Propagation of Session auto refresh behaviour to e.g.
 UserManager
Thread-Topic: Propagation of Session auto refresh behaviour to e.g.
 UserManager
Thread-Index: Ac6SipUIsFXlqbwKR4+nviPJ43cp/g==
Message-ID: <CE26929D.5B1E%anchela@adobe.com>
In-Reply-To: 
 <CAOFYJNaDRvDKithZ_kQGqMs+Abwgo+6VaZ6WDaTn=rm-umd70A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.2.130206
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

hi jukka

we are talking about 2 different sessions. with one single session
everything works as expected.

regarding attaching to the SessionDelegate: i definitely disagree.
in contrast to the various plugins which are not really pluggable
the various mgr security related implementations must be
pluggable at runtime. therefore making the implementation depend
on the internal SessionDelegate is not an option.
in addition some of those classes are also used within the oak core
(validators, commit hooks and so forth). i really don't want to
add any dependency to oak-jcr nor the internals contained therein
to the various security related parts. i deliberately avoided it.
this wasn't a coincidence :-)

angela


On 8/6/13 11:42 AM, "Jukka Zitting" <jukka.zitting@gmail.com> wrote:

>Hi,
>
>On Tue, Aug 6, 2013 at 12:23 PM, Angela Schreiber <anchela@adobe.com>
>wrote:
>> but in this case as michael explained the setup is that one session
>> should be informed about modifications made by another session.
>
>Are we talking about two separate sessions (i.e. javax.jcr.Session
>instances) or a session and the UserManager associated with it?
>
>> this works for all operations that are 'attached' to the SessionDelegate
>> but the refresh doesn't work for those classes that are just associated
>> with the Root (such as e.g. the UserManager which btw. makes transient
>> modifications on the root associated with editing session. the
>>read-write
>> trick doesn't help here).
>
>It sounds to me as if the UserManager should also be attached to the
>SessionDelegate, and use the SessionOperation mechanism whenever
>accessing information bound to that session.
>
>BR,
>
>Jukka Zitting