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
