Ok, thanks for all answers so far :) Bertrand Delacretaz wrote: > On Fri, Jan 15, 2010 at 1:15 PM, Alexander Klimetschek <aklim...@day.com> > 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 -- Carsten Ziegeler cziege...@apache.org
