I thought about using adapTo() and the cache integrated in there.
Technically it could work, but it would require me to write a
AdapterFactory plus a matching "target" class, to which I can adapt to.
That's a lot of development overhead compared to a simple
resourceResolver.getPropertyMap().put("key", theObjectIWantToStore);
especially if this this class and the AdapterFactory are only used at this
place. If this would be a recurring pattern, I would make this much more
explicit. But I worked around this missing already a few times, and I never
found a pattern (besides that having such a map on the resource resolver
would have made it much easier.
Also when we think about resource handling, we could enhance the
implementation, that at the logout() of a ResourceResolver all closeable
objects stored in the map are closed, and that the map is cleared. So the
objects in this map are closely bound to the lifetime of the resource
resolver, making both accidental and intentional misuse harder.
WDYT?
Jörg
Am Do., 21. Okt. 2021 um 20:56 Uhr schrieb Julian Sedding <
[email protected]>:
> Hi Jörg
>
> You could wrap your ResourceResolver using a custom
> ResourceResolverWrapper that could hold your state. IIRC Sling's
> ResourceResolverWrapper does a "deep wrap", i.e. resources obtained
> from it are also wrapped and return the wrapped RR via their
> Resource#getResourceResolver() method.
>
> Inside your custom wrapper you can store whatever state you want, and
> you may clean it up once ResourceResolver#close() is called.
>
> Of course this requires you to be able to wrap the RR before calling
> the API in question.
>
> Regards
> Julian
>
> On Mon, Oct 18, 2021 at 2:09 PM Paul Bjorkstrand
> <[email protected]> wrote:
> >
> > My point stands, there is no API provided. The thread local cleaner that
> is
> > used, while used commonly in many applications (I am 99% sure I saw that
> > exact code or very similar in a SO while looking for such an API), is
> still
> > dependent on internal implementation details of thread locals
> > (non-public/inaccessible fields). This is no different than depending on
> > Unsafe. As you mentioned, it is much harder in later versions of Java
> > because implementation details are much more encapsulated.
> >
> > -Paul
> >
> >
> > On Mon, Oct 18, 2021 at 4:24 AM Robert Munteanu <[email protected]>
> wrote:
> >
> > > Hi,
> > >
> > > On Sun, 2021-10-17 at 14:26 -0500, Paul Bjorkstrand wrote:
> > > > As far as I understand, thread locals' storage is an implementation
> > > > detail
> > > > in the JVM. There isn't an API to clear all/arbitrary thread locals.
> > > > Thread
> > > > pools, or applications that use thread pools, need to provide hooks
> to
> > > > do
> > > > that, so that code can do its own cleanup. This is exactly what the
> > > > request listener that Carsten mentioned does.
> > >
> > > Sling's thread pool actually cleans up thread locals after execution
> > > [1]. It's not yet fixed for Java 17 though [2].
> > >
> > > [1]:
> > >
> > >
> https://github.com/apache/sling-org-apache-sling-commons-threads/blob/org.apache.sling.commons.threads-3.2.22/src/main/java/org/apache/sling/commons/threads/impl/ThreadPoolExecutorCleaningThreadLocals.java
> > > [2]: https://issues.apache.org/jira/browse/SLING-10831
> > >
> > > Thanks,
> > > Robert
> > >
>
--
Cheers,
Jörg Hoh,
https://cqdump.joerghoh.de
Twitter: @joerghoh
