Hi,
On 3/2/07, Stefan Guggisberg <[EMAIL PROTECTED]> wrote:
On 3/2/07, Jukka Zitting <[EMAIL PROTECTED]> 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
