Hi, in the past years we added a lot of things here and there which over time resulted in cruft and sometimes hard to understand / debug problems. In order to have an even better framework which is easier to manage but also scales better for the things to come, we should get rid of this additional weigth.
One area which I think needs attention is the resource type handling. We started years back with the two methods on a resource, getting a resource type and optionally getting a resource super type. A little bit later this was extended with what we call today the resource type hierarchy: for a resource type a/b, a resource can be created in /libs/a/b with a resource super type property. This can be overlayed in /apps. (I'm assuming the default search paths here to keep it simple). While this sounds nice and and simple, it has several drawbacks (in no particular order): - it's hard to find out all the super types of a resource type - the resource resolver which reads the type hierarchy needs read access to the complete tree of /libs and /apps - just to find a few properties here and there. - two resources with the same resource type, might have different resource super types or even a complete different hierarchy. - there is no guarantee that the resource super type is static, which means two calls to find the super type for a resource type could result in different results, e.g. if the resource itself decides to return a different value, or if a resource decorator is used which does so. - for traversing the hierarchy we currently create an additional admin resource resolver per resource resolver - which is a huge overhead. Especially the last three points make improving the script resolution hard - if not impossible. Today the cache is using the resource type and resource super type of the resource as a key. However, given the above information it is easy to create a scenario where the cache returns a wrong script. Taking all these things into account, I think we should somehow start fresh with handling the resource type hierarchy and come to a better solution. In this first step, I think we should not care about compatibility. Once we have a great solution, we'll find a way on how to achieve this. My rough initial proposal would be: a) forget about Resource#getResourceSuperType. This method is ignored from now on (and deprecated) b) the resource hierarchy is not spread across /libs, /apps anymore c) we create a dedicated resource tree at /foo (I'm using /foo as a placeholder as I don't want to start an endless discussion now on what this path actually really is). We then have /foo/apps and /foo/libs. Underneath each of these resources, there is a flat list of resources. Each resource is associated with a resource type (through the name of the resource) and has two properties: resource type and resource super type. d) we create a service which has three methods // get the super type String getResourceSuperType(ResourceResolver resolver, String resourceType); // get an ordered list of all super types List<String> getResourceSuperTypes(ResourceResolver resolver, String resourceType) // check if resourceType is checkResourceType (either directly or one of the parents) boolean isResourceType(ResourceResolver resolver, String resourceType, String checkResourceType) We pass in the resource resolver to this service in order to pass in the search paths and the current user rights. This should allow us to continue with this service, even if we add tenant support at a later time or do some other checks. With this approach we have a) a clear resource type hierarchy which is stable. A resource of type A has always the same resource super types. (unless the hierarchy is changed of course) b) the service reading the hierarchy only needs read access in a single place c) it's easy to find out the hierarchy by looking into the resource tree d) the hierarchy can easily be cached in memory WDYT? Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
