hi
if i remember correctly the move case you mentioned below is
covered by the commit hook (see VersionablePathsTest). if there
are cases that don't work properly i would be glad if you could
provide add a test case (patch for the fix is optional).
as far as the location of the versionable path
Hi,
I noticed this looking at the query benchmarks and filed an issue for the
query engine (OAK-1132), but I think it's important to understand how this
works and if this is a bigger problem (OAK-1130 is possibly related).
If the SegmentRootBuilder#getNodeState creates a new revision (even
On Wed, Oct 30, 2013 at 7:25 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Wed, Oct 30, 2013 at 6:43 AM, Stefan Guggisberg
stefan.guggisb...@gmail.com wrote:
SNNP was introduced with JSR 283, mainly due to pressure from vendors with
legacy systems. we (day) were opposed since SNNP
On 2013-10-31 12:59, Stefan Guggisberg wrote:
On Wed, Oct 30, 2013 at 7:25 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Wed, Oct 30, 2013 at 6:43 AM, Stefan Guggisberg
stefan.guggisb...@gmail.com wrote:
SNNP was introduced with JSR 283, mainly due to pressure from vendors with
Hi,
On Thu, Oct 31, 2013 at 9:09 AM, Thomas Mueller muel...@adobe.com wrote:
Instead, I suggest we support (both?) weak and hard references as follows:
at the target node, add a hidden child node (called :references or so).
+1
Within this node, store all references as a tree.
With the
Hi,
i OTOH have seen a lot of JSON recently ;). SNNP breaks
the intuitive 1:1 JSON representation of repository content.
Related to this problem, if we need a round-trippable (*) JSON
representation:
1) To preserve the order of child nodes, we would need to use an array to
represent child
Hi,
On Thu, Oct 31, 2013 at 5:23 AM, Alex Parvulescu
alex.parvule...@gmail.com wrote:
If the SegmentRootBuilder#getNodeState creates a new revision (even though
looking at the apis this should not have side effects), this means that
any call basically invalidates all existing NodeBuilders and
hi,
On Thu, Oct 31, 2013 at 3:46 PM, Jukka Zitting jukka.zitt...@gmail.comwrote:
Hi,
On Thu, Oct 31, 2013 at 5:23 AM, Alex Parvulescu
alex.parvule...@gmail.com wrote:
If the SegmentRootBuilder#getNodeState creates a new revision (even
though
looking at the apis this should not have
Hi,
On Thu, Oct 31, 2013 at 11:54 AM, Alex Parvulescu
alex.parvule...@gmail.com wrote:
Fair enough, please take a look at [0], then [1]. this leads me to believe
that the base revision is increased on each call, so the other builders
would get invalidated (as mentioned on the #set method
The Buildbot has detected a new failure on builder oak-trunk while building ASF
Buildbot.
Full details are available at:
http://ci.apache.org/builders/oak-trunk/builds/3579
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: osiris_ubuntu
Build Reason: scheduler
Build Source Stamp:
i assume it's a tmp problem as i added a method in jackrabbit-api
to allow for multivalued restrictions in an access control entry.
the oak-parent points to 2.8-SNAPSHOT version of jackrabbit again.
so, it should be fixed once the latest version is picked up... let
me know if i missed something.
Build Update for apache/jackrabbit-oak
-
Build: #2518
Status: Broken
Duration: 285 seconds
Commit: 6e03596620459b237a2210f50655897b0f5d98c0 (trunk)
Author: Angela Schreiber
Message: OAK-51 Access Control Management (adjust code to implement API
modifications
Hi,
---
jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/accesscontrol/ImmutableACL.java
(original)
+++
jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/accesscontrol/ImmutableACL.java
Thu
this is public API and i don't want to break existing code. originally
i thought that restrictions will never be multivalued, otherwise i would
have defined the original extension differently (right away with an array).
on the other hand i am sure that a given implementation of the OAK
hi
this breaks existing code which IMHO is not an option.
kind regards
angela
On 10/31/13 8:29 PM, Tobias Bocanegra tri...@apache.org wrote:
sorry, I saw https://issues.apache.org/jira/browse/JCR-3641 too late.
I would object :-) and only use the following signature:
boolean
hi
but you don't gain anything when you store the path of the versionable
node with the version. the evaluation will be excuted against the
current persisted effective permissions present on the versionable
node referred to by that path not the state when it was 'private'.
IMO the most common
On Thu, Oct 31, 2013 at 3:27 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Thu, Oct 31, 2013 at 1:36 PM, Tobias Bocanegra tri...@apache.org wrote:
No, this is not the issue. The main problem of the versioning is, that
the versionable path is not recorded when creating a version.
On Thu, Oct 31, 2013 at 2:27 PM, Angela Schreiber anch...@adobe.com wrote:
hi
this breaks existing code which IMHO is not an option.
but the API change was just added yesterday for Jackrabbit 2.7.2
(JCR-3641) which is not released yet. So we still can change it.
Regards, Toby
kind regards
hi
what are you referring to?
the JackrabbitAccessControlList hasn't been touched for ages. the
addEntry method with the String-Value map has been there at least
since 2.0... changing that (and adjusting all calls that use that
method in jr-core) is definitely not what i want to do.
kind regards
but in:
http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/JackrabbitAccessControlList.java?r1=1537546r2=1537545pathrev=1537546
you added a new method to the API yesterday, which I think could be simplified.
Regards, Toby
On Thu, Oct
ah that one... this was today :-)
i added a new method as i didn't want to change the signature of
the method that already existed.. and which will now still work
the same way as they used to work. but maybe misread your post.
kind regards
angela
On 10/31/13 11:51 PM, Tobias Bocanegra
I see, the signature would be the same as only the generic type of the
map is different.
well, in this case we have to live with this :-)
regards, toby
On Thu, Oct 31, 2013 at 3:59 PM, Angela Schreiber anch...@adobe.com wrote:
ah that one... this was today :-)
i added a new method as i didn't
Build Update for apache/jackrabbit-oak
-
Build: #2520
Status: Fixed
Duration: 1619 seconds
Commit: 1e3cd60ac696273c205724f147805a13db2797b9 (trunk)
Author: Angela Schreiber
Message: OAK-527: permissions (wip)
git-svn-id:
Build Update for apache/jackrabbit-oak
-
Build: #2521
Status: Broken
Duration: 425 seconds
Commit: 6126347dd8554dd55634c870835e5f41f14f9eb7 (trunk)
Author: Tobias Bocanegra
Message: OAK-1138 Implement global per principal permission entry cache (wip)
The Buildbot has detected a restored build on builder oak-trunk while building
ASF Buildbot.
Full details are available at:
http://ci.apache.org/builders/oak-trunk/builds/3582
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: osiris_ubuntu
Build Reason: scheduler
Build Source
Hi,
I debugged a simple call like:
session.getProperty(/a/b/foo).getString();
and was really astonished how many path conversion, checking,
manipulation, tree/parent/child access operations are performed. not
only in access control, but everywhere. it looks like most of the
time, oak is busy
26 matches
Mail list logo
