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: Duck typing in Oak
Date Wed, 24 Apr 2013 13:23:19 GMT

On Wed, Apr 24, 2013 at 3:59 PM, Angela Schreiber <anchela@adobe.com> wrote:
> as far as access control content is concerned that validation
> is IMO required due to the fact that without the mixin type
> on the parent the policy nodes would have a different declaring
> node type which IMO is part of the contract defined by the
> implementation... e.g. the repo could contain rep:policy nodes
> that are basically invalid.

I'm proposing that we move the checking of such constraints to the
type validator where we already have all relevant type information
readily available and where we can more easily optimize the constraint

Note that doing so would require us to extend the type validator with
some extra rules, like that content in reserved namespaces like
rep/internal can only occur when there's a built-in node type with a
matching named item definition. Such a rule would for example
guarantee that a rep:policy node can only occur when the parent is
rep:AccessControllable. Then there would be no need for the access
control validator to re-check that constraint and it could simply
treat all rep:policy nodes as containers of access control

> while taking a closer look at the permission evaluation i found
> that the commit hooks and validators get informed about all
> index updates which then get explicitly ignored by most
> validators/hooks, except for those dealing with index update.

The best way to address this is to move the index updates to be
performed only after all the other hooks/editors have been processed.
Unfortunately this doesn't cover all possible cases (like when an
entire subtree is copied around together with the contained hidden
content), so an additional piece of functionality, described below, is

> wouldn't it be possible to make it an explicit characteristic
> of the commit hooks if they want/need to deal with hidden
> trees and/or properties? IMO that would simplify the wast
> majority of all hooks and significantly reduce the amount of
> calls.

Indeed. The o.a.j.o.spi.commit.VisibleEditor wrapper class that's
explicitly designed for this purpose. The provider of an editor (which
is what most of our commit hooks would ideally become), that doesn't
need to care about hidden content, can use a VisibleEditor wrapper for
the root editor it returns to prevent any hidden content from showing
up to that editor. See the TypeEditorProvider class for an example of
that feature in action.


Jukka Zitting

View raw message