After thinking a bit more about it I would propose the following a) Extend the ResourceResolver interface like outlined in https://github.com/apache/sling-org-apache-sling-api/pull/2 <https://github.com/apache/sling-org-apache-sling-api/pull/2> b) In ResourceResolverImpl reference a ResourceTypeInheritance service singleton which caches resource super types of all resources below /apps and /libs - this cache should be populated via resource traversal (that should be supported by all resource providers) - the cache should be invalidated via the ResourceChangeListener
That way the cache is an implementation detail and I would also explicitly mention in its javadoc that this is not supposed to be consumed except from within the Resource Resolver. The cache can even be located in the Resource Resolver bundle and its interface does not even need to be exported. WDYT? > On 12. Jan 2018, at 15:46, Konrad Windszus <[email protected]> wrote: > >> >> >> Resource resolver is short lived, so caching there doesn't provide that >> much value. You need something "global". > I see, so the cache must be bound to something else. The only thing which > comes to mind is the ResourceResolverFactory, but I would like to keep that > new method and the method getResourceSuperType in the same interface (because > one is just the inversion of the other). Any other idea except for a > completely new OSGi service? > >> >> Most clients of resource resolver do not care about resource types at >> all, so adding more stuff to that interface doesn't make it nicer for >> most use cases of resource resolver. >> >> A solution which is only limited to JCR is imho not a good idea and >> putting the burden on resource providers is as you point out too much >> effort and not necessary. Resource type inheritance is a cross cutting >> concern. > I cannot think any other solution than those two. > >> >> Regards >> >> Carsten >> >> >> Konrad Windszus wrote >>> Why do you want to separate it from the ResourceResolver interface? From a >>> consumer perspective this sound like the perfect fit. In the >>> ResourceResolveImpl we can then implement such a cache (but this would be >>> an implementation detail and not part of the API). >>> >>> I am thinking about a best effort approach like querying recursively with >>> SQL2. Of course this would only return results for the JCR Resource >>> Provider (but I think that is sufficient for 99% of the cases). >>> >>> Another approach would be to require every Resource Provider to provide >>> that information and I think this is too much of an effort for right now. >>> Later on we can easily extend/improve the implementation by extending the >>> Resource Provider interface. >>> WDYT? >>> >>>> On 12. Jan 2018, at 15:25, Carsten Ziegeler <[email protected]> wrote: >>>> >>>> I think some time ago we discussed a separate resource type mgmt service >>>> (which also could cache resource type resolution). >>>> >>>> Maybe now is a good time to think about it and introduce it? >>>> >>>> Regards >>>> >>>> Carsten >>>> >>>> >>>> Konrad Windszus wrote >>>>> Yes, exactly. >>>>> But if someone has a better idea on how to achieve that I am eager all >>>>> ears. >>>>> >>>>>> On 12. Jan 2018, at 15:19, Jason Bailey <[email protected]> wrote: >>>>>> >>>>>> So that I understand, this would benefit a scenario where you are >>>>>> searching for a specific resource type, and the search implementation >>>>>> would have to traverse up the resourceType hierarchy to determine if a >>>>>> specific type was of a type that you are looking for. >>>>>> >>>>>> One of the solutions for this, as you suggest, could be a pre-emptive >>>>>> determination of the derived types and then the search implementation >>>>>> could compare against that. >>>>>> >>>>>> Did I get that right? >>>>>> >>>>>> -----Original Message----- >>>>>> From: Konrad Windszus [mailto:[email protected]] >>>>>> Sent: Friday, January 12, 2018 5:46 AM >>>>>> To: [email protected] >>>>>> Subject: Re: Search for specific resource types >>>>>> >>>>>> EXTERNAL >>>>>> >>>>>> Ping, does anyone have any idea? >>>>>> >>>>>> I am thinking about introducing a new method to ResourceResolver which >>>>>> allows to return all derived resource types for a given resource type. >>>>>> That must internally rely on a search within /apps and /libs looking for >>>>>> resourceSuperType=<given type> recursively! >>>>>> >>>>>> Such a method could be used as a basis for the query to look for content >>>>>> of type "a" or a derived type. >>>>>> WDYT? >>>>>> >>>>>> Konrad >>>>>> >>>>>>> On 15. Dec 2017, at 16:59, Konrad Windszus <[email protected]> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> is there a simple way to search with Sling Resource API for resources >>>>>>> which have a certain resource type "a" or a resource type derived from >>>>>>> "a". >>>>>>> The resource type inheritance in Sling is a pretty powerful concept. I >>>>>>> am wondering how to properly support that when searching for content >>>>>>> which is either of resource type a directly or a derived resource type. >>>>>>> >>>>>>> I cannot really think of a JCR SQL2 or XPath expression which would >>>>>>> also cover derived resource types (without knowing them in advance). >>>>>>> Thanks for any pointers, >>>>>>> Konrad >>>>>> >>>>> >>>> -- >>>> Carsten Ziegeler >>>> Adobe Research Switzerland >>>> [email protected] >>> >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> [email protected] >
