jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Troublesome dependencies introduce with OAK-1296
Date Tue, 04 Feb 2014 08:45:44 GMT
hi jukka

>Agreed. That's actually one of the drivers behind revision 1552379
>where I got rid of the JCR/Oak API dependencies of
>ReadOnlyNodeTypeManager. Ideally the Editors and Validators should be
>able to operate entirely on the NodeState level, though I think
>getting there will be difficult as ImmutableTrees are used in so many

yes... see also OAK-1381 for a similar discussion.
>> if we can't get rid of the TreeTypeProvider, we should consider moving
>> type provider elsewhere (some utility package) or make it accessible on
>> the API.
>In this particular case the reason for the TreeTypeProviderImpl
>dependency is that it's needed by ImmutableTree.getType(), which in
>turn is needed by CompiledPermissionImpl. I would actually try to get
>rid of ImmutableTree.getType() entirely, and instead track the type
>information in TreePermission based on the sequence of
>getChildPermission() calls. This way TreeTypeProvider would no longer
>be needed by ImmutableTree, and could easily be moved elsewhere.

yes... that might be better. i will give it a try.


View raw message