jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Propagation of Session auto refresh behaviour to e.g. UserManager
Date Tue, 06 Aug 2013 09:51:53 GMT
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 :-)


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

>On Tue, Aug 6, 2013 at 12:23 PM, Angela Schreiber <anchela@adobe.com>
>> 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
>> 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.
>Jukka Zitting

View raw message