Felix Meschberger wrote:
> Hi,
>
> I think equals should hold. == should not be required (and even less
> depended upon).
>
> Especially in long used ResourceResolver instances having to guarantee
> == will generate a memory hog sooner or later.
>
> I agree that we might build in some caching to the ResourceResolver, for
> example using an LRUMap or using WeakReferences for the GC to be able to
> clean up in times of low memory conditions.
>
> One thing, holds me back a bit: The Resource.getResourceMetadata is
> currently not completely defined. So one, could assume that
>
> resource.getResourceMetadata.put("xyz", "some data");
> "some data".equals(resource.getResourceMetadata.get(xyz"));
>
> If we wan to reuse Resource objects, this is dangerous .... There may be
> good reasons to have it, but it inherently makes the Resource non-thread
> safe for those background task resource resolvers.
>
Yes, that's true - everything would be fine and easily doable if we just had
resource resolvers during request processing :)
And yes, you're right that returning the same resource might require to
make the resource implementations thread safe - which does not seem to
be worth the effort I guess.
Now while I do not care that much about the resource, I care more about
the adaptables :) Invoking adaptTo twice on the same resource produces
two different objects - with different state - for some adaptions this
doesn't matter while it might does for others. One thing is the
different state, the other is that the adaption might be a heavy process
which you want to avoid to be done several times.
But as we don't have a clean up mechanism I guess this is not that
easily doable - and maybe we can defer this to the developers: if the
adaption takes some time they should take care to call adaptTo only once
and reuse the object.
Carsten
--
Carsten Ziegeler
[email protected]
