incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <>
Subject Re: Page renaming weirdness
Date Sat, 17 Oct 2009 16:19:22 GMT
Janne, as of the current trunk build, we have three remaining failing
unit tests, and they seem to be Priha-related. Can you take a look at

First, since 0.5.4 (which I have not checked in to the JSPWiki trunk),
there seems to be a big honking memory leak somewhere. The build is
stopping earlier than expected, right around the time
JSPWikiMarkupParser executes, because of an OutOfMemoryError. 0.5.3
does not have this problem -- it runs like a champ all the way

Second, WITH 0.5.4, PageRenamerTest.testAttachmentChange() is failing
because of this message:

javax.jcr.InvalidItemStateException: Looks like this Node has been
removed by another session: /pages/Main/RenamedTest
	at org.priha.core.SessionProvider.checkSanity(
	at org.priha.core.SessionImpl.saveNodes(
	... 18 more

what SEEMS to be happening is that the item state of page node
RenamedTest is calling itself UPDATED, when perhaps it should say it
is MOVED? That is a guess.

Third, JSPWikiMarkupParser. testRenderingSpeed1() doesn't work under
0.5.3, probably for a reason having to do with the current build of

Testcase: testRenderingSpeed1 took 0.336 sec
	Caused an ERROR
Unable to add a page Unable to add a page
Caused by: javax.jcr.RepositoryException: TURNED OFF FOR NOW
	at org.priha.core.NodeImpl.addNode(
	at org.priha.core.NodeImpl.addNode(
	at org.priha.core.NodeImpl.addNode(

If we can fix these things, we should be able to get our unit test
pass rate to 100%. That would be awesome: it would be the first clean
build since the JCR stuff went in. As it stands right now, we are at
99.7% passing, which is still rather good. :)


On Thu, Oct 15, 2009 at 11:06 PM, Andrew Jaquith
<> wrote:
> Janne --
> I solved the problem. How I solved it probably relates to Priha, and
> it's worth explaining...
> My first attempt at setting up MemoryProvider wasn't successful, so I
> went back to the trial-and-error method with the standard setup until
> I isolated the problem. Here is how to reproduce the issue:
> - Tweak the Ant 'tests' target so that only
> and run, and in that order
> - Run 'ant clean tests'
> - Watch as ProviderManagerTest passes, and RecentChangesPluginTest fails
> The error message for RecentChangesPluginTest is thrown as part of a
> call that goes through ContentManager.getAllPages(). Here is what it
> says:
> javax.jcr.PathNotFoundException: The property metadata file was not
> found: /tmp/priha/fileprovider/workspaces/jspwiki/pages/Main/
> RecentChangesPluginTest does not create or use TestPage! But if I look
> in the source of PluginManager, I see that its setUp() method *does*
> create TestPage. I **also** see that tearDown() deletes "Testpage"
> (notice the wrong capitalization). When I change Testpage to TestPage
> in PluginManagerTest.tearDown(), RecentChangesPluginTest all of a
> sudden works fine.
> Now, that's kind of interesting. But what is *really* interesting is
> that RecentChangesPluginTest calls TestEngine.emptyRepository() in its
> tearDown() method. So the repository *should* be empty when the
> getAllPages() call executes.
> While I haven't tried to actually slap a debugger on the sequence down
> through Priha, my guess is that the EhCache is somehow failing to
> empty its cache.
> Anyhow, I thought I'd pass that on in case it helps.
> Andrew
> On Thu, Oct 15, 2009 at 3:32 PM, Janne Jalkanen
> <> wrote:
>> On Oct 15, 2009, at 21:01 , Andrew Jaquith wrote:
>>> So, can I go back to using Node.isNew()?
>> As of ten seconds ago :-)
>> (0.5.4 fixes this issue and adds an unit test to catch it.)
>>> Also: I have 8 unit tests that fail when run from the command line as
>>> part of the giant 1000+ test batch. But they run fine when run
>>> individually form the command line or inside Eclipse. I didn't see
>>> these prior to the latest Priha checkin.
>>> Any ideas? I'll try to isolate this, but it's proving to be extremely
>>> difficult so far.
>> My guess is that there's something which is not cleaned away properly.  You
>> could try to isolate it by switching to MemoryProvider and seeing if the
>> same error is still occurring.  If not (or you get a new exception) I can
>> have a better guess.
>> /Janne

View raw message