But you can use adaptTo to retrieve your cache via an adapter factory.
As Radu points out, those objects are cached/created once per Adaptable.
This binds the lifetime of your cache to the lifetime of the Adaptable
and you get what you need for free without any api additions.
Carsten
Am 15.10.2021 um 18:37 schrieb Jörg Hoh:
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
--
Carsten Ziegeler
Adobe
[email protected]
