sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Search for specific resource types
Date Sun, 14 Jan 2018 09:01:00 GMT
 I would like to get back to your use case, you mention this is search

Even with such a method, doing the search is tricky as we have this
strange setup of a resource optionally returning a resource super type.
For example:

If a resource returns A as the resource type and null as the resource
super type, this resource is of type A and all parent types of A.

However, if a resource returns A as the resource type and B as the
resource super type, this resource is of type A, B and all parent types
of B - but not the parent types of A.

If search is the use case, I believe that we should finally at something
like the search api I proposed a long time ago and then we could add a
predicate for this and code all the logic once in a general implementation.



Konrad Windszus wrote
> After thinking a bit more about it I would propose the following
> a) Extend the ResourceResolver interface like outlined in
> 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.
>> On 12. Jan 2018, at 15:46, Konrad Windszus <> 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
>>>> 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 <>
>>>>> 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 <>
>>>>>>> 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
>>>>>>> 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
>>>>>>> Did I get that right?
>>>>>>> -----Original Message-----
>>>>>>> From: Konrad Windszus [] 
>>>>>>> Sent: Friday, January 12, 2018 5:46 AM
>>>>>>> To:
>>>>>>> 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 <>
>>>>>>>> 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
>>> -- 
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
Carsten Ziegeler
Adobe Research Switzerland

View raw message