jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: TreeImpl vs ReadOnlyTree
Date Thu, 19 Jul 2012 08:57:12 GMT

On Thu, Jul 19, 2012 at 10:40 AM, Angela Schreiber <anchela@adobe.com> wrote:
> - what is the aim of the ReadOnlyTree?

As you noticed, it's meant for use by plugins that want to access a
raw NodeState through the Tree API without any internal layers
(security, etc.) in between. Ideally such a wrapper wouldn't be
needed, as it mixes levels of abstraction, which is why I didn't want
to spend too much time documenting it (I'm hoping to refactor it away

> - is my assumption correct or would it be required to enforce access
>   restrictions on the ReadOnlyTree as well?

You're correct.

> - if the ReadOnlyTree is meant to be an 'internal' implementation of
>   the Tree interface, can we really enforce that it cannot be abused?

Yes. As long as a client doesn't see the underlying NodeStates (or the
MicroKernel), it can't do anything useful with ReadOnlyTree.

> - i quickly checked if the NodeState interface was really just used
>   within oak-core and not exposed: however i found that there as least
>   one reference to the NodeState interface in oak-jcr (observation).

That should probably move to a plugin in oak-core.


Jukka Zitting

View raw message