Hi Radu, not necessarily. My case at hand is something like this:
I have a API method, which takes a Resource to perform some checks on it. As part of these checks it adapts the Resource to the ResourceResolver, performs a search using this resource resolver and uses the results to do the checks on the passed resource. This method is called for a number of resources, which belong to the same resource resolver, and also the search is always the same and has the same search results. The idea is to run the query only once and and store the search result along with the resource resolver, so I can reuse it on subseqent invocations. I don't want to manage an external / dedicated global cache (security!) and I also cannot realistically change the method signature to pass an additional parameter (the cache). So in this case I don't want to cache the result of an adaptTo() call. Jörg Am Fr., 15. Okt. 2021 um 15:23 Uhr schrieb Radu Cotescu <[email protected]>: > Hi Jörg, > > Are those objects generated based on a ResourceResolver#adaptTo call? If > so, we should already have a built-in cache via SlingAdaptable [0]. > > Thanks, > Radu > > > On 13 Oct 2021, at 09:28, Jörg Hoh <[email protected]> > wrote: > > > > Hi Robert, > > > > Am Di., 12. Okt. 2021 um 09:35 Uhr schrieb Robert Munteanu < > > [email protected]>: > > > >> > >> > >> Is the basic need to only know when the resource resolver is going to > >> be closed in order to flush the cache? > >> > > > > That is not my concern at all. In that case I would require the value to > be > > a Closeable. But that would make it more complex to store simple objects, > > and it would also require to change the "close" methods all > implementations > > of the ResourceResolver interface. By just adding a default method > > "getTemporaryStorage()" we can avoid that. Of course this would mandate > > that these cached objects do not require an explicit close(). But the > only > > relevant cases I saw in the last years in the Sling world are > > ResourceResolvers and JCR Sessions. And I hope that you don't store other > > resourceResolvers in such a cache :-) > > > > The problem I want to solve is > > * store objects derived from a resource resolver along the resolver, > because > > * existing API and code, which is just passing in a resource resolver, > but > > not a "cache object". > > > > > > > >> > >> If that is the case we could expose a hook that notifies interested > >> parties about a ResourceResolver closing so they can flush the caches. > >> > >> The benefit would IMO be that we keep the API lean and allow creating > >> new bundles that implement the caching logic. > >> > > > > I just call it "cache" because I want to emphasize that I cannot rely on > > the presence of a key-value pair in that map. I don't think that we need > a > > very complex logic there by default. But if an implementation could > provide > > their own implementation of the default method returning a more adjusted. > > > > Jörg > > > > -- > > Cheers, > > Jörg Hoh, > > > > https://cqdump.joerghoh.de > > Twitter: @joerghoh > > -- Cheers, Jörg Hoh, https://cqdump.joerghoh.de Twitter: @joerghoh
