My initial reaction was basically what Mike wrote.
But the more I think about it, the more I'm on the fence about:
resolver.getResource("/a/b") == resolver.getResource("/a/b")
My first instinct was basically what Mike wrote, this can be true, but isn't
required to be so. But the more I think about it, I think this should always
be true. I don't have a explanation why... still working on that part.
It seems natural that r.adaptTo(Foo.class).equals(r.adaptTo(Foo.class)), but
this does seem like an implementation detail that Sling may or may not be
able to impose. JCR happens to require Node.equals() to do what is, IMHO,
the right thing, but requiring this on a different legacy API doesn't seem
feasible.
Justin
On Thu, Jan 14, 2010 at 9:41 AM, Carsten Ziegeler <[email protected]>wrote:
> 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]
>
