You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Andrew Jaquith <an...@gmail.com> on 2009/10/12 06:48:06 UTC
Page renaming weirdness
Janne, I'm digging into more bugs...
The page-renamer tests haven't worked for a while. I think I know why.
ContentManager.renamePage(WikiContext, fromPage, toPage) has a bug.
Specifically, after this code executes:
getCurrentSession().move( getJCRPath( fromPage ),
getJCRPath( toPage ) );
getCurrentSession().save();
...fromPage is still accessible after this point. I.e.,
engine.getPage(fromPage) returns a valid page. Moreover, it shares the
same JCR UUID as the toPage. That would suggest that something isn't
getting cleaned up properly inside of Priha SessionImpl.move().
Of the 18 failing PageRenamerTest tests, fixing this bug would
probably get rid of 15 of them.
Thoughts?
Andrew
Re: Page renaming weirdness
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
Hm... That should be an easy-peasy fix. I thought I already cleaned
those all away...
/Janne
On Oct 13, 2009, at 06:22 , Andrew Jaquith wrote:
> Yeah, unfortunately 0.5.2 is even worse than 0.5.0. 39 failures, 57
> errors.
>
> That said, MANY of them seem to be IllegalStateExceptions related to
> dates, e.g.,:
>
> java.lang.IllegalStateException
> at org.priha.core.values.ValueImpl.checkValue(ValueImpl.java:63)
> at
> org
> .priha.core.values.CalendarValueImpl.getDate(CalendarValueImpl.java:
> 101)
> at
> org
> .priha
> .core.values.ValueFactoryImpl.createValue(ValueFactoryImpl.java:71)
> at
> org
> .priha.core.values.ValueFactoryImpl.cloneValue(ValueFactoryImpl.java:
> 337)
> at org.priha.providers.ValueContainer.deepClone(ValueContainer.java:
> 144)
> at org.priha.core.PropertyImpl.getValue(PropertyImpl.java:188)
> at org.priha.core.PropertyImpl.getValue(PropertyImpl.java:40)
> at
> org
> .apache
> .wiki.content.ContentManager.copyProperties(ContentManager.java:428)
> at
> org.apache.wiki.content.ContentManager.checkin(ContentManager.java:
> 392)
> at org.apache.wiki.content.ContentManager.save(ContentManager.java:
> 465)
> at
> org
> .apache
> .wiki
> .parser
> .JSPWikiMarkupParser.handleAccessRule(JSPWikiMarkupParser.java:1417)
> at
> org
> .apache
> .wiki
> .parser
> .JSPWikiMarkupParser.handleHyperlinks(JSPWikiMarkupParser.java:1499)
> at
> org
> .apache
> .wiki
> .parser
> .JSPWikiMarkupParser.handleOpenbracket(JSPWikiMarkupParser.java:2320)
> at
> org
> .apache
> .wiki.parser.JSPWikiMarkupParser.parseToken(JSPWikiMarkupParser.java:
> 2899)
> at
> org
> .apache
> .wiki.parser.JSPWikiMarkupParser.fillBuffer(JSPWikiMarkupParser.java:
> 2695)
> at
> org
> .apache
> .wiki.parser.JSPWikiMarkupParser.parse(JSPWikiMarkupParser.java:2971)
> at
> org
> .apache
> .wiki
> .render.RenderingManager.getRenderedDocument(RenderingManager.java:
> 247)
> at
> org
> .apache.wiki.render.RenderingManager.getHTML(RenderingManager.java:
> 323)
> at org.apache.wiki.WikiEngine.textToHTML(WikiEngine.java:1543)
> at org.apache.wiki.content.ContentManager
> $SaveWikiPageTask.execute(ContentManager.java:1267)
> at
> org.apache.wiki.workflow.Workflow.processCurrentStep(Workflow.java:
> 766)
> at org.apache.wiki.workflow.Workflow.start(Workflow.java:681)
> at
> org.apache.wiki.workflow.WorkflowManager.start(WorkflowManager.java:
> 82)
> at org.apache.wiki.WikiEngine.saveText(WikiEngine.java:1775)
> at org.apache.wiki.TestEngine.saveText(TestEngine.java:379)
> at
> org
> .apache
> .wiki
> .auth
> .AuthorizationManagerTest
> .testPrincipalAcl(AuthorizationManagerTest.java:466)
>
>
> The file-renaming bugs seem to have been partly fixed, although there
> are still errors (might be in the calling code, though).
>
> Andrew
>
> On Mon, Oct 12, 2009 at 9:42 AM, Harry Metske <ha...@gmail.com>
> wrote:
>> I almost checked in that priha version yesterday :-)
>> Should I wait, or commit that one in ?
>>
>> I kept some test-stats BTW:
>> http://people.apache.org/~metskem/tests/jspwiki-testresult.html
>> (you can see the good results from Andrew's work the last few days)
>>
>>
>> regards,
>> Harry
>>
>> 2009/10/12 Janne Jalkanen <Ja...@ecyrd.com>
>>
>>>
>>> Yup, this is a known problem in 0.3.2... Should be fixed in the
>>> current
>>> trunk.
>>>
>>> /Janne
>>>
>>>
>>> On Oct 12, 2009, at 07:48 , Andrew Jaquith wrote:
>>>
>>> Janne, I'm digging into more bugs...
>>>>
>>>> The page-renamer tests haven't worked for a while. I think I know
>>>> why.
>>>>
>>>> ContentManager.renamePage(WikiContext, fromPage, toPage) has a bug.
>>>> Specifically, after this code executes:
>>>>
>>>> getCurrentSession().move( getJCRPath( fromPage ),
>>>> getJCRPath( toPage ) );
>>>> getCurrentSession().save();
>>>>
>>>> ...fromPage is still accessible after this point. I.e.,
>>>> engine.getPage(fromPage) returns a valid page. Moreover, it shares
>>>> the
>>>> same JCR UUID as the toPage. That would suggest that something
>>>> isn't
>>>> getting cleaned up properly inside of Priha SessionImpl.move().
>>>>
>>>> Of the 18 failing PageRenamerTest tests, fixing this bug would
>>>> probably get rid of 15 of them.
>>>>
>>>> Thoughts?
>>>>
>>>> Andrew
>>>>
>>>
>>>
>>
Re: Page renaming weirdness
Posted by Andrew Jaquith <an...@gmail.com>.
Fixed item 3. The translate() method in the JSPWikiMarkupParserTest
was simply creating nodes and not saving them, relying on pageExists()
to tell it if they had been created. But in 3.0 you can create a page
without saving it -- different than 2.x, where creating automatically
means the page is persisted. Forcing the page-save before the
rendering speed test fixed the problem.
Anyway, it was a bug in the test code, not the core code. All good!
Andrew
On Sat, Oct 17, 2009 at 5:01 PM, Andrew Jaquith
<an...@gmail.com> wrote:
>> I'm currently working on moves (the SNS support is really hard to do without
>> screwing everything); I have something new on the hard drive already which
>> may be fixing this.
>
> Excellent. I'll cool my jets on these until something new hits the Priha trunk.
>
>> This suggests a serious bug in JSPWiki, which is creating a new page *by the
>> same name* as an existing page. Since JSPWiki currently is using
>> "nt:unstructured" as the page type, Priha will happily allow these so-called
>> same-name-siblings - as specified by JCR spec.
>>
>> This functionality was turned off in 0.5.3, but it's enabled again in trunk.
>> However, in this case the test will pass but JSPWiki will not work
>> correctly.
>>
>> I think we should either switch the node type, or add an assertion for pages
>> which already exist.
>
> Hmm. I haven't switched back the isNew() stuff in ContentManager just
> yet. I'll try that first. If it doesn't fix the problem, I'll add some
> existence-checking code into addPage().
>
> Andrew
>
Re: Page renaming weirdness
Posted by Andrew Jaquith <an...@gmail.com>.
> I'm currently working on moves (the SNS support is really hard to do without
> screwing everything); I have something new on the hard drive already which
> may be fixing this.
Excellent. I'll cool my jets on these until something new hits the Priha trunk.
> This suggests a serious bug in JSPWiki, which is creating a new page *by the
> same name* as an existing page. Since JSPWiki currently is using
> "nt:unstructured" as the page type, Priha will happily allow these so-called
> same-name-siblings - as specified by JCR spec.
>
> This functionality was turned off in 0.5.3, but it's enabled again in trunk.
> However, in this case the test will pass but JSPWiki will not work
> correctly.
>
> I think we should either switch the node type, or add an assertion for pages
> which already exist.
Hmm. I haven't switched back the isNew() stuff in ContentManager just
yet. I'll try that first. If it doesn't fix the problem, I'll add some
existence-checking code into addPage().
Andrew
Re: Page renaming weirdness
Posted by Janne Jalkanen <ja...@ecyrd.com>.
> 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
> through.
I'll check this... I have a feeling it's related to the other bugs.
> 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
I'm currently working on moves (the SNS support is really hard to do
without screwing everything); I have something new on the hard drive
already which may be fixing this.
> 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.
No, that's ok. 0.5.x has a completely new way of storing the session-
specific changes, so getState() reflects the *latest* state. Which may
change if there are e.g. Nodes added or Properties changed.
> Third, JSPWikiMarkupParser. testRenderingSpeed1() doesn't work under
> 0.5.3, probably for a reason having to do with the current build of
> Priha.
>
> Testcase: testRenderingSpeed1 took 0.336 sec
> Caused an ERROR
> Unable to add a page
> org.apache.wiki.providers.ProviderException: Unable to add a page
> at
> org.apache.wiki.content.ContentManager.addPage(ContentManager.java:
> 1501)
> at
> org.apache.wiki.content.ContentManager.addPage(ContentManager.java:
> 1469)
> at org.apache.wiki.WikiEngine.createPage(WikiEngine.java:1882)
> at
> org
> .apache
> .wiki
> .parser
> .JSPWikiMarkupParserTest.translate(JSPWikiMarkupParserTest.java:101)
> at
> org
> .apache
> .wiki
> .parser
> .JSPWikiMarkupParserTest
> .testRenderingSpeed1(JSPWikiMarkupParserTest.java:2333)
> Caused by: javax.jcr.RepositoryException: TURNED OFF FOR NOW
This suggests a serious bug in JSPWiki, which is creating a new page
*by the same name* as an existing page. Since JSPWiki currently is
using "nt:unstructured" as the page type, Priha will happily allow
these so-called same-name-siblings - as specified by JCR spec.
This functionality was turned off in 0.5.3, but it's enabled again in
trunk. However, in this case the test will pass but JSPWiki will not
work correctly.
I think we should either switch the node type, or add an assertion for
pages which already exist.
/Janne
Re: Page renaming weirdness
Posted by Andrew Jaquith <an...@gmail.com>.
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
these?
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
through.
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(SessionProvider.java:621)
at org.priha.core.SessionProvider.save(SessionProvider.java:345)
at org.priha.core.SessionImpl.saveNodes(SessionImpl.java:499)
at org.priha.core.SessionImpl.save(SessionImpl.java:484)
at org.apache.wiki.content.ContentManager.renamePage(ContentManager.java:1362)
... 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
Priha.
Testcase: testRenderingSpeed1 took 0.336 sec
Caused an ERROR
Unable to add a page
org.apache.wiki.providers.ProviderException: Unable to add a page
at org.apache.wiki.content.ContentManager.addPage(ContentManager.java:1501)
at org.apache.wiki.content.ContentManager.addPage(ContentManager.java:1469)
at org.apache.wiki.WikiEngine.createPage(WikiEngine.java:1882)
at org.apache.wiki.parser.JSPWikiMarkupParserTest.translate(JSPWikiMarkupParserTest.java:101)
at org.apache.wiki.parser.JSPWikiMarkupParserTest.testRenderingSpeed1(JSPWikiMarkupParserTest.java:2333)
Caused by: javax.jcr.RepositoryException: TURNED OFF FOR NOW
at org.priha.core.NodeImpl.addNode(NodeImpl.java:259)
at org.priha.core.NodeImpl.addNode(NodeImpl.java:160)
at org.priha.core.NodeImpl.addNode(NodeImpl.java:64)
at org.apache.wiki.content.ContentManager.addPage(ContentManager.java:1490)
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. :)
Andrew
On Thu, Oct 15, 2009 at 11:06 PM, Andrew Jaquith
<an...@gmail.com> 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 ProviderManagerTest.java
> and RecentChangesPluginTest.java 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/TestPage.info
>
> 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
> <Ja...@ecyrd.com> 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
>>
>
Re: Page renaming weirdness
Posted by Andrew Jaquith <an...@gmail.com>.
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 ProviderManagerTest.java
and RecentChangesPluginTest.java 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/TestPage.info
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
<Ja...@ecyrd.com> 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
>
Re: Page renaming weirdness
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
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
Re: Page renaming weirdness
Posted by Andrew Jaquith <an...@gmail.com>.
So, can I go back to using Node.isNew()?
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.
Andrew
Testsuite: org.apache.wiki.plugin.ReferredPagesPluginTest
Tests run: 4, Failures: 0, Errors: 4, Time elapsed: 1.578 sec
------------- Standard Output ---------------
LOC = Node[jspwiki:/], check=
LOC = Node[jspwiki:/], check=pages
XXX
LOC = Node[jspwiki:/pages], check=null
LOC = Node[jspwiki:/pages/Main], check=null
LOC = Node[jspwiki:/], check=
LOC = Node[jspwiki:/], check=pages
XXX
LOC = Node[jspwiki:/pages], check=null
LOC = Node[jspwiki:/pages/Main], check=null
LOC = Node[jspwiki:/], check=
LOC = Node[jspwiki:/], check=pages
XXX
LOC = Node[jspwiki:/pages], check=null
LOC = Node[jspwiki:/pages/Main], check=null
LOC = Node[jspwiki:/], check=
LOC = Node[jspwiki:/], check=pages
XXX
LOC = Node[jspwiki:/pages], check=null
LOC = Node[jspwiki:/pages/Main], check=null
------------- ---------------- ---------------
------------- Standard Error -----------------
javax.jcr.PathNotFoundException: The property metadata file was not
found: /tmp/priha/fileprovider/workspaces/jspwiki/pages/Main/TestPage.info
at org.priha.providers.FileProvider.getPropertyInfo(FileProvider.java:785)
at org.priha.providers.FileProvider.getPropertyValue(FileProvider.java:811)
at org.priha.providers.EhCachingProvider.getPropertyValue(EhCachingProvider.java:312)
at org.priha.core.ProviderManager.getPropertyValue(ProviderManager.java:260)
at org.priha.core.ProviderManager.loadProperty(ProviderManager.java:393)
at org.priha.core.ProviderManager.getItem(ProviderManager.java:488)
at org.priha.core.SessionProvider.getItem(SessionProvider.java:129)
at org.priha.core.SessionImpl.getItem(SessionImpl.java:225)
at org.priha.util.LazyNodeIteratorImpl.nextNode(LazyNodeIteratorImpl.java:30)
at org.priha.util.LazyNodeIteratorImpl.nextNode(LazyNodeIteratorImpl.java:14)
at org.priha.query.SimpleQueryProvider.visit(SimpleQueryProvider.java:568)
at org.priha.query.aqt.LocationStepQueryNode.accept(LocationStepQueryNode.java:163)
at org.priha.query.SimpleQueryProvider.visit(SimpleQueryProvider.java:144)
at org.priha.query.aqt.PathQueryNode.accept(PathQueryNode.java:72)
at org.priha.query.aqt.TraversingQueryNodeVisitor.visit(TraversingQueryNodeVisitor.java:38)
at org.priha.query.SimpleQueryProvider.query(SimpleQueryProvider.java:34)
at org.priha.query.QueryImpl.execute(QueryImpl.java:41)
at org.apache.wiki.content.ContentManager.getAllPages(ContentManager.java:582)
at org.apache.wiki.TestEngine.emptyRepository(TestEngine.java:218)
at org.apache.wiki.plugin.ReferredPagesPluginTest.tearDown(ReferredPagesPluginTest.java:66)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:421)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:912)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743)
On Thu, Oct 15, 2009 at 1:09 PM, Janne Jalkanen
<Ja...@ecyrd.com> wrote:
>> FYI, a subtle JCR point that I discovered while pounding out bugs: there's
>> no easy way to figure out whether a Node exists on disk.
>>
>> You'd think Node.isNew() would work, but if you create a node then add a
>> mixin (as we do with createPage()), its status changes to UPDATED, even
>> before calling save().
>
> This is correct and you just stumbled upon a Priha bug which is not caught
> by the TCK :-). isNew() works as you thought it should work.
>
> /Janne
>
Re: Page renaming weirdness
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> FYI, a subtle JCR point that I discovered while pounding out bugs:
> there's no easy way to figure out whether a Node exists on disk.
>
> You'd think Node.isNew() would work, but if you create a node then
> add a mixin (as we do with createPage()), its status changes to
> UPDATED, even before calling save().
This is correct and you just stumbled upon a Priha bug which is not
caught by the TCK :-). isNew() works as you thought it should work.
/Janne
Re: Page renaming weirdness
Posted by Andrew Jaquith <an...@gmail.com>.
Excellent!
FYI, a subtle JCR point that I discovered while pounding out bugs:
there's no easy way to figure out whether a Node exists on disk.
You'd think Node.isNew() would work, but if you create a node then add
a mixin (as we do with createPage()), its status changes to UPDATED,
even before calling save().
The solution I came to -- for WikiPage Nodes at least -- was to check
for the JCRWikiPage.CREATED attribute. Works like a charm.
Andrew
On Oct 14, 2009, at 17:11, Janne Jalkanen <Ja...@ecyrd.com>
wrote:
>
> My current copy only fails on four TCK tests now...
>
> /Janne
>
> On Oct 14, 2009, at 22:25 , Harry Metske wrote:
>
>> Yep, very nice, thanks a lot !
>> /Harry
>>
>> 2009/10/13 Andrew Jaquith <an...@gmail.com>
>>
>>> That seems to work a LOT better -- thanks!
>>>
>>> On Tue, Oct 13, 2009 at 2:32 AM, Janne Jalkanen
>>> <Ja...@ecyrd.com> wrote:
>>>>
>>>> Done; 0.5.3 should fix this.
>>>>
>>>> /Janne
>>>>
>>>> On Oct 13, 2009, at 06:22 , Andrew Jaquith wrote:
>>>>
>>>>> Yeah, unfortunately 0.5.2 is even worse than 0.5.0. 39 failures,
>>>>> 57
>>>>> errors.
>>>>>
>>>>> That said, MANY of them seem to be IllegalStateExceptions
>>>>> related to
>>>>> dates, e.g.,:
>>>>>
>>>>> java.lang.IllegalStateException
>>>>> at org.priha.core.values.ValueImpl.checkValue(ValueImpl.java:63)
>>>>> at
>>>>>
>>> org.priha.core.values.CalendarValueImpl.getDate
>>> (CalendarValueImpl.java:101)
>>>>> at
>>>>>
>>> org.priha.core.values.ValueFactoryImpl.createValue
>>> (ValueFactoryImpl.java:71)
>>>>> at
>>>>>
>>> org.priha.core.values.ValueFactoryImpl.cloneValue
>>> (ValueFactoryImpl.java:337)
>>>>> at org.priha.providers.ValueContainer.deepClone
>>>>> (ValueContainer.java:144)
>>>>> at org.priha.core.PropertyImpl.getValue(PropertyImpl.java:188)
>>>>> at org.priha.core.PropertyImpl.getValue(PropertyImpl.java:40)
>>>>> at
>>>>>
>>> org.apache.wiki.content.ContentManager.copyProperties
>>> (ContentManager.java:428)
>>>>> at
>>> org.apache.wiki.content.ContentManager.checkin(ContentManager.java:
>>> 392)
>>>>> at org.apache.wiki.content.ContentManager.save
>>>>> (ContentManager.java:465)
>>>>> at
>>>>>
>>> org.apache.wiki.parser.JSPWikiMarkupParser.handleAccessRule
>>> (JSPWikiMarkupParser.java:1417)
>>>>> at
>>>>>
>>> org.apache.wiki.parser.JSPWikiMarkupParser.handleHyperlinks
>>> (JSPWikiMarkupParser.java:1499)
>>>>> at
>>>>>
>>> org.apache.wiki.parser.JSPWikiMarkupParser.handleOpenbracket
>>> (JSPWikiMarkupParser.java:2320)
>>>>> at
>>>>>
>>> org.apache.wiki.parser.JSPWikiMarkupParser.parseToken
>>> (JSPWikiMarkupParser.java:2899)
>>>>> at
>>>>>
>>> org.apache.wiki.parser.JSPWikiMarkupParser.fillBuffer
>>> (JSPWikiMarkupParser.java:2695)
>>>>> at
>>>>>
>>> org.apache.wiki.parser.JSPWikiMarkupParser.parse
>>> (JSPWikiMarkupParser.java:2971)
>>>>> at
>>>>>
>>> org.apache.wiki.render.RenderingManager.getRenderedDocument
>>> (RenderingManager.java:247)
>>>>> at
>>>>>
>>> org.apache.wiki.render.RenderingManager.getHTML
>>> (RenderingManager.java:323)
>>>>> at org.apache.wiki.WikiEngine.textToHTML(WikiEngine.java:1543)
>>>>> at
>>>>>
>>> org.apache.wiki.content.ContentManager$SaveWikiPageTask.execute
>>> (ContentManager.java:1267)
>>>>> at
>>> org.apache.wiki.workflow.Workflow.processCurrentStep(Workflow.java:
>>> 766)
>>>>> at org.apache.wiki.workflow.Workflow.start(Workflow.java:681)
>>>>> at
>>> org.apache.wiki.workflow.WorkflowManager.start
>>> (WorkflowManager.java:82)
>>>>> at org.apache.wiki.WikiEngine.saveText(WikiEngine.java:1775)
>>>>> at org.apache.wiki.TestEngine.saveText(TestEngine.java:379)
>>>>> at
>>>>>
>>> org.apache.wiki.auth.AuthorizationManagerTest.testPrincipalAcl
>>> (AuthorizationManagerTest.java:466)
>>>>>
>>>>>
>>>>> The file-renaming bugs seem to have been partly fixed, although
>>>>> there
>>>>> are still errors (might be in the calling code, though).
>>>>>
>>>>> Andrew
>>>>>
>>>>> On Mon, Oct 12, 2009 at 9:42 AM, Harry Metske <harry.metske@gmail.com
>>>>> >
>>>>> wrote:
>>>>>>
>>>>>> I almost checked in that priha version yesterday :-)
>>>>>> Should I wait, or commit that one in ?
>>>>>>
>>>>>> I kept some test-stats BTW:
>>>>>> http://people.apache.org/~metskem/tests/jspwiki-testresult.html
>>>>>> (you can see the good results from Andrew's work the last few
>>>>>> days)
>>>>>>
>>>>>>
>>>>>> regards,
>>>>>> Harry
>>>>>>
>>>>>> 2009/10/12 Janne Jalkanen <Ja...@ecyrd.com>
>>>>>>
>>>>>>>
>>>>>>> Yup, this is a known problem in 0.3.2... Should be fixed in the
>>>>>>> current
>>>>>>> trunk.
>>>>>>>
>>>>>>> /Janne
>>>>>>>
>>>>>>>
>>>>>>> On Oct 12, 2009, at 07:48 , Andrew Jaquith wrote:
>>>>>>>
>>>>>>> Janne, I'm digging into more bugs...
>>>>>>>>
>>>>>>>> The page-renamer tests haven't worked for a while. I think I
>>>>>>>> know
>>>>>>>> why.
>>>>>>>>
>>>>>>>> ContentManager.renamePage(WikiContext, fromPage, toPage) has
>>>>>>>> a bug.
>>>>>>>> Specifically, after this code executes:
>>>>>>>>
>>>>>>>> getCurrentSession().move( getJCRPath( fromPage ),
>>>>>>>> getJCRPath( toPage ) );
>>>>>>>> getCurrentSession().save();
>>>>>>>>
>>>>>>>> ...fromPage is still accessible after this point. I.e.,
>>>>>>>> engine.getPage(fromPage) returns a valid page. Moreover, it
>>>>>>>> shares
>>>>>>>> the
>>>>>>>> same JCR UUID as the toPage. That would suggest that
>>>>>>>> something isn't
>>>>>>>> getting cleaned up properly inside of Priha SessionImpl.move().
>>>>>>>>
>>>>>>>> Of the 18 failing PageRenamerTest tests, fixing this bug would
>>>>>>>> probably get rid of 15 of them.
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>> Andrew
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>
Re: Page renaming weirdness
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
My current copy only fails on four TCK tests now...
/Janne
On Oct 14, 2009, at 22:25 , Harry Metske wrote:
> Yep, very nice, thanks a lot !
> /Harry
>
> 2009/10/13 Andrew Jaquith <an...@gmail.com>
>
>> That seems to work a LOT better -- thanks!
>>
>> On Tue, Oct 13, 2009 at 2:32 AM, Janne Jalkanen
>> <Ja...@ecyrd.com> wrote:
>>>
>>> Done; 0.5.3 should fix this.
>>>
>>> /Janne
>>>
>>> On Oct 13, 2009, at 06:22 , Andrew Jaquith wrote:
>>>
>>>> Yeah, unfortunately 0.5.2 is even worse than 0.5.0. 39 failures, 57
>>>> errors.
>>>>
>>>> That said, MANY of them seem to be IllegalStateExceptions related
>>>> to
>>>> dates, e.g.,:
>>>>
>>>> java.lang.IllegalStateException
>>>> at org.priha.core.values.ValueImpl.checkValue(ValueImpl.java:63)
>>>> at
>>>>
>> org
>> .priha.core.values.CalendarValueImpl.getDate(CalendarValueImpl.java:
>> 101)
>>>> at
>>>>
>> org
>> .priha
>> .core.values.ValueFactoryImpl.createValue(ValueFactoryImpl.java:71)
>>>> at
>>>>
>> org
>> .priha
>> .core.values.ValueFactoryImpl.cloneValue(ValueFactoryImpl.java:337)
>>>> at
>>>> org.priha.providers.ValueContainer.deepClone(ValueContainer.java:
>>>> 144)
>>>> at org.priha.core.PropertyImpl.getValue(PropertyImpl.java:188)
>>>> at org.priha.core.PropertyImpl.getValue(PropertyImpl.java:40)
>>>> at
>>>>
>> org
>> .apache
>> .wiki.content.ContentManager.copyProperties(ContentManager.java:428)
>>>> at
>> org.apache.wiki.content.ContentManager.checkin(ContentManager.java:
>> 392)
>>>> at
>>>> org.apache.wiki.content.ContentManager.save(ContentManager.java:
>>>> 465)
>>>> at
>>>>
>> org
>> .apache
>> .wiki
>> .parser
>> .JSPWikiMarkupParser.handleAccessRule(JSPWikiMarkupParser.java:1417)
>>>> at
>>>>
>> org
>> .apache
>> .wiki
>> .parser
>> .JSPWikiMarkupParser.handleHyperlinks(JSPWikiMarkupParser.java:1499)
>>>> at
>>>>
>> org
>> .apache
>> .wiki
>> .parser
>> .JSPWikiMarkupParser.handleOpenbracket(JSPWikiMarkupParser.java:2320)
>>>> at
>>>>
>> org
>> .apache
>> .wiki
>> .parser.JSPWikiMarkupParser.parseToken(JSPWikiMarkupParser.java:2899)
>>>> at
>>>>
>> org
>> .apache
>> .wiki
>> .parser.JSPWikiMarkupParser.fillBuffer(JSPWikiMarkupParser.java:2695)
>>>> at
>>>>
>> org
>> .apache
>> .wiki.parser.JSPWikiMarkupParser.parse(JSPWikiMarkupParser.java:2971)
>>>> at
>>>>
>> org
>> .apache
>> .wiki
>> .render.RenderingManager.getRenderedDocument(RenderingManager.java:
>> 247)
>>>> at
>>>>
>> org
>> .apache.wiki.render.RenderingManager.getHTML(RenderingManager.java:
>> 323)
>>>> at org.apache.wiki.WikiEngine.textToHTML(WikiEngine.java:1543)
>>>> at
>>>>
>> org.apache.wiki.content.ContentManager
>> $SaveWikiPageTask.execute(ContentManager.java:1267)
>>>> at
>> org.apache.wiki.workflow.Workflow.processCurrentStep(Workflow.java:
>> 766)
>>>> at org.apache.wiki.workflow.Workflow.start(Workflow.java:681)
>>>> at
>> org.apache.wiki.workflow.WorkflowManager.start(WorkflowManager.java:
>> 82)
>>>> at org.apache.wiki.WikiEngine.saveText(WikiEngine.java:1775)
>>>> at org.apache.wiki.TestEngine.saveText(TestEngine.java:379)
>>>> at
>>>>
>> org
>> .apache
>> .wiki
>> .auth
>> .AuthorizationManagerTest
>> .testPrincipalAcl(AuthorizationManagerTest.java:466)
>>>>
>>>>
>>>> The file-renaming bugs seem to have been partly fixed, although
>>>> there
>>>> are still errors (might be in the calling code, though).
>>>>
>>>> Andrew
>>>>
>>>> On Mon, Oct 12, 2009 at 9:42 AM, Harry Metske <harry.metske@gmail.com
>>>> >
>>>> wrote:
>>>>>
>>>>> I almost checked in that priha version yesterday :-)
>>>>> Should I wait, or commit that one in ?
>>>>>
>>>>> I kept some test-stats BTW:
>>>>> http://people.apache.org/~metskem/tests/jspwiki-testresult.html
>>>>> (you can see the good results from Andrew's work the last few
>>>>> days)
>>>>>
>>>>>
>>>>> regards,
>>>>> Harry
>>>>>
>>>>> 2009/10/12 Janne Jalkanen <Ja...@ecyrd.com>
>>>>>
>>>>>>
>>>>>> Yup, this is a known problem in 0.3.2... Should be fixed in the
>>>>>> current
>>>>>> trunk.
>>>>>>
>>>>>> /Janne
>>>>>>
>>>>>>
>>>>>> On Oct 12, 2009, at 07:48 , Andrew Jaquith wrote:
>>>>>>
>>>>>> Janne, I'm digging into more bugs...
>>>>>>>
>>>>>>> The page-renamer tests haven't worked for a while. I think I
>>>>>>> know
>>>>>>> why.
>>>>>>>
>>>>>>> ContentManager.renamePage(WikiContext, fromPage, toPage) has a
>>>>>>> bug.
>>>>>>> Specifically, after this code executes:
>>>>>>>
>>>>>>> getCurrentSession().move( getJCRPath( fromPage ),
>>>>>>> getJCRPath( toPage ) );
>>>>>>> getCurrentSession().save();
>>>>>>>
>>>>>>> ...fromPage is still accessible after this point. I.e.,
>>>>>>> engine.getPage(fromPage) returns a valid page. Moreover, it
>>>>>>> shares
>>>>>>> the
>>>>>>> same JCR UUID as the toPage. That would suggest that something
>>>>>>> isn't
>>>>>>> getting cleaned up properly inside of Priha SessionImpl.move().
>>>>>>>
>>>>>>> Of the 18 failing PageRenamerTest tests, fixing this bug would
>>>>>>> probably get rid of 15 of them.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> Andrew
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
Re: Page renaming weirdness
Posted by Harry Metske <ha...@gmail.com>.
Yep, very nice, thanks a lot !
/Harry
2009/10/13 Andrew Jaquith <an...@gmail.com>
> That seems to work a LOT better -- thanks!
>
> On Tue, Oct 13, 2009 at 2:32 AM, Janne Jalkanen
> <Ja...@ecyrd.com> wrote:
> >
> > Done; 0.5.3 should fix this.
> >
> > /Janne
> >
> > On Oct 13, 2009, at 06:22 , Andrew Jaquith wrote:
> >
> >> Yeah, unfortunately 0.5.2 is even worse than 0.5.0. 39 failures, 57
> >> errors.
> >>
> >> That said, MANY of them seem to be IllegalStateExceptions related to
> >> dates, e.g.,:
> >>
> >> java.lang.IllegalStateException
> >> at org.priha.core.values.ValueImpl.checkValue(ValueImpl.java:63)
> >> at
> >>
> org.priha.core.values.CalendarValueImpl.getDate(CalendarValueImpl.java:101)
> >> at
> >>
> org.priha.core.values.ValueFactoryImpl.createValue(ValueFactoryImpl.java:71)
> >> at
> >>
> org.priha.core.values.ValueFactoryImpl.cloneValue(ValueFactoryImpl.java:337)
> >> at org.priha.providers.ValueContainer.deepClone(ValueContainer.java:144)
> >> at org.priha.core.PropertyImpl.getValue(PropertyImpl.java:188)
> >> at org.priha.core.PropertyImpl.getValue(PropertyImpl.java:40)
> >> at
> >>
> org.apache.wiki.content.ContentManager.copyProperties(ContentManager.java:428)
> >> at
> org.apache.wiki.content.ContentManager.checkin(ContentManager.java:392)
> >> at org.apache.wiki.content.ContentManager.save(ContentManager.java:465)
> >> at
> >>
> org.apache.wiki.parser.JSPWikiMarkupParser.handleAccessRule(JSPWikiMarkupParser.java:1417)
> >> at
> >>
> org.apache.wiki.parser.JSPWikiMarkupParser.handleHyperlinks(JSPWikiMarkupParser.java:1499)
> >> at
> >>
> org.apache.wiki.parser.JSPWikiMarkupParser.handleOpenbracket(JSPWikiMarkupParser.java:2320)
> >> at
> >>
> org.apache.wiki.parser.JSPWikiMarkupParser.parseToken(JSPWikiMarkupParser.java:2899)
> >> at
> >>
> org.apache.wiki.parser.JSPWikiMarkupParser.fillBuffer(JSPWikiMarkupParser.java:2695)
> >> at
> >>
> org.apache.wiki.parser.JSPWikiMarkupParser.parse(JSPWikiMarkupParser.java:2971)
> >> at
> >>
> org.apache.wiki.render.RenderingManager.getRenderedDocument(RenderingManager.java:247)
> >> at
> >>
> org.apache.wiki.render.RenderingManager.getHTML(RenderingManager.java:323)
> >> at org.apache.wiki.WikiEngine.textToHTML(WikiEngine.java:1543)
> >> at
> >>
> org.apache.wiki.content.ContentManager$SaveWikiPageTask.execute(ContentManager.java:1267)
> >> at
> org.apache.wiki.workflow.Workflow.processCurrentStep(Workflow.java:766)
> >> at org.apache.wiki.workflow.Workflow.start(Workflow.java:681)
> >> at
> org.apache.wiki.workflow.WorkflowManager.start(WorkflowManager.java:82)
> >> at org.apache.wiki.WikiEngine.saveText(WikiEngine.java:1775)
> >> at org.apache.wiki.TestEngine.saveText(TestEngine.java:379)
> >> at
> >>
> org.apache.wiki.auth.AuthorizationManagerTest.testPrincipalAcl(AuthorizationManagerTest.java:466)
> >>
> >>
> >> The file-renaming bugs seem to have been partly fixed, although there
> >> are still errors (might be in the calling code, though).
> >>
> >> Andrew
> >>
> >> On Mon, Oct 12, 2009 at 9:42 AM, Harry Metske <ha...@gmail.com>
> >> wrote:
> >>>
> >>> I almost checked in that priha version yesterday :-)
> >>> Should I wait, or commit that one in ?
> >>>
> >>> I kept some test-stats BTW:
> >>> http://people.apache.org/~metskem/tests/jspwiki-testresult.html
> >>> (you can see the good results from Andrew's work the last few days)
> >>>
> >>>
> >>> regards,
> >>> Harry
> >>>
> >>> 2009/10/12 Janne Jalkanen <Ja...@ecyrd.com>
> >>>
> >>>>
> >>>> Yup, this is a known problem in 0.3.2... Should be fixed in the
> >>>> current
> >>>> trunk.
> >>>>
> >>>> /Janne
> >>>>
> >>>>
> >>>> On Oct 12, 2009, at 07:48 , Andrew Jaquith wrote:
> >>>>
> >>>> Janne, I'm digging into more bugs...
> >>>>>
> >>>>> The page-renamer tests haven't worked for a while. I think I know
> >>>>> why.
> >>>>>
> >>>>> ContentManager.renamePage(WikiContext, fromPage, toPage) has a bug.
> >>>>> Specifically, after this code executes:
> >>>>>
> >>>>> getCurrentSession().move( getJCRPath( fromPage ),
> >>>>> getJCRPath( toPage ) );
> >>>>> getCurrentSession().save();
> >>>>>
> >>>>> ...fromPage is still accessible after this point. I.e.,
> >>>>> engine.getPage(fromPage) returns a valid page. Moreover, it shares
> >>>>> the
> >>>>> same JCR UUID as the toPage. That would suggest that something isn't
> >>>>> getting cleaned up properly inside of Priha SessionImpl.move().
> >>>>>
> >>>>> Of the 18 failing PageRenamerTest tests, fixing this bug would
> >>>>> probably get rid of 15 of them.
> >>>>>
> >>>>> Thoughts?
> >>>>>
> >>>>> Andrew
> >>>>>
> >>>>
> >>>>
> >>>
> >
> >
>
Re: Page renaming weirdness
Posted by Andrew Jaquith <an...@gmail.com>.
That seems to work a LOT better -- thanks!
On Tue, Oct 13, 2009 at 2:32 AM, Janne Jalkanen
<Ja...@ecyrd.com> wrote:
>
> Done; 0.5.3 should fix this.
>
> /Janne
>
> On Oct 13, 2009, at 06:22 , Andrew Jaquith wrote:
>
>> Yeah, unfortunately 0.5.2 is even worse than 0.5.0. 39 failures, 57
>> errors.
>>
>> That said, MANY of them seem to be IllegalStateExceptions related to
>> dates, e.g.,:
>>
>> java.lang.IllegalStateException
>> at org.priha.core.values.ValueImpl.checkValue(ValueImpl.java:63)
>> at
>> org.priha.core.values.CalendarValueImpl.getDate(CalendarValueImpl.java:101)
>> at
>> org.priha.core.values.ValueFactoryImpl.createValue(ValueFactoryImpl.java:71)
>> at
>> org.priha.core.values.ValueFactoryImpl.cloneValue(ValueFactoryImpl.java:337)
>> at org.priha.providers.ValueContainer.deepClone(ValueContainer.java:144)
>> at org.priha.core.PropertyImpl.getValue(PropertyImpl.java:188)
>> at org.priha.core.PropertyImpl.getValue(PropertyImpl.java:40)
>> at
>> org.apache.wiki.content.ContentManager.copyProperties(ContentManager.java:428)
>> at org.apache.wiki.content.ContentManager.checkin(ContentManager.java:392)
>> at org.apache.wiki.content.ContentManager.save(ContentManager.java:465)
>> at
>> org.apache.wiki.parser.JSPWikiMarkupParser.handleAccessRule(JSPWikiMarkupParser.java:1417)
>> at
>> org.apache.wiki.parser.JSPWikiMarkupParser.handleHyperlinks(JSPWikiMarkupParser.java:1499)
>> at
>> org.apache.wiki.parser.JSPWikiMarkupParser.handleOpenbracket(JSPWikiMarkupParser.java:2320)
>> at
>> org.apache.wiki.parser.JSPWikiMarkupParser.parseToken(JSPWikiMarkupParser.java:2899)
>> at
>> org.apache.wiki.parser.JSPWikiMarkupParser.fillBuffer(JSPWikiMarkupParser.java:2695)
>> at
>> org.apache.wiki.parser.JSPWikiMarkupParser.parse(JSPWikiMarkupParser.java:2971)
>> at
>> org.apache.wiki.render.RenderingManager.getRenderedDocument(RenderingManager.java:247)
>> at
>> org.apache.wiki.render.RenderingManager.getHTML(RenderingManager.java:323)
>> at org.apache.wiki.WikiEngine.textToHTML(WikiEngine.java:1543)
>> at
>> org.apache.wiki.content.ContentManager$SaveWikiPageTask.execute(ContentManager.java:1267)
>> at org.apache.wiki.workflow.Workflow.processCurrentStep(Workflow.java:766)
>> at org.apache.wiki.workflow.Workflow.start(Workflow.java:681)
>> at org.apache.wiki.workflow.WorkflowManager.start(WorkflowManager.java:82)
>> at org.apache.wiki.WikiEngine.saveText(WikiEngine.java:1775)
>> at org.apache.wiki.TestEngine.saveText(TestEngine.java:379)
>> at
>> org.apache.wiki.auth.AuthorizationManagerTest.testPrincipalAcl(AuthorizationManagerTest.java:466)
>>
>>
>> The file-renaming bugs seem to have been partly fixed, although there
>> are still errors (might be in the calling code, though).
>>
>> Andrew
>>
>> On Mon, Oct 12, 2009 at 9:42 AM, Harry Metske <ha...@gmail.com>
>> wrote:
>>>
>>> I almost checked in that priha version yesterday :-)
>>> Should I wait, or commit that one in ?
>>>
>>> I kept some test-stats BTW:
>>> http://people.apache.org/~metskem/tests/jspwiki-testresult.html
>>> (you can see the good results from Andrew's work the last few days)
>>>
>>>
>>> regards,
>>> Harry
>>>
>>> 2009/10/12 Janne Jalkanen <Ja...@ecyrd.com>
>>>
>>>>
>>>> Yup, this is a known problem in 0.3.2... Should be fixed in the
>>>> current
>>>> trunk.
>>>>
>>>> /Janne
>>>>
>>>>
>>>> On Oct 12, 2009, at 07:48 , Andrew Jaquith wrote:
>>>>
>>>> Janne, I'm digging into more bugs...
>>>>>
>>>>> The page-renamer tests haven't worked for a while. I think I know
>>>>> why.
>>>>>
>>>>> ContentManager.renamePage(WikiContext, fromPage, toPage) has a bug.
>>>>> Specifically, after this code executes:
>>>>>
>>>>> getCurrentSession().move( getJCRPath( fromPage ),
>>>>> getJCRPath( toPage ) );
>>>>> getCurrentSession().save();
>>>>>
>>>>> ...fromPage is still accessible after this point. I.e.,
>>>>> engine.getPage(fromPage) returns a valid page. Moreover, it shares
>>>>> the
>>>>> same JCR UUID as the toPage. That would suggest that something isn't
>>>>> getting cleaned up properly inside of Priha SessionImpl.move().
>>>>>
>>>>> Of the 18 failing PageRenamerTest tests, fixing this bug would
>>>>> probably get rid of 15 of them.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Andrew
>>>>>
>>>>
>>>>
>>>
>
>
Re: Page renaming weirdness
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
Done; 0.5.3 should fix this.
/Janne
On Oct 13, 2009, at 06:22 , Andrew Jaquith wrote:
> Yeah, unfortunately 0.5.2 is even worse than 0.5.0. 39 failures, 57
> errors.
>
> That said, MANY of them seem to be IllegalStateExceptions related to
> dates, e.g.,:
>
> java.lang.IllegalStateException
> at org.priha.core.values.ValueImpl.checkValue(ValueImpl.java:63)
> at
> org
> .priha.core.values.CalendarValueImpl.getDate(CalendarValueImpl.java:
> 101)
> at
> org
> .priha
> .core.values.ValueFactoryImpl.createValue(ValueFactoryImpl.java:71)
> at
> org
> .priha.core.values.ValueFactoryImpl.cloneValue(ValueFactoryImpl.java:
> 337)
> at org.priha.providers.ValueContainer.deepClone(ValueContainer.java:
> 144)
> at org.priha.core.PropertyImpl.getValue(PropertyImpl.java:188)
> at org.priha.core.PropertyImpl.getValue(PropertyImpl.java:40)
> at
> org
> .apache
> .wiki.content.ContentManager.copyProperties(ContentManager.java:428)
> at
> org.apache.wiki.content.ContentManager.checkin(ContentManager.java:
> 392)
> at org.apache.wiki.content.ContentManager.save(ContentManager.java:
> 465)
> at
> org
> .apache
> .wiki
> .parser
> .JSPWikiMarkupParser.handleAccessRule(JSPWikiMarkupParser.java:1417)
> at
> org
> .apache
> .wiki
> .parser
> .JSPWikiMarkupParser.handleHyperlinks(JSPWikiMarkupParser.java:1499)
> at
> org
> .apache
> .wiki
> .parser
> .JSPWikiMarkupParser.handleOpenbracket(JSPWikiMarkupParser.java:2320)
> at
> org
> .apache
> .wiki.parser.JSPWikiMarkupParser.parseToken(JSPWikiMarkupParser.java:
> 2899)
> at
> org
> .apache
> .wiki.parser.JSPWikiMarkupParser.fillBuffer(JSPWikiMarkupParser.java:
> 2695)
> at
> org
> .apache
> .wiki.parser.JSPWikiMarkupParser.parse(JSPWikiMarkupParser.java:2971)
> at
> org
> .apache
> .wiki
> .render.RenderingManager.getRenderedDocument(RenderingManager.java:
> 247)
> at
> org
> .apache.wiki.render.RenderingManager.getHTML(RenderingManager.java:
> 323)
> at org.apache.wiki.WikiEngine.textToHTML(WikiEngine.java:1543)
> at org.apache.wiki.content.ContentManager
> $SaveWikiPageTask.execute(ContentManager.java:1267)
> at
> org.apache.wiki.workflow.Workflow.processCurrentStep(Workflow.java:
> 766)
> at org.apache.wiki.workflow.Workflow.start(Workflow.java:681)
> at
> org.apache.wiki.workflow.WorkflowManager.start(WorkflowManager.java:
> 82)
> at org.apache.wiki.WikiEngine.saveText(WikiEngine.java:1775)
> at org.apache.wiki.TestEngine.saveText(TestEngine.java:379)
> at
> org
> .apache
> .wiki
> .auth
> .AuthorizationManagerTest
> .testPrincipalAcl(AuthorizationManagerTest.java:466)
>
>
> The file-renaming bugs seem to have been partly fixed, although there
> are still errors (might be in the calling code, though).
>
> Andrew
>
> On Mon, Oct 12, 2009 at 9:42 AM, Harry Metske <ha...@gmail.com>
> wrote:
>> I almost checked in that priha version yesterday :-)
>> Should I wait, or commit that one in ?
>>
>> I kept some test-stats BTW:
>> http://people.apache.org/~metskem/tests/jspwiki-testresult.html
>> (you can see the good results from Andrew's work the last few days)
>>
>>
>> regards,
>> Harry
>>
>> 2009/10/12 Janne Jalkanen <Ja...@ecyrd.com>
>>
>>>
>>> Yup, this is a known problem in 0.3.2... Should be fixed in the
>>> current
>>> trunk.
>>>
>>> /Janne
>>>
>>>
>>> On Oct 12, 2009, at 07:48 , Andrew Jaquith wrote:
>>>
>>> Janne, I'm digging into more bugs...
>>>>
>>>> The page-renamer tests haven't worked for a while. I think I know
>>>> why.
>>>>
>>>> ContentManager.renamePage(WikiContext, fromPage, toPage) has a bug.
>>>> Specifically, after this code executes:
>>>>
>>>> getCurrentSession().move( getJCRPath( fromPage ),
>>>> getJCRPath( toPage ) );
>>>> getCurrentSession().save();
>>>>
>>>> ...fromPage is still accessible after this point. I.e.,
>>>> engine.getPage(fromPage) returns a valid page. Moreover, it shares
>>>> the
>>>> same JCR UUID as the toPage. That would suggest that something
>>>> isn't
>>>> getting cleaned up properly inside of Priha SessionImpl.move().
>>>>
>>>> Of the 18 failing PageRenamerTest tests, fixing this bug would
>>>> probably get rid of 15 of them.
>>>>
>>>> Thoughts?
>>>>
>>>> Andrew
>>>>
>>>
>>>
>>
Re: Page renaming weirdness
Posted by Andrew Jaquith <an...@gmail.com>.
Yeah, unfortunately 0.5.2 is even worse than 0.5.0. 39 failures, 57 errors.
That said, MANY of them seem to be IllegalStateExceptions related to
dates, e.g.,:
java.lang.IllegalStateException
at org.priha.core.values.ValueImpl.checkValue(ValueImpl.java:63)
at org.priha.core.values.CalendarValueImpl.getDate(CalendarValueImpl.java:101)
at org.priha.core.values.ValueFactoryImpl.createValue(ValueFactoryImpl.java:71)
at org.priha.core.values.ValueFactoryImpl.cloneValue(ValueFactoryImpl.java:337)
at org.priha.providers.ValueContainer.deepClone(ValueContainer.java:144)
at org.priha.core.PropertyImpl.getValue(PropertyImpl.java:188)
at org.priha.core.PropertyImpl.getValue(PropertyImpl.java:40)
at org.apache.wiki.content.ContentManager.copyProperties(ContentManager.java:428)
at org.apache.wiki.content.ContentManager.checkin(ContentManager.java:392)
at org.apache.wiki.content.ContentManager.save(ContentManager.java:465)
at org.apache.wiki.parser.JSPWikiMarkupParser.handleAccessRule(JSPWikiMarkupParser.java:1417)
at org.apache.wiki.parser.JSPWikiMarkupParser.handleHyperlinks(JSPWikiMarkupParser.java:1499)
at org.apache.wiki.parser.JSPWikiMarkupParser.handleOpenbracket(JSPWikiMarkupParser.java:2320)
at org.apache.wiki.parser.JSPWikiMarkupParser.parseToken(JSPWikiMarkupParser.java:2899)
at org.apache.wiki.parser.JSPWikiMarkupParser.fillBuffer(JSPWikiMarkupParser.java:2695)
at org.apache.wiki.parser.JSPWikiMarkupParser.parse(JSPWikiMarkupParser.java:2971)
at org.apache.wiki.render.RenderingManager.getRenderedDocument(RenderingManager.java:247)
at org.apache.wiki.render.RenderingManager.getHTML(RenderingManager.java:323)
at org.apache.wiki.WikiEngine.textToHTML(WikiEngine.java:1543)
at org.apache.wiki.content.ContentManager$SaveWikiPageTask.execute(ContentManager.java:1267)
at org.apache.wiki.workflow.Workflow.processCurrentStep(Workflow.java:766)
at org.apache.wiki.workflow.Workflow.start(Workflow.java:681)
at org.apache.wiki.workflow.WorkflowManager.start(WorkflowManager.java:82)
at org.apache.wiki.WikiEngine.saveText(WikiEngine.java:1775)
at org.apache.wiki.TestEngine.saveText(TestEngine.java:379)
at org.apache.wiki.auth.AuthorizationManagerTest.testPrincipalAcl(AuthorizationManagerTest.java:466)
The file-renaming bugs seem to have been partly fixed, although there
are still errors (might be in the calling code, though).
Andrew
On Mon, Oct 12, 2009 at 9:42 AM, Harry Metske <ha...@gmail.com>
wrote:
> I almost checked in that priha version yesterday :-)
> Should I wait, or commit that one in ?
>
> I kept some test-stats BTW:
> http://people.apache.org/~metskem/tests/jspwiki-testresult.html
> (you can see the good results from Andrew's work the last few days)
>
>
> regards,
> Harry
>
> 2009/10/12 Janne Jalkanen <Ja...@ecyrd.com>
>
>>
>> Yup, this is a known problem in 0.3.2... Should be fixed in the
>> current
>> trunk.
>>
>> /Janne
>>
>>
>> On Oct 12, 2009, at 07:48 , Andrew Jaquith wrote:
>>
>> Janne, I'm digging into more bugs...
>>>
>>> The page-renamer tests haven't worked for a while. I think I know
>>> why.
>>>
>>> ContentManager.renamePage(WikiContext, fromPage, toPage) has a bug.
>>> Specifically, after this code executes:
>>>
>>> getCurrentSession().move( getJCRPath( fromPage ),
>>> getJCRPath( toPage ) );
>>> getCurrentSession().save();
>>>
>>> ...fromPage is still accessible after this point. I.e.,
>>> engine.getPage(fromPage) returns a valid page. Moreover, it shares
>>> the
>>> same JCR UUID as the toPage. That would suggest that something isn't
>>> getting cleaned up properly inside of Priha SessionImpl.move().
>>>
>>> Of the 18 failing PageRenamerTest tests, fixing this bug would
>>> probably get rid of 15 of them.
>>>
>>> Thoughts?
>>>
>>> Andrew
>>>
>>
>>
>
Re: Page renaming weirdness
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
Done; tagged 0.5.2 for your pleasure.
/Janne
On Oct 12, 2009, at 23:40 , Janne Jalkanen wrote:
>
> Hold on a few minutes; I'm checking in 0.5.2 which is fixing quite a
> few issues.
>
> /Janne
>
> On Oct 12, 2009, at 22:21 , Harry Metske wrote:
>
>> nope, not recommended in the priha Changelog 0.5, also the test
>> results are
>> not better :-(quite a bit more errors and failures.
>>
>> Harry
>>
>> 2009/10/12 Harry Metske <ha...@gmail.com>
>>
>>> I almost checked in that priha version yesterday :-)
>>> Should I wait, or commit that one in ?
>>>
>>> I kept some test-stats BTW:
>>> http://people.apache.org/~metskem/tests/jspwiki-testresult.html
>>> (you can see the good results from Andrew's work the last few days)
>>>
>>>
>>> regards,
>>> Harry
>>>
>>> 2009/10/12 Janne Jalkanen <Ja...@ecyrd.com>
>>>
>>>
>>>> Yup, this is a known problem in 0.3.2... Should be fixed in the
>>>> current
>>>> trunk.
>>>>
>>>> /Janne
>>>>
>>>>
>>>> On Oct 12, 2009, at 07:48 , Andrew Jaquith wrote:
>>>>
>>>> Janne, I'm digging into more bugs...
>>>>>
>>>>> The page-renamer tests haven't worked for a while. I think I
>>>>> know why.
>>>>>
>>>>> ContentManager.renamePage(WikiContext, fromPage, toPage) has a
>>>>> bug.
>>>>> Specifically, after this code executes:
>>>>>
>>>>> getCurrentSession().move( getJCRPath( fromPage ),
>>>>> getJCRPath( toPage ) );
>>>>> getCurrentSession().save();
>>>>>
>>>>> ...fromPage is still accessible after this point. I.e.,
>>>>> engine.getPage(fromPage) returns a valid page. Moreover, it
>>>>> shares the
>>>>> same JCR UUID as the toPage. That would suggest that something
>>>>> isn't
>>>>> getting cleaned up properly inside of Priha SessionImpl.move().
>>>>>
>>>>> Of the 18 failing PageRenamerTest tests, fixing this bug would
>>>>> probably get rid of 15 of them.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Andrew
>>>>>
>>>>
>>>>
>>>
Re: Page renaming weirdness
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
Hold on a few minutes; I'm checking in 0.5.2 which is fixing quite a
few issues.
/Janne
On Oct 12, 2009, at 22:21 , Harry Metske wrote:
> nope, not recommended in the priha Changelog 0.5, also the test
> results are
> not better :-(quite a bit more errors and failures.
>
> Harry
>
> 2009/10/12 Harry Metske <ha...@gmail.com>
>
>> I almost checked in that priha version yesterday :-)
>> Should I wait, or commit that one in ?
>>
>> I kept some test-stats BTW:
>> http://people.apache.org/~metskem/tests/jspwiki-testresult.html
>> (you can see the good results from Andrew's work the last few days)
>>
>>
>> regards,
>> Harry
>>
>> 2009/10/12 Janne Jalkanen <Ja...@ecyrd.com>
>>
>>
>>> Yup, this is a known problem in 0.3.2... Should be fixed in the
>>> current
>>> trunk.
>>>
>>> /Janne
>>>
>>>
>>> On Oct 12, 2009, at 07:48 , Andrew Jaquith wrote:
>>>
>>> Janne, I'm digging into more bugs...
>>>>
>>>> The page-renamer tests haven't worked for a while. I think I
>>>> know why.
>>>>
>>>> ContentManager.renamePage(WikiContext, fromPage, toPage) has a bug.
>>>> Specifically, after this code executes:
>>>>
>>>> getCurrentSession().move( getJCRPath( fromPage ),
>>>> getJCRPath( toPage ) );
>>>> getCurrentSession().save();
>>>>
>>>> ...fromPage is still accessible after this point. I.e.,
>>>> engine.getPage(fromPage) returns a valid page. Moreover, it
>>>> shares the
>>>> same JCR UUID as the toPage. That would suggest that something
>>>> isn't
>>>> getting cleaned up properly inside of Priha SessionImpl.move().
>>>>
>>>> Of the 18 failing PageRenamerTest tests, fixing this bug would
>>>> probably get rid of 15 of them.
>>>>
>>>> Thoughts?
>>>>
>>>> Andrew
>>>>
>>>
>>>
>>
Re: Page renaming weirdness
Posted by Harry Metske <ha...@gmail.com>.
nope, not recommended in the priha Changelog 0.5, also the test results are
not better :-(quite a bit more errors and failures.
Harry
2009/10/12 Harry Metske <ha...@gmail.com>
> I almost checked in that priha version yesterday :-)
> Should I wait, or commit that one in ?
>
> I kept some test-stats BTW:
> http://people.apache.org/~metskem/tests/jspwiki-testresult.html
> (you can see the good results from Andrew's work the last few days)
>
>
> regards,
> Harry
>
> 2009/10/12 Janne Jalkanen <Ja...@ecyrd.com>
>
>
>> Yup, this is a known problem in 0.3.2... Should be fixed in the current
>> trunk.
>>
>> /Janne
>>
>>
>> On Oct 12, 2009, at 07:48 , Andrew Jaquith wrote:
>>
>> Janne, I'm digging into more bugs...
>>>
>>> The page-renamer tests haven't worked for a while. I think I know why.
>>>
>>> ContentManager.renamePage(WikiContext, fromPage, toPage) has a bug.
>>> Specifically, after this code executes:
>>>
>>> getCurrentSession().move( getJCRPath( fromPage ),
>>> getJCRPath( toPage ) );
>>> getCurrentSession().save();
>>>
>>> ...fromPage is still accessible after this point. I.e.,
>>> engine.getPage(fromPage) returns a valid page. Moreover, it shares the
>>> same JCR UUID as the toPage. That would suggest that something isn't
>>> getting cleaned up properly inside of Priha SessionImpl.move().
>>>
>>> Of the 18 failing PageRenamerTest tests, fixing this bug would
>>> probably get rid of 15 of them.
>>>
>>> Thoughts?
>>>
>>> Andrew
>>>
>>
>>
>
Re: Page renaming weirdness
Posted by Harry Metske <ha...@gmail.com>.
I almost checked in that priha version yesterday :-)
Should I wait, or commit that one in ?
I kept some test-stats BTW:
http://people.apache.org/~metskem/tests/jspwiki-testresult.html
(you can see the good results from Andrew's work the last few days)
regards,
Harry
2009/10/12 Janne Jalkanen <Ja...@ecyrd.com>
>
> Yup, this is a known problem in 0.3.2... Should be fixed in the current
> trunk.
>
> /Janne
>
>
> On Oct 12, 2009, at 07:48 , Andrew Jaquith wrote:
>
> Janne, I'm digging into more bugs...
>>
>> The page-renamer tests haven't worked for a while. I think I know why.
>>
>> ContentManager.renamePage(WikiContext, fromPage, toPage) has a bug.
>> Specifically, after this code executes:
>>
>> getCurrentSession().move( getJCRPath( fromPage ),
>> getJCRPath( toPage ) );
>> getCurrentSession().save();
>>
>> ...fromPage is still accessible after this point. I.e.,
>> engine.getPage(fromPage) returns a valid page. Moreover, it shares the
>> same JCR UUID as the toPage. That would suggest that something isn't
>> getting cleaned up properly inside of Priha SessionImpl.move().
>>
>> Of the 18 failing PageRenamerTest tests, fixing this bug would
>> probably get rid of 15 of them.
>>
>> Thoughts?
>>
>> Andrew
>>
>
>
Re: Page renaming weirdness
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
Yup, this is a known problem in 0.3.2... Should be fixed in the
current trunk.
/Janne
On Oct 12, 2009, at 07:48 , Andrew Jaquith wrote:
> Janne, I'm digging into more bugs...
>
> The page-renamer tests haven't worked for a while. I think I know
> why.
>
> ContentManager.renamePage(WikiContext, fromPage, toPage) has a bug.
> Specifically, after this code executes:
>
> getCurrentSession().move( getJCRPath( fromPage ),
> getJCRPath( toPage ) );
> getCurrentSession().save();
>
> ...fromPage is still accessible after this point. I.e.,
> engine.getPage(fromPage) returns a valid page. Moreover, it shares the
> same JCR UUID as the toPage. That would suggest that something isn't
> getting cleaned up properly inside of Priha SessionImpl.move().
>
> Of the 18 failing PageRenamerTest tests, fixing this bug would
> probably get rid of 15 of them.
>
> Thoughts?
>
> Andrew