Agreed, such an approach is definitely easier to use compared to all the
other options.
I think supporting Closeable is a nice feature which adds some
additional value.
If we just go with that single method addition, I'm ok with adding this
to the api. Returning a mutable map is way better than having the
set/get/remove methods as this also allows for computeIf etc
Regards
Carsten
Am 25.10.2021 um 11:38 schrieb Jörg Hoh:
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
--
Carsten Ziegeler
Adobe
[email protected]
