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" <[email protected]> wrote: >Hi, > >On Tue, Aug 6, 2013 at 12:23 PM, Angela Schreiber <[email protected]> >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
