+1 Accept FileVault into Apache Jackrabbit
Michael
Hi,
On Tue, Aug 6, 2013 at 3:40 AM, Tobias Bocanegra tri...@apache.org wrote:
Please vote to approve this contribution.
[x] +1 Accept FileVault into Apache Jackrabbit
Great stuff, thanks!
BR,
Jukka Zitting
Please vote to approve this contribution.
[X] +1 Accept FileVault into Apache Jackrabbit
Regards
Marcel
+1
Thanks !
Regards,
Cédric
Le 06/08/2013 02:40, Tobias Bocanegra a écrit :
Jackrabbit has received a donation of Adobe's FileVault that we'd like
to have as part of the contribs. the process is tracked under JCR-3612
and the signed source code is available here:
tar:
hi michael
either we introduce the rootprovider or we create some sort of
refresh-listener behavior.
regards
angela
On 8/6/13 10:24 AM, Michael Dürig mdue...@apache.org wrote:
Hi,
With OAK-938 [1] Antonio uncovered another consequence of introducing
auto refreshing sessions [2]:
Acquiring a
On Mon, Aug 5, 2013 at 8:40 PM, Tobias Bocanegra tri...@apache.org wrote:
[x] +1 Accept FileVault into Apache Jackrabbit
Regards,
Justin
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 see
Hi,
On Tue, Aug 6, 2013 at 11:24 AM, Michael Dürig mdue...@apache.org 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
On 6.8.13 10:41, Jukka Zitting wrote:
Hi,
On Tue, Aug 6, 2013 at 11:24 AM, Michael Dürig mdue...@apache.org wrote:
We might have similar issues with other entities tied to a session like
PrincipalManager, VersionManager, ... Basically all (indirect) callers of
SessionDelegate#getRoot() are
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 mdue...@apache.org 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
On 6.8.13 11:33, Jukka Zitting wrote:
Hi,
On Tue, Aug 6, 2013 at 12:21 PM, Michael Dürig mdue...@apache.org 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()
Hi,
On Tue, Aug 6, 2013 at 12:23 PM, Angela Schreiber anch...@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
Hi,
On Tue, Aug 6, 2013 at 12:51 PM, Angela Schreiber anch...@adobe.com 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.
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.
-
15 matches
Mail list logo
