Mike Müller wrote:
> Nobody seems to be willing to burn his finger on this topic,
> nevertheless I try to jump in the hot pot...
Hehe, thanks!
> If the following is given and we talk about the same request
>
> Resource a = resolver.getResource("/a/b");
> Resource b = resolver.getResource("/a/b");
>
> I would expect
> a.equals(b) = true
> but a == b does not have to be true (but could be)
>
> as of the JCR spec, even if in the same session between
> retrieving a and b "/a/b" is changed, both a and b have to
> reflect these changes.
Good point!
> In this case I think we're not allowed to make any assumptions
> about the returned instance, so I would expect also
>
> n1.equals(n2) = true
> n1 == n2 does not have to be true (but could be)
>
I see that I picked up a bad example here :) Now let's assume you
want to adapt the resource to a PersistableValueMap
PersistableValueMap p1 = resource.adaptTo(PersistableValueMap.class)
PersistableValueMap p2 = resource.adaptTo(PersistableValueMap.class)
p1 == p2? p1.equals(p2)?
> In the case of the JCR as backend (which maybe hasn't to be the case
> in the future if we introduce ResourceResolverFactoriy etc.) the
> JCR spec says
> "However, the state reflected by the object must at all times be
> consistent with any other Item object (associated with the same
> Session) representing the same actual item entity"
> That means that even if the resource resolver returns an other
> resource on the second call the first should return the same
> (changed) properties, which means a.equals(b) should return true
> even in this case.
>
> The question is here if we should specify this behavour for a
> resource resolver in sling or not.
Yepp, exactly :)
Thanks for your answer, Mike! Anyone else?
Regards
Carsten
--
Carsten Ziegeler
[email protected]
