jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: svn commit: r512695 - in /jackrabbit/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons: AbstractItem.java AbstractNode.java AbstractProperty.java
Date Fri, 02 Mar 2007 10:49:00 GMT
Hi,

On 3/2/07, Stefan Guggisberg <stefan.guggisberg@gmail.com> wrote:
> On 3/2/07, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> > The only thing being protected is that the client will not have a
> > reference to a parent or ancestor node. I could always construct a
> > custom Node instance myself that would act just like such a  parent or
> > ancestor node would, throwing AccessControlExceptions for all attempts
> > to access property, child node, or metadata information. How would
> > such an instance differ from something that Item.getParent() or
> > Item.getAncestor() can't return?
>
> it wouldn't be compliant with the spec i guess ;)
>
> you wouldn't expect e.g. getPrimaryType() throwing an AccessDeniedExcpetion.

Fair enough. :-)

> the jsr 170 eg's rationale for the different behaviours of Session.getItem
> and Item.getParent wrt access control is as you assumed correctly:
>
> Session.getItem throws a PathNotFound if access is denied. Item.getParent
> otoh throws an AccessDeniedException in same situation since the existence
> of the requested item is evident. once you have e.g. a reference to a Node
> instance you should imo be able to retrieve its primary/mixin node types.

I guess that's valid. I'll add a note about this and an extra catch
for the AccessDeniedException in the abstract base classes I've been
drafting. I figure all reasonable subclasses would override those
default method implementations in any case, so this shouldn't be much
of a problem.

BR,

Jukka Zitting

Mime
View raw message