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 >places.
yes... see also OAK-1381 for a similar discussion. > >> if we can't get rid of the TreeTypeProvider, we should consider moving >>the >> 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. regards angela
