Hi,
With OAK-938 [1] Antonio uncovered another consequence of introducing
auto refreshing sessions [2]:
Acquiring a UserManager from a auto refreshing session, that UserManager
instance would not "inherit" the auto refresh setting. That is, although
the session itself might after a while se
Hi,
On Tue, Aug 6, 2013 at 11:24 AM, Michael Dürig wrote:
> We might have similar issues with other entities tied to a session like
> PrincipalManager, VersionManager, ... Basically all (indirect) callers of
> SessionDelegate#getRoot() are suspect... and that's quite a list.
We sorted out a good
On 6.8.13 10:41, Jukka Zitting wrote:
Hi,
On Tue, Aug 6, 2013 at 11:24 AM, Michael Dürig wrote:
We might have similar issues with other entities tied to a session like
PrincipalManager, VersionManager, ... Basically all (indirect) callers of
SessionDelegate#getRoot() are suspect... and that'
hi jukka
IMO the approach in the namespaceregistry is something different:
in that case you have a different write-root that needs to make
sure that the root (and the editing session) gets updated once
the changes are persisted.
but in this case as michael explained the setup is that one session
Hi,
On Tue, Aug 6, 2013 at 12:21 PM, Michael Dürig wrote:
> On 6.8.13 10:41, Jukka Zitting wrote:
>> a) When making transient changes or reading information that can come
>> from an earlier repository snapshot, use sessionDelegate.getRoot() so
>> that you see the exact same state as the rest of t
On 6.8.13 11:33, Jukka Zitting wrote:
Hi,
On Tue, Aug 6, 2013 at 12:21 PM, Michael Dürig wrote:
On 6.8.13 10:41, Jukka Zitting wrote:
a) When making transient changes or reading information that can come
from an earlier repository snapshot, use sessionDelegate.getRoot() so
that you see the
Hi,
On Tue, Aug 6, 2013 at 12:36 PM, Michael Dürig wrote:
> There is no perform call in this case. That is the point of the whole story.
The way I see it, there *should* be a perform() call in this case.
BR,
Jukka Zitting
Hi,
On Tue, Aug 6, 2013 at 12:23 PM, Angela Schreiber 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
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
p
Hi,
On Tue, Aug 6, 2013 at 12:51 PM, Angela Schreiber wrote:
> 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
On 6.8.13 11:23, Angela Schreiber wrote:
let's discuss that in the call this afternoon.
Quick summary from that call:
- We need some way of backwards compatibility re. sessions as discussed
in OAK-803. Otherwise client code could break in very subtle ways
creating a support legacy.
- Pus
Hi,
On Tue, Aug 6, 2013 at 5:26 PM, Michael Dürig wrote:
> I'll start looking into implementing those extra Delegate classes on an as
> need basis.
Great, thanks!
Perhaps it's worth it to try out the briefly discussed idea of
implementing at least some of the required wrappers using reflection
12 matches
Mail list logo
