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.
Regards
Felix
On 15.01.2010 14:14, Carsten Ziegeler wrote:
> Ok, thanks for all answers so far :)
>
> Bertrand Delacretaz wrote:
>> On Fri, Jan 15, 2010 at 1:15 PM, Alexander Klimetschek <[email protected]>
>> wrote:
>>> ...Note that ensuring a == b can make implementations very difficult, as
>>> you need to cache all the Resource instances you returned to the API
>>> client. And what about handling this across multiple threads?...
>>
>> Right, I wouldn't go that far.
>>
>> Java programmers are (or should be) used to rely on equals as opposed to ==
>>
> Yes, that's right :) Ok, so here are my thoughts so far. I'm more with
> Justin and would expect that during a request response cycle the same
> resource object is returned for the same path from the same resource
> resolver. But I never would compare them with == :)
>
> Implementing the caching here is easy (it would be a non synced cache
> which also improves performance in systems where a lot is happening
> during rendering).
>
> Now obviously I've started this thread with something in mind. I've seen
> apps developed on top of Sling with a lot of happening during a request
> and with a lot of using the adapter pattern. So it happens during a
> single request that a getResource() is called for the same path and then
> this resource is adapted to some business object.
>
> Of course as different calls to getResource end up with different
> resource objects, we end up with different business objects.
> Specifying everything like the jcr spec does is nice, but it keeps a
> high burden on the developer who implements resources and adaptables as
> you somehow have to take care that these different objects have the same
> state!
>
> So from an implementation pov it would be easier to return the same
> resource object and then return the same adaptable. This could be done
> by Sling transparently. I think this would make things easier and speed
> up performance.
>
> Now, unfortunately if we would only have a request response cycle this
> would be easily doable with simple caching etc.
>
> But we have background stuff and caching resources in a resource
> resolver that runs forever doesn't seem to be a good idea. However this
> could be solved as well.
>
> Carsten
