Thanks for the quick fix, Juanjo. Once I update to the new Sling structure, I'll test it. Marc
On Mon, Feb 23, 2009 at 2:14 PM, Juan José Vázquez Delgado < juanjo.vazq...@gmail.com> wrote: > > You mean it's not supported with addAccessControlEntry()? At least > > AccessControlUtil.addEntry() offers a method to apply restrictions. I > guess > > it calls ACLTemplate.addEntry() (that implements > > JackrabbitAccessControlList) and there is a signature that accepts > > "isAllow". > > There are 2 methods in jackrabbit core (ACLTemplate) to deal with this: > > (1) public boolean addEntry(Principal principal, Privilege[] > privileges, boolean isAllow) and > > (2) public boolean addEntry(Principal principal, Privilege[] > privileges, boolean isAllow, Map restrictions) > > For the time being, Jackrabbit 1.5 only supports to invoke the first > one or the second one without restrictions (restrictions = null). > These features belong to jsr-283 specification (AKA JCR 2.0) [1] and > the Jackrabbit implemention is only a developer preview. > > > So if it is really not possible to apply restrictions, I suggest > > removing the isAllow parameter from AccessControlUtil.addEntry(). Though > I > > think there might be just a problem floating around the > > AccessControlUtil.addEntry(). > > In the other hand, we are using reflection to invoke > addEntry(Principal principal, Privilege[] privileges, boolean isAllow) > but this implemention has a bug. I have created an issue [2] to deal > with this problem. > > Please, follow the issue to know about their resolution. Sorry for the > problems. > > BR, > > Juanjo. > > [1] http://jcp.org/en/jsr/detail?id=283 > [2] https://issues.apache.org/jira/browse/SLING-867 >
