The problem was that CachingProvider used equals() to check whether a WikiPage was already in the cache. Unfortunately, since WikiPage used to be a container for attributes, so you could conceivably have two WikiPages with the same name and version, yet different attributes. This would cause dataloss in certain cases.
Now that mapping wikipages and attributes together is done by the back- end (and WikiPage itself is just a facade), I think your analysis is correct. The reason why the tests are failing is probably because the backend is quite liberal in creating new WikiPage objects as opposed to caching them (CachingProvider used to make sure that there's *usually* just one copy of a WikiPage around, but it could never be sure :-)
Always find any statement with "per se" very funny (it is a Finnish vulgarity ;-)
/Janne On 16 Mar 2009, at 06:13, Andrew Jaquith wrote:
In the 3.0 SVN, bunches of unit tests, like assertEquals( wikiPage, context.getPage() ), aren't working any more because JCRWikiPage.equals() doesn't really have a contract per se. It seems to me that two JCRWikiPages ought to be considered equal when their JCR paths and versions are the same. Note that the hashCode() method incorporates the m_name (WikiName) and version fields, so that would seem to imply that would be the correct test for equality. Janne, what do you think? -- Andrew
