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/26 19:13:42 UTC
2 last failing unit tests
Hey Janne,
I upgraded to Priha 0.5.5, PageRenamer.testBug25 and
testAttachmentChange are the only unit tests that still fail (other
than LDAP if an LDAP test server isn't running).
Both are failing with messages similar to this...
Could not rename page. Reason: Looks like this Node has been removed
by another session: /pages/Main/RenamedTest
org.apache.wiki.api.WikiException: Could not rename page. Reason:
Looks like this Node has been removed by another session:
/pages/Main/RenamedTest
at org.apache.wiki.content.ContentManager.renamePage(ContentManager.java:1373)
at org.apache.wiki.WikiEngine.renamePage(WikiEngine.java:2330)
at org.apache.wiki.content.PageRenamerTest.testAttachmentChange(PageRenamerTest.java:237)
Caused by: 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:1369)
I did a little digging, and what seems to happen is that
ContentManager calls SessionImpl.move() successfully. But then the
save() that immediately follows throws an error. Is there anything we
can do inside JSPWiki to fix this? (Probably not... feels like Priha).
Any chance you could take a peek at this? I suspect we are close to
closing these.
One more quick thing: the state of the build is stabilizing. The WAR
builds fine, but runs a little funny because something is complaining
about not finding certain JCR attributes when pages are displayed.
This has been true since the upgrade from Priha 0.3x. I will hunt
these issues down...
Oh, and lastly, it'll be good to see you (and other local wikifolk)
next week in Boston...
Andrew
Re: 2 last failing unit tests
Posted by Andrew Jaquith <an...@gmail.com>.
Ok -- just checked in a bunch of little tweaks. The svn:ignore
properties for etc/ and tests/etc/ should be fixed now, so you
*should* see updates for certain files next time you synchronize that
should be the "right" ones.
Also, I found the discrepancy in the test numbers. A few tests had
been excluded from the guitests and Eclipse version. Also,
TextUtilTest was included TWICE in its AllTests class.
Anyway, it's all fixed, except for some sort of classpath issue that's
causing the HtmlStringToWikiTest to fail. I'm kinda tired of messing
with this stuff after spending what, 3 weeks in a row? fixing tests
nonstop. So I'm going to let Janne tackle this one.
As for running the Ant tests target by just running the AllTests
method, I think this is a bad idea. Partly because it serves as a good
check against how AllTests are constructed (as I just found out
tonight), and partly because you'd get no command-line output for each
test like we have now. Which I find comforting, somehow...
Andrew
On Tue, Oct 27, 2009 at 4:35 PM, Janne Jalkanen
<Ja...@ecyrd.com> wrote:
>
>>> However, I still do get a bunch of ClassNotFounds for
>>> HtmlStringToWikiTranslatorTest, but I suspect these could be my setup
>>> too.
>
> Yup; ant guitests passes now with 990 runs, no errors, no failures. Good
> work!
>
> Now we just have to figure out which tests are actually still correct and
> whether the UI still runs :-)
>
> /Janne
>
Re: 2 last failing unit tests
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
>> However, I still do get a bunch of ClassNotFounds for
>> HtmlStringToWikiTranslatorTest, but I suspect these could be my
>> setup too.
Yup; ant guitests passes now with 990 runs, no errors, no failures.
Good work!
Now we just have to figure out which tests are actually still correct
and whether the UI still runs :-)
/Janne
Re: 2 last failing unit tests
Posted by Andrew Jaquith <an...@gmail.com>.
Ok -- I think I know what the issue is. There's are .svnignore file in
etc/ and tests/etc that probably need to have their
userdatabase.xml/groupdatabase.xml exclusions removed. If trunk wasn't
overwriting your local copies (which it should, now), that would
explain the XMLUserDatabase failure.
Lemme take a look at this tonight...
Andrew
On Tue, Oct 27, 2009 at 4:15 PM, Janne Jalkanen
<Ja...@ecyrd.com> wrote:
>> 1) Guitests. I'll see what I can find. Probably something minor. I
>> know the "tests" target runs all test classes ending in "*Test" and
>> ignores "AllTests", while Eclipse (and probably guitests) just runs
>> the AllTests classes. It's likely that one or more of the AllTests
>> classes is failing to include, oh, about 34 tests. :)
>
> Yes, that's possible. I think it might make sense if we used AllTests for
> everything... I know it's a bit of manual work, but at least that's how we
> can keep the results in sync.
>
>> 2) Graceful LDAP fail (inside the tests themselves). Any ideas on how
>> to implement? The easy way would be to look for a localhost listener
>> on 4890 (where the OpenLDAP test fixture listens) and then not run the
>> tests if it isn't found. Should they FAIL or PASS in that case? It
>> sounds like passing is the right thing to do.
>
> Just committed some code to SVN. Can you please check that they work well
> also in the positive case?
>
> (Meh, it's been three months since my last commit. Too long... Well,
> hopefully now that Priha works I can get back to this again :-)
>
>> 3) Differences in your test pass rate versus mine. Not sure why your
>> "ant tests" run would produce different results than mine. I did try
>> running mine with a completely new, checked-out branch. Because I
>> can't know what changes you might have in your local branch, could you
>> check out a clean copy and diff the tree versus yours? SOMETHING is
>> different. Also, I'd like to know what Harry and others are seeing.
>> Gents, any clues?
>
> I poked into it and it seems that I had an older userdatabase.xml which was
> NOT updated whenever I did "svn up". Strange.
>
> However, I still do get a bunch of ClassNotFounds for
> HtmlStringToWikiTranslatorTest, but I suspect these could be my setup too.
>
>> Eclipse, by the way, hasn't been reliable for me, for testing, for a
>> while. I tend to exhaust memory somewhere around JSPWikiMarkupParser.
>> But I haven't tried it in the last few months (i.e. before my massive
>> bug-hunting campaign).
>
> Ah, I always add more memory to these tests: Click on the test runner, "Run
> Configurations" -> "Arguments" -> "VM Arguments", add -xmx512m.
>
> /Janne
>
Re: 2 last failing unit tests
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> 1) Guitests. I'll see what I can find. Probably something minor. I
> know the "tests" target runs all test classes ending in "*Test" and
> ignores "AllTests", while Eclipse (and probably guitests) just runs
> the AllTests classes. It's likely that one or more of the AllTests
> classes is failing to include, oh, about 34 tests. :)
Yes, that's possible. I think it might make sense if we used AllTests
for everything... I know it's a bit of manual work, but at least
that's how we can keep the results in sync.
> 2) Graceful LDAP fail (inside the tests themselves). Any ideas on how
> to implement? The easy way would be to look for a localhost listener
> on 4890 (where the OpenLDAP test fixture listens) and then not run the
> tests if it isn't found. Should they FAIL or PASS in that case? It
> sounds like passing is the right thing to do.
Just committed some code to SVN. Can you please check that they work
well also in the positive case?
(Meh, it's been three months since my last commit. Too long... Well,
hopefully now that Priha works I can get back to this again :-)
> 3) Differences in your test pass rate versus mine. Not sure why your
> "ant tests" run would produce different results than mine. I did try
> running mine with a completely new, checked-out branch. Because I
> can't know what changes you might have in your local branch, could you
> check out a clean copy and diff the tree versus yours? SOMETHING is
> different. Also, I'd like to know what Harry and others are seeing.
> Gents, any clues?
I poked into it and it seems that I had an older userdatabase.xml
which was NOT updated whenever I did "svn up". Strange.
However, I still do get a bunch of ClassNotFounds for
HtmlStringToWikiTranslatorTest, but I suspect these could be my setup
too.
> Eclipse, by the way, hasn't been reliable for me, for testing, for a
> while. I tend to exhaust memory somewhere around JSPWikiMarkupParser.
> But I haven't tried it in the last few months (i.e. before my massive
> bug-hunting campaign).
Ah, I always add more memory to these tests: Click on the test runner,
"Run Configurations" -> "Arguments" -> "VM Arguments", add -xmx512m.
/Janne
Re: 2 last failing unit tests
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
Ehm. So "ThisIsAPage" => "This Is APage", "XRay" => "XRay" (and not
"X Ray") and "PresidentUThant" => "President UThant"?
I fail to see where this becomes easier than the current method, which
is fairly straightforward:
1) Clean the page first by collapsing all spaces so that only one
space remains per whitespace sequence. Find a page by that name.
2) IFF the page in 1) did not exist, collapse the rest of the spaces
away, then try finding that page. This keeps it compatible with the
CamelCase syntax and the pre 2.6 -method. We can make this an option
in 3.0, and for new installs, turn it off so they will not create a
legacy.
The beatifyTitle() kind of attempts to do exactly this, but it's not a
particularly efficient and is known to break in several cases.
I also think changing the page names upon import is a bad idea, since
it will e.g. break certain types of search and possible scripts which
might rely on pages named in a certain pattern. I'd say let's keep
the page names as-is, since it's likely that the users have chosen the
pagenames with a particular purpose in mind, and I'd rather not go
around second-guessing them.
/Janne
On Nov 5, 2009, at 18:21 , Andrew Jaquith wrote:
> Yes, that is right. While the examples do look a bit odd, I'd point
> out that MYPAGE in all-caps is an acronym.
>
> There is one refinement we could make to rule (3): add a space when
> an uppercase letter follows a lowercase letter. so PageJSPWiki would
> expand to Page JSPWiki.
>
> That is still fairly simple, while producing good results.
>
> On Nov 5, 2009, at 0:49, Harry Metske <ha...@gmail.com> wrote:
>
>> so that would mean for example :
>>
>> [MYPAGE] => [ M Y P A G E ]
>> [IPPhone] => [ I P Phone]
>> [mypagE] => [mypag E]
>>
>> looks a bit odd to me
>>
>>
>> 2009/11/5 Andrew Jaquith <an...@gmail.com>
>>
>>> I'd define it as "an uppercase latter that follows a non-whitespace
>>> character."
>>>
>>> On Wed, Nov 4, 2009 at 2:52 PM, Harry Metske
>>> <ha...@gmail.com>
>>> wrote:
>>>> agreed on the 1) and 2)
>>>>
>>>> But how exactly do you define "adding a space before each uppercase
>>> letter
>>>> that starts a word" ?
>>>> How do you find this "uppercase letter that starts a word" in a
>>>> pagename
>>> or
>>>> link ?
>>>> Can you give a few samples ?
>>>>
>>>> /Harry
>>>>
>>>> 2009/11/2 Andrew Jaquith <an...@gmail.com>
>>>>
>>>>> Ok, that makes sense. I can think of cases in English too, like
>>>>> "averse" (opposed to) and "a verse" (a portion of a song or
>>>>> poem). I
>>>>> just decided that I didn't care. :)
>>>>>
>>>>> But assuming we do care...
>>>>>
>>>>> ...what about going the other way: on import, or on page save,
>>>>> or page
>>>>> lookup, forcibly expanding CamelCasePageNames (and inline page
>>>>> links)
>>>>> so that they have one space in between the words? That way,
>>>>> case-insensitive matching with spaces preserved (trimmed to one
>>>>> space)
>>>>> would work.
>>>>>
>>>>> So, the rules would be this:
>>>>>
>>>>> (1) When links in pages are parsed, or page names are saved,
>>>>> leading
>>>>> and trailing spaces will be trimmed, and all whitespace between
>>>>> words
>>>>> will be replaced with one space character.
>>>>> (2) Whitespace before and after the space name will be removed.
>>>>> (3) CamelCase page links or page names will be normalize by
>>>>> adding a
>>>>> space before each uppercase letter that starts a word
>>>>> (4) Tests for page name equality are done by applying rules
>>>>> (1) , (2)
>>>>> and (3) and making a case-insensitive comparison.
>>>>>
>>>>> That seems simple enough, no?
>>>>>
>>>>> Andrew
>>>>>
>>>>> On Mon, Nov 2, 2009 at 2:44 PM, Janne Jalkanen <janne.jalkanen@iki.fi
>>>>> >
>>>>> wrote:
>>>>>>> Can you provide some examples where a
>>>>>>> strip-the-whitespace-and-do-a-case-insensitive-comparison
>>>>>>> strategy
>>>>>>> would not work, in Finnish? I'd like to understand this,
>>>>>>> seriously.
>>>>>>
>>>>>> E.g. "maan alle" vs "maanalle". First means "into the ground",
>>>>>> the
>>>>>> next one is "earth bear".
>>>>>>
>>>>>> Or "kuusi puuta" vs "kuusipuuta" - "six trees" vs "at a
>>>>>> fir" (or "of
>>>>>> fir timber").
>>>>>>
>>>>>> Or simply "sivusta katsoja" vs "sivustakatsoja" - "a person who
>>>>>> looks
>>>>>> (literally) from the sides" vs "onlooker". The difference is
>>>>>> subtler
>>>>>> than with the previous ones, but the existence of the space is
>>>>>> significant information.
>>>>>>
>>>>>> In fact, getting mixed up when two words go together and when
>>>>>> they do
>>>>>> not is one of the most common grammatical errors. Sometimes the
>>>>>> results can be fairly hilarious and unintended. Often it looks
>>>>>> just
>>>>>> sad.
>>>>>>
>>>>>> But the point being that in Finnish (and other so-called
>>>>>> constructed
>>>>>> languages), whitespace is significant. So it should not be
>>>>>> ignored
>>>>>> arbitrarily.
>>>>>>
>>>>>> Besids, I am not aware of any wikiengines who would consider
>>>>>> whitespace insignificant in determining pagename equality.
>>> mediawiki's
>>>>>> rules concerning spaces are:
>>>>>>
>>>>>> <snip>
>>>>>> Spaces/underscores which are ignored:
>>>>>> * those at the start and end of a full page name
>>>>>> * those at the end of a namespace prefix, before the colon
>>>>>> * those after the colon of the namespace prefix
>>>>>> * duplicate consecutive spaces
>>>>>> <snap>
>>>>>>
>>>>>>> FYI, I took a look at JSPWiki.org to see what the scale of the
>>> problem
>>>>>>> might be. The site has about 4850 pages. I yanked down all of
>>>>>>> the
>>> page
>>>>>>> names and compared them. I detected exactly ONE name clash:
>>>>>>> "Text
>>>>>>> formatting rulesKorean" and "TextformattingrulesKorean" appear
>>>>>>> to be
>>>>>>> different pages. That is a 0.02% collision rate -- and easily
>>>>>>> handled
>>>>>>> by a rename-on-import or special-page redirection strategy.
>>>>>>
>>>>>> That's not what I meant. I meant that we have many links of
>>>>>> the form
>>>>>> [word1 word2] embedded within running text. If we change
>>>>>> those, then
>>>>>> the running text becomes meaningless and needs to be *checked by
>>>>>> hand*.
>>>>>>
>>>>>> /Janne
>>>>>>
>>>>>
>>>>
>>>
Re: 2 last failing unit tests
Posted by Andrew Jaquith <an...@gmail.com>.
Yes, that is right. While the examples do look a bit odd, I'd point
out that MYPAGE in all-caps is an acronym.
There is one refinement we could make to rule (3): add a space when an
uppercase letter follows a lowercase letter. so PageJSPWiki would
expand to Page JSPWiki.
That is still fairly simple, while producing good results.
On Nov 5, 2009, at 0:49, Harry Metske <ha...@gmail.com> wrote:
> so that would mean for example :
>
> [MYPAGE] => [ M Y P A G E ]
> [IPPhone] => [ I P Phone]
> [mypagE] => [mypag E]
>
> looks a bit odd to me
>
>
> 2009/11/5 Andrew Jaquith <an...@gmail.com>
>
>> I'd define it as "an uppercase latter that follows a non-whitespace
>> character."
>>
>> On Wed, Nov 4, 2009 at 2:52 PM, Harry Metske <ha...@gmail.com>
>> wrote:
>>> agreed on the 1) and 2)
>>>
>>> But how exactly do you define "adding a space before each uppercase
>> letter
>>> that starts a word" ?
>>> How do you find this "uppercase letter that starts a word" in a
>>> pagename
>> or
>>> link ?
>>> Can you give a few samples ?
>>>
>>> /Harry
>>>
>>> 2009/11/2 Andrew Jaquith <an...@gmail.com>
>>>
>>>> Ok, that makes sense. I can think of cases in English too, like
>>>> "averse" (opposed to) and "a verse" (a portion of a song or
>>>> poem). I
>>>> just decided that I didn't care. :)
>>>>
>>>> But assuming we do care...
>>>>
>>>> ...what about going the other way: on import, or on page save, or
>>>> page
>>>> lookup, forcibly expanding CamelCasePageNames (and inline page
>>>> links)
>>>> so that they have one space in between the words? That way,
>>>> case-insensitive matching with spaces preserved (trimmed to one
>>>> space)
>>>> would work.
>>>>
>>>> So, the rules would be this:
>>>>
>>>> (1) When links in pages are parsed, or page names are saved,
>>>> leading
>>>> and trailing spaces will be trimmed, and all whitespace between
>>>> words
>>>> will be replaced with one space character.
>>>> (2) Whitespace before and after the space name will be removed.
>>>> (3) CamelCase page links or page names will be normalize by
>>>> adding a
>>>> space before each uppercase letter that starts a word
>>>> (4) Tests for page name equality are done by applying rules (1) ,
>>>> (2)
>>>> and (3) and making a case-insensitive comparison.
>>>>
>>>> That seems simple enough, no?
>>>>
>>>> Andrew
>>>>
>>>> On Mon, Nov 2, 2009 at 2:44 PM, Janne Jalkanen <janne.jalkanen@iki.fi
>>>> >
>>>> wrote:
>>>>>> Can you provide some examples where a
>>>>>> strip-the-whitespace-and-do-a-case-insensitive-comparison
>>>>>> strategy
>>>>>> would not work, in Finnish? I'd like to understand this,
>>>>>> seriously.
>>>>>
>>>>> E.g. "maan alle" vs "maanalle". First means "into the ground", the
>>>>> next one is "earth bear".
>>>>>
>>>>> Or "kuusi puuta" vs "kuusipuuta" - "six trees" vs "at a fir" (or
>>>>> "of
>>>>> fir timber").
>>>>>
>>>>> Or simply "sivusta katsoja" vs "sivustakatsoja" - "a person who
>>>>> looks
>>>>> (literally) from the sides" vs "onlooker". The difference is
>>>>> subtler
>>>>> than with the previous ones, but the existence of the space is
>>>>> significant information.
>>>>>
>>>>> In fact, getting mixed up when two words go together and when
>>>>> they do
>>>>> not is one of the most common grammatical errors. Sometimes the
>>>>> results can be fairly hilarious and unintended. Often it looks
>>>>> just
>>>>> sad.
>>>>>
>>>>> But the point being that in Finnish (and other so-called
>>>>> constructed
>>>>> languages), whitespace is significant. So it should not be
>>>>> ignored
>>>>> arbitrarily.
>>>>>
>>>>> Besids, I am not aware of any wikiengines who would consider
>>>>> whitespace insignificant in determining pagename equality.
>> mediawiki's
>>>>> rules concerning spaces are:
>>>>>
>>>>> <snip>
>>>>> Spaces/underscores which are ignored:
>>>>> * those at the start and end of a full page name
>>>>> * those at the end of a namespace prefix, before the colon
>>>>> * those after the colon of the namespace prefix
>>>>> * duplicate consecutive spaces
>>>>> <snap>
>>>>>
>>>>>> FYI, I took a look at JSPWiki.org to see what the scale of the
>> problem
>>>>>> might be. The site has about 4850 pages. I yanked down all of the
>> page
>>>>>> names and compared them. I detected exactly ONE name clash: "Text
>>>>>> formatting rulesKorean" and "TextformattingrulesKorean" appear
>>>>>> to be
>>>>>> different pages. That is a 0.02% collision rate -- and easily
>>>>>> handled
>>>>>> by a rename-on-import or special-page redirection strategy.
>>>>>
>>>>> That's not what I meant. I meant that we have many links of the
>>>>> form
>>>>> [word1 word2] embedded within running text. If we change those,
>>>>> then
>>>>> the running text becomes meaningless and needs to be *checked by
>>>>> hand*.
>>>>>
>>>>> /Janne
>>>>>
>>>>
>>>
>>
Re: 2 last failing unit tests
Posted by Harry Metske <ha...@gmail.com>.
so that would mean for example :
[MYPAGE] => [ M Y P A G E ]
[IPPhone] => [ I P Phone]
[mypagE] => [mypag E]
looks a bit odd to me
2009/11/5 Andrew Jaquith <an...@gmail.com>
> I'd define it as "an uppercase latter that follows a non-whitespace
> character."
>
> On Wed, Nov 4, 2009 at 2:52 PM, Harry Metske <ha...@gmail.com>
> wrote:
> > agreed on the 1) and 2)
> >
> > But how exactly do you define "adding a space before each uppercase
> letter
> > that starts a word" ?
> > How do you find this "uppercase letter that starts a word" in a pagename
> or
> > link ?
> > Can you give a few samples ?
> >
> > /Harry
> >
> > 2009/11/2 Andrew Jaquith <an...@gmail.com>
> >
> >> Ok, that makes sense. I can think of cases in English too, like
> >> "averse" (opposed to) and "a verse" (a portion of a song or poem). I
> >> just decided that I didn't care. :)
> >>
> >> But assuming we do care...
> >>
> >> ...what about going the other way: on import, or on page save, or page
> >> lookup, forcibly expanding CamelCasePageNames (and inline page links)
> >> so that they have one space in between the words? That way,
> >> case-insensitive matching with spaces preserved (trimmed to one space)
> >> would work.
> >>
> >> So, the rules would be this:
> >>
> >> (1) When links in pages are parsed, or page names are saved, leading
> >> and trailing spaces will be trimmed, and all whitespace between words
> >> will be replaced with one space character.
> >> (2) Whitespace before and after the space name will be removed.
> >> (3) CamelCase page links or page names will be normalize by adding a
> >> space before each uppercase letter that starts a word
> >> (4) Tests for page name equality are done by applying rules (1) , (2)
> >> and (3) and making a case-insensitive comparison.
> >>
> >> That seems simple enough, no?
> >>
> >> Andrew
> >>
> >> On Mon, Nov 2, 2009 at 2:44 PM, Janne Jalkanen <ja...@iki.fi>
> >> wrote:
> >> >> Can you provide some examples where a
> >> >> strip-the-whitespace-and-do-a-case-insensitive-comparison strategy
> >> >> would not work, in Finnish? I'd like to understand this, seriously.
> >> >
> >> > E.g. "maan alle" vs "maanalle". First means "into the ground", the
> >> > next one is "earth bear".
> >> >
> >> > Or "kuusi puuta" vs "kuusipuuta" - "six trees" vs "at a fir" (or "of
> >> > fir timber").
> >> >
> >> > Or simply "sivusta katsoja" vs "sivustakatsoja" - "a person who looks
> >> > (literally) from the sides" vs "onlooker". The difference is subtler
> >> > than with the previous ones, but the existence of the space is
> >> > significant information.
> >> >
> >> > In fact, getting mixed up when two words go together and when they do
> >> > not is one of the most common grammatical errors. Sometimes the
> >> > results can be fairly hilarious and unintended. Often it looks just
> >> > sad.
> >> >
> >> > But the point being that in Finnish (and other so-called constructed
> >> > languages), whitespace is significant. So it should not be ignored
> >> > arbitrarily.
> >> >
> >> > Besids, I am not aware of any wikiengines who would consider
> >> > whitespace insignificant in determining pagename equality.
> mediawiki's
> >> > rules concerning spaces are:
> >> >
> >> > <snip>
> >> > Spaces/underscores which are ignored:
> >> > * those at the start and end of a full page name
> >> > * those at the end of a namespace prefix, before the colon
> >> > * those after the colon of the namespace prefix
> >> > * duplicate consecutive spaces
> >> > <snap>
> >> >
> >> >> FYI, I took a look at JSPWiki.org to see what the scale of the
> problem
> >> >> might be. The site has about 4850 pages. I yanked down all of the
> page
> >> >> names and compared them. I detected exactly ONE name clash: "Text
> >> >> formatting rulesKorean" and "TextformattingrulesKorean" appear to be
> >> >> different pages. That is a 0.02% collision rate -- and easily handled
> >> >> by a rename-on-import or special-page redirection strategy.
> >> >
> >> > That's not what I meant. I meant that we have many links of the form
> >> > [word1 word2] embedded within running text. If we change those, then
> >> > the running text becomes meaningless and needs to be *checked by
> >> > hand*.
> >> >
> >> > /Janne
> >> >
> >>
> >
>
Re: 2 last failing unit tests
Posted by Dirk Frederickx <di...@gmail.com>.
What about "ThisIsANiceJSPWikiPage" ?
dirk.
Op 05 Nov 2009 om 03:49 heeft Andrew Jaquith
<an...@gmail.com> het volgende geschreven:\
> I'd define it as "an uppercase latter that follows a non-whitespace
> character."
>
> On Wed, Nov 4, 2009 at 2:52 PM, Harry Metske
> <ha...@gmail.com> wrote:
>> agreed on the 1) and 2)
>>
>> But how exactly do you define "adding a space before each uppercase
>> letter
>> that starts a word" ?
>> How do you find this "uppercase letter that starts a word" in a
>> pagename or
>> link ?
>> Can you give a few samples ?
>>
>> /Harry
>>
>> 2009/11/2 Andrew Jaquith <an...@gmail.com>
>>
>>> Ok, that makes sense. I can think of cases in English too, like
>>> "averse" (opposed to) and "a verse" (a portion of a song or poem). I
>>> just decided that I didn't care. :)
>>>
>>> But assuming we do care...
>>>
>>> ...what about going the other way: on import, or on page save, or
>>> page
>>> lookup, forcibly expanding CamelCasePageNames (and inline page
>>> links)
>>> so that they have one space in between the words? That way,
>>> case-insensitive matching with spaces preserved (trimmed to one
>>> space)
>>> would work.
>>>
>>> So, the rules would be this:
>>>
>>> (1) When links in pages are parsed, or page names are saved, leading
>>> and trailing spaces will be trimmed, and all whitespace between
>>> words
>>> will be replaced with one space character.
>>> (2) Whitespace before and after the space name will be removed.
>>> (3) CamelCase page links or page names will be normalize by adding a
>>> space before each uppercase letter that starts a word
>>> (4) Tests for page name equality are done by applying rules (1) ,
>>> (2)
>>> and (3) and making a case-insensitive comparison.
>>>
>>> That seems simple enough, no?
>>>
>>> Andrew
>>>
>>> On Mon, Nov 2, 2009 at 2:44 PM, Janne Jalkanen <janne.jalkanen@iki.fi
>>> >
>>> wrote:
>>>>> Can you provide some examples where a
>>>>> strip-the-whitespace-and-do-a-case-insensitive-comparison strategy
>>>>> would not work, in Finnish? I'd like to understand this,
>>>>> seriously.
>>>>
>>>> E.g. "maan alle" vs "maanalle". First means "into the ground", the
>>>> next one is "earth bear".
>>>>
>>>> Or "kuusi puuta" vs "kuusipuuta" - "six trees" vs "at a fir" (or
>>>> "of
>>>> fir timber").
>>>>
>>>> Or simply "sivusta katsoja" vs "sivustakatsoja" - "a person who
>>>> looks
>>>> (literally) from the sides" vs "onlooker". The difference is
>>>> subtler
>>>> than with the previous ones, but the existence of the space is
>>>> significant information.
>>>>
>>>> In fact, getting mixed up when two words go together and when
>>>> they do
>>>> not is one of the most common grammatical errors. Sometimes the
>>>> results can be fairly hilarious and unintended. Often it looks
>>>> just
>>>> sad.
>>>>
>>>> But the point being that in Finnish (and other so-called
>>>> constructed
>>>> languages), whitespace is significant. So it should not be ignored
>>>> arbitrarily.
>>>>
>>>> Besids, I am not aware of any wikiengines who would consider
>>>> whitespace insignificant in determining pagename equality.
>>>> mediawiki's
>>>> rules concerning spaces are:
>>>>
>>>> <snip>
>>>> Spaces/underscores which are ignored:
>>>> * those at the start and end of a full page name
>>>> * those at the end of a namespace prefix, before the colon
>>>> * those after the colon of the namespace prefix
>>>> * duplicate consecutive spaces
>>>> <snap>
>>>>
>>>>> FYI, I took a look at JSPWiki.org to see what the scale of the
>>>>> problem
>>>>> might be. The site has about 4850 pages. I yanked down all of
>>>>> the page
>>>>> names and compared them. I detected exactly ONE name clash: "Text
>>>>> formatting rulesKorean" and "TextformattingrulesKorean" appear
>>>>> to be
>>>>> different pages. That is a 0.02% collision rate -- and easily
>>>>> handled
>>>>> by a rename-on-import or special-page redirection strategy.
>>>>
>>>> That's not what I meant. I meant that we have many links of the
>>>> form
>>>> [word1 word2] embedded within running text. If we change those,
>>>> then
>>>> the running text becomes meaningless and needs to be *checked by
>>>> hand*.
>>>>
>>>> /Janne
>>>>
>>>
>>
Re: 2 last failing unit tests
Posted by Andrew Jaquith <an...@gmail.com>.
I'd define it as "an uppercase latter that follows a non-whitespace character."
On Wed, Nov 4, 2009 at 2:52 PM, Harry Metske <ha...@gmail.com> wrote:
> agreed on the 1) and 2)
>
> But how exactly do you define "adding a space before each uppercase letter
> that starts a word" ?
> How do you find this "uppercase letter that starts a word" in a pagename or
> link ?
> Can you give a few samples ?
>
> /Harry
>
> 2009/11/2 Andrew Jaquith <an...@gmail.com>
>
>> Ok, that makes sense. I can think of cases in English too, like
>> "averse" (opposed to) and "a verse" (a portion of a song or poem). I
>> just decided that I didn't care. :)
>>
>> But assuming we do care...
>>
>> ...what about going the other way: on import, or on page save, or page
>> lookup, forcibly expanding CamelCasePageNames (and inline page links)
>> so that they have one space in between the words? That way,
>> case-insensitive matching with spaces preserved (trimmed to one space)
>> would work.
>>
>> So, the rules would be this:
>>
>> (1) When links in pages are parsed, or page names are saved, leading
>> and trailing spaces will be trimmed, and all whitespace between words
>> will be replaced with one space character.
>> (2) Whitespace before and after the space name will be removed.
>> (3) CamelCase page links or page names will be normalize by adding a
>> space before each uppercase letter that starts a word
>> (4) Tests for page name equality are done by applying rules (1) , (2)
>> and (3) and making a case-insensitive comparison.
>>
>> That seems simple enough, no?
>>
>> Andrew
>>
>> On Mon, Nov 2, 2009 at 2:44 PM, Janne Jalkanen <ja...@iki.fi>
>> wrote:
>> >> Can you provide some examples where a
>> >> strip-the-whitespace-and-do-a-case-insensitive-comparison strategy
>> >> would not work, in Finnish? I'd like to understand this, seriously.
>> >
>> > E.g. "maan alle" vs "maanalle". First means "into the ground", the
>> > next one is "earth bear".
>> >
>> > Or "kuusi puuta" vs "kuusipuuta" - "six trees" vs "at a fir" (or "of
>> > fir timber").
>> >
>> > Or simply "sivusta katsoja" vs "sivustakatsoja" - "a person who looks
>> > (literally) from the sides" vs "onlooker". The difference is subtler
>> > than with the previous ones, but the existence of the space is
>> > significant information.
>> >
>> > In fact, getting mixed up when two words go together and when they do
>> > not is one of the most common grammatical errors. Sometimes the
>> > results can be fairly hilarious and unintended. Often it looks just
>> > sad.
>> >
>> > But the point being that in Finnish (and other so-called constructed
>> > languages), whitespace is significant. So it should not be ignored
>> > arbitrarily.
>> >
>> > Besids, I am not aware of any wikiengines who would consider
>> > whitespace insignificant in determining pagename equality. mediawiki's
>> > rules concerning spaces are:
>> >
>> > <snip>
>> > Spaces/underscores which are ignored:
>> > * those at the start and end of a full page name
>> > * those at the end of a namespace prefix, before the colon
>> > * those after the colon of the namespace prefix
>> > * duplicate consecutive spaces
>> > <snap>
>> >
>> >> FYI, I took a look at JSPWiki.org to see what the scale of the problem
>> >> might be. The site has about 4850 pages. I yanked down all of the page
>> >> names and compared them. I detected exactly ONE name clash: "Text
>> >> formatting rulesKorean" and "TextformattingrulesKorean" appear to be
>> >> different pages. That is a 0.02% collision rate -- and easily handled
>> >> by a rename-on-import or special-page redirection strategy.
>> >
>> > That's not what I meant. I meant that we have many links of the form
>> > [word1 word2] embedded within running text. If we change those, then
>> > the running text becomes meaningless and needs to be *checked by
>> > hand*.
>> >
>> > /Janne
>> >
>>
>
Re: 2 last failing unit tests
Posted by Harry Metske <ha...@gmail.com>.
agreed on the 1) and 2)
But how exactly do you define "adding a space before each uppercase letter
that starts a word" ?
How do you find this "uppercase letter that starts a word" in a pagename or
link ?
Can you give a few samples ?
/Harry
2009/11/2 Andrew Jaquith <an...@gmail.com>
> Ok, that makes sense. I can think of cases in English too, like
> "averse" (opposed to) and "a verse" (a portion of a song or poem). I
> just decided that I didn't care. :)
>
> But assuming we do care...
>
> ...what about going the other way: on import, or on page save, or page
> lookup, forcibly expanding CamelCasePageNames (and inline page links)
> so that they have one space in between the words? That way,
> case-insensitive matching with spaces preserved (trimmed to one space)
> would work.
>
> So, the rules would be this:
>
> (1) When links in pages are parsed, or page names are saved, leading
> and trailing spaces will be trimmed, and all whitespace between words
> will be replaced with one space character.
> (2) Whitespace before and after the space name will be removed.
> (3) CamelCase page links or page names will be normalize by adding a
> space before each uppercase letter that starts a word
> (4) Tests for page name equality are done by applying rules (1) , (2)
> and (3) and making a case-insensitive comparison.
>
> That seems simple enough, no?
>
> Andrew
>
> On Mon, Nov 2, 2009 at 2:44 PM, Janne Jalkanen <ja...@iki.fi>
> wrote:
> >> Can you provide some examples where a
> >> strip-the-whitespace-and-do-a-case-insensitive-comparison strategy
> >> would not work, in Finnish? I'd like to understand this, seriously.
> >
> > E.g. "maan alle" vs "maanalle". First means "into the ground", the
> > next one is "earth bear".
> >
> > Or "kuusi puuta" vs "kuusipuuta" - "six trees" vs "at a fir" (or "of
> > fir timber").
> >
> > Or simply "sivusta katsoja" vs "sivustakatsoja" - "a person who looks
> > (literally) from the sides" vs "onlooker". The difference is subtler
> > than with the previous ones, but the existence of the space is
> > significant information.
> >
> > In fact, getting mixed up when two words go together and when they do
> > not is one of the most common grammatical errors. Sometimes the
> > results can be fairly hilarious and unintended. Often it looks just
> > sad.
> >
> > But the point being that in Finnish (and other so-called constructed
> > languages), whitespace is significant. So it should not be ignored
> > arbitrarily.
> >
> > Besids, I am not aware of any wikiengines who would consider
> > whitespace insignificant in determining pagename equality. mediawiki's
> > rules concerning spaces are:
> >
> > <snip>
> > Spaces/underscores which are ignored:
> > * those at the start and end of a full page name
> > * those at the end of a namespace prefix, before the colon
> > * those after the colon of the namespace prefix
> > * duplicate consecutive spaces
> > <snap>
> >
> >> FYI, I took a look at JSPWiki.org to see what the scale of the problem
> >> might be. The site has about 4850 pages. I yanked down all of the page
> >> names and compared them. I detected exactly ONE name clash: "Text
> >> formatting rulesKorean" and "TextformattingrulesKorean" appear to be
> >> different pages. That is a 0.02% collision rate -- and easily handled
> >> by a rename-on-import or special-page redirection strategy.
> >
> > That's not what I meant. I meant that we have many links of the form
> > [word1 word2] embedded within running text. If we change those, then
> > the running text becomes meaningless and needs to be *checked by
> > hand*.
> >
> > /Janne
> >
>
Re: 2 last failing unit tests
Posted by Andrew Jaquith <an...@gmail.com>.
Ok, that makes sense. I can think of cases in English too, like
"averse" (opposed to) and "a verse" (a portion of a song or poem). I
just decided that I didn't care. :)
But assuming we do care...
...what about going the other way: on import, or on page save, or page
lookup, forcibly expanding CamelCasePageNames (and inline page links)
so that they have one space in between the words? That way,
case-insensitive matching with spaces preserved (trimmed to one space)
would work.
So, the rules would be this:
(1) When links in pages are parsed, or page names are saved, leading
and trailing spaces will be trimmed, and all whitespace between words
will be replaced with one space character.
(2) Whitespace before and after the space name will be removed.
(3) CamelCase page links or page names will be normalize by adding a
space before each uppercase letter that starts a word
(4) Tests for page name equality are done by applying rules (1) , (2)
and (3) and making a case-insensitive comparison.
That seems simple enough, no?
Andrew
On Mon, Nov 2, 2009 at 2:44 PM, Janne Jalkanen <ja...@iki.fi> wrote:
>> Can you provide some examples where a
>> strip-the-whitespace-and-do-a-case-insensitive-comparison strategy
>> would not work, in Finnish? I'd like to understand this, seriously.
>
> E.g. "maan alle" vs "maanalle". First means "into the ground", the
> next one is "earth bear".
>
> Or "kuusi puuta" vs "kuusipuuta" - "six trees" vs "at a fir" (or "of
> fir timber").
>
> Or simply "sivusta katsoja" vs "sivustakatsoja" - "a person who looks
> (literally) from the sides" vs "onlooker". The difference is subtler
> than with the previous ones, but the existence of the space is
> significant information.
>
> In fact, getting mixed up when two words go together and when they do
> not is one of the most common grammatical errors. Sometimes the
> results can be fairly hilarious and unintended. Often it looks just
> sad.
>
> But the point being that in Finnish (and other so-called constructed
> languages), whitespace is significant. So it should not be ignored
> arbitrarily.
>
> Besids, I am not aware of any wikiengines who would consider
> whitespace insignificant in determining pagename equality. mediawiki's
> rules concerning spaces are:
>
> <snip>
> Spaces/underscores which are ignored:
> * those at the start and end of a full page name
> * those at the end of a namespace prefix, before the colon
> * those after the colon of the namespace prefix
> * duplicate consecutive spaces
> <snap>
>
>> FYI, I took a look at JSPWiki.org to see what the scale of the problem
>> might be. The site has about 4850 pages. I yanked down all of the page
>> names and compared them. I detected exactly ONE name clash: "Text
>> formatting rulesKorean" and "TextformattingrulesKorean" appear to be
>> different pages. That is a 0.02% collision rate -- and easily handled
>> by a rename-on-import or special-page redirection strategy.
>
> That's not what I meant. I meant that we have many links of the form
> [word1 word2] embedded within running text. If we change those, then
> the running text becomes meaningless and needs to be *checked by
> hand*.
>
> /Janne
>
Re: 2 last failing unit tests
Posted by Janne Jalkanen <ja...@iki.fi>.
> Can you provide some examples where a
> strip-the-whitespace-and-do-a-case-insensitive-comparison strategy
> would not work, in Finnish? I'd like to understand this, seriously.
E.g. "maan alle" vs "maanalle". First means "into the ground", the
next one is "earth bear".
Or "kuusi puuta" vs "kuusipuuta" - "six trees" vs "at a fir" (or "of
fir timber").
Or simply "sivusta katsoja" vs "sivustakatsoja" - "a person who looks
(literally) from the sides" vs "onlooker". The difference is subtler
than with the previous ones, but the existence of the space is
significant information.
In fact, getting mixed up when two words go together and when they do
not is one of the most common grammatical errors. Sometimes the
results can be fairly hilarious and unintended. Often it looks just
sad.
But the point being that in Finnish (and other so-called constructed
languages), whitespace is significant. So it should not be ignored
arbitrarily.
Besids, I am not aware of any wikiengines who would consider
whitespace insignificant in determining pagename equality. mediawiki's
rules concerning spaces are:
<snip>
Spaces/underscores which are ignored:
* those at the start and end of a full page name
* those at the end of a namespace prefix, before the colon
* those after the colon of the namespace prefix
* duplicate consecutive spaces
<snap>
> FYI, I took a look at JSPWiki.org to see what the scale of the problem
> might be. The site has about 4850 pages. I yanked down all of the page
> names and compared them. I detected exactly ONE name clash: "Text
> formatting rulesKorean" and "TextformattingrulesKorean" appear to be
> different pages. That is a 0.02% collision rate -- and easily handled
> by a rename-on-import or special-page redirection strategy.
That's not what I meant. I meant that we have many links of the form
[word1 word2] embedded within running text. If we change those, then
the running text becomes meaningless and needs to be *checked by
hand*.
/Janne
Re: 2 last failing unit tests
Posted by Andrew Jaquith <an...@gmail.com>.
Agreed on the side-effect of (3).
As for burden on end-users, don't you think that the current scheme is
confusing? I do. In the sense that I can't explain it simply...
Can you provide some examples where a
strip-the-whitespace-and-do-a-case-insensitive-comparison strategy
would not work, in Finnish? I'd like to understand this, seriously.
FYI, I took a look at JSPWiki.org to see what the scale of the problem
might be. The site has about 4850 pages. I yanked down all of the page
names and compared them. I detected exactly ONE name clash: "Text
formatting rulesKorean" and "TextformattingrulesKorean" appear to be
different pages. That is a 0.02% collision rate -- and easily handled
by a rename-on-import or special-page redirection strategy.
Andrew
On Mon, Nov 2, 2009 at 1:27 PM, Janne Jalkanen <ja...@iki.fi> wrote:
>> (1) Pages with spaces in their names are normalized so that any
>> consecutive whitespace is changed to one space character. Cases would
>> be preserved on storage.
>
> Good.
>
>> (2) Comparisons would be done by stripping out all whitespace and
>> doing a case-insensitive comparisons
>
> Not a good idea for Finnish language as it will create name clashes for
> things which are not actually relevant. Strong -1, as it'll
> potentially make JSPWiki unusable for myself. (This is probably true
> also for many other languages which depend a lot on word composition.)
>
> (Case-insensitive comparisons are fine. Stripping out whitespace
> before doing comparisons = bad.)
>
>> (3) When the page repository is migrated, on import, "clashing" links
>> would be modified so that they do not conflict. So if two pages called
>> "A test" and "atest" existed, the second one would be renamed to
>> "atest_2" (as would all its references).
>
> I have some experience in a case where we did this. The amount of
> confusion was pretty bad afterwards. This should be avoided.
>
> I believe there are two things we shouldn't change for 3.0:
> * permalinks
> * Existing wiki pages
>
> Especially in large wikis changing the wiki page format will mean a
> lot of work for the users. And we really don't want to add to the
> burden of the users.
>
> Note that your (3) means that some permalinks might be broken.
>
> /Janne
>
Re: 2 last failing unit tests
Posted by Janne Jalkanen <ja...@iki.fi>.
> (1) Pages with spaces in their names are normalized so that any
> consecutive whitespace is changed to one space character. Cases would
> be preserved on storage.
Good.
> (2) Comparisons would be done by stripping out all whitespace and
> doing a case-insensitive comparisons
Not a good idea for Finnish language as it will create name clashes for
things which are not actually relevant. Strong -1, as it'll
potentially make JSPWiki unusable for myself. (This is probably true
also for many other languages which depend a lot on word composition.)
(Case-insensitive comparisons are fine. Stripping out whitespace
before doing comparisons = bad.)
> (3) When the page repository is migrated, on import, "clashing" links
> would be modified so that they do not conflict. So if two pages called
> "A test" and "atest" existed, the second one would be renamed to
> "atest_2" (as would all its references).
I have some experience in a case where we did this. The amount of
confusion was pretty bad afterwards. This should be avoided.
I believe there are two things we shouldn't change for 3.0:
* permalinks
* Existing wiki pages
Especially in large wikis changing the wiki page format will mean a
lot of work for the users. And we really don't want to add to the
burden of the users.
Note that your (3) means that some permalinks might be broken.
/Janne
Re: 2 last failing unit tests
Posted by Andrew Jaquith <an...@gmail.com>.
This discussion is losing sight of an important point. We have a
unique opportunity with 3.0 to do whatever we want. After all, admins
will need to import all of their pages from 2.x into 3.0. When that
happens, we can do any normalization that is needed.
So, I'd urge us to think carefully about this issue. I don't want
"fuzzy logic" because too often that means fuzzy thinking. We should
strive for the simplest page-resolution algorithm we can design, with
the fewest special cases. The current 3.0 scheme is too complex.
My suggested strategy would be to have a simple naming and resolution
scheme, and fix with the edge cases at migration time. There are only
two rules:
(1) Pages with spaces in their names are normalized so that any
consecutive whitespace is changed to one space character. Cases would
be preserved on storage.
(2) Comparisons would be done by stripping out all whitespace and
doing a case-insensitive comparisons
To ensure that these two rules can be enforced, we need to deal with
the edge cases. So, I suggest that:
(3) When the page repository is migrated, on import, "clashing" links
would be modified so that they do not conflict. So if two pages called
"A test" and "atest" existed, the second one would be renamed to
"atest_2" (as would all its references).
I think this would simplify things nicely.
Andrew
On Mon, Nov 2, 2009 at 12:05 PM, Janne Jalkanen <ja...@iki.fi> wrote:
>> The fuzzy logic you are talking about, where we leave out blanks, should go
>> away too, +1 from me too. (which component holds that logic BTW ?)
>
> I don't think getting rid of that would be a good idea, as it would
> break a LOT of old links.
>
> The problem is that [links like this] (which in the old days would
> link to "LinksLikeThis") would stop working. e.g. jspwiki.org uses
> these quite a lot.
>
> We can make it an option, but I would not leave it out.
>
> /Janne
>
Re: 2 last failing unit tests
Posted by Janne Jalkanen <ja...@iki.fi>.
> The fuzzy logic you are talking about, where we leave out blanks, should go
> away too, +1 from me too. (which component holds that logic BTW ?)
I don't think getting rid of that would be a good idea, as it would
break a LOT of old links.
The problem is that [links like this] (which in the old days would
link to "LinksLikeThis") would stop working. e.g. jspwiki.org uses
these quite a lot.
We can make it an option, but I would not leave it out.
/Janne
Re: 2 last failing unit tests
Posted by Harry Metske <ha...@gmail.com>.
uhm yes indeed, I meant case-insensitive (how confusing :-) )
camelCaseLinks could be left untouched if page names become
case-insensitive, and is in fact irrelevant here.
The fuzzy logic you are talking about, where we leave out blanks, should go
away too, +1 from me too. (which component holds that logic BTW ?)
/Harry
2009/11/1 Florian Holeczek <fl...@holeczek.de>
> Hi Harry,
>
> > +1 for me for becoming completely case-sensitive, I understand that
> > this will break compatibility with 2.8 a bit more, but it would makes
> > things simpler I think.
>
> eeehm... you mean case insensitive I guess?
>
> Janne wrote case insensitive and that's where my +1 goes :-)
>
> > BTW: Is the same discussion true for camelCaseLinks and
> > matchEnglishPlurals, and if so, should we drop that too ?
>
> Good question. My thoughts: For linking without special markup, one
> needs such a notation. But that's the frontend, and we're talking about
> making the backend case-insensitive. So MyCamelCaseLink would simply be
> mapped to the case-insensitive internal name, e.g. mycamelcaselink.
>
> I'm wondering about what to do with this special fuzzy logic of mapping
> "My Test Page" to "MyTestPage". I think this piece of code is
> responsible for many oddities and although it means breaking backwards
> compatibility even more, removing it would be best.
>
> Regards
> Florian
>
>
Re: 2 last failing unit tests
Posted by Florian Holeczek <fl...@holeczek.de>.
Hi Harry,
> +1 for me for becoming completely case-sensitive, I understand that
> this will break compatibility with 2.8 a bit more, but it would makes
> things simpler I think.
eeehm... you mean case insensitive I guess?
Janne wrote case insensitive and that's where my +1 goes :-)
> BTW: Is the same discussion true for camelCaseLinks and
> matchEnglishPlurals, and if so, should we drop that too ?
Good question. My thoughts: For linking without special markup, one
needs such a notation. But that's the frontend, and we're talking about
making the backend case-insensitive. So MyCamelCaseLink would simply be
mapped to the case-insensitive internal name, e.g. mycamelcaselink.
I'm wondering about what to do with this special fuzzy logic of mapping
"My Test Page" to "MyTestPage". I think this piece of code is
responsible for many oddities and although it means breaking backwards
compatibility even more, removing it would be best.
Regards
Florian
Re: 2 last failing unit tests
Posted by Harry Metske <ha...@gmail.com>.
+1 for me for becoming completely case-sensitive, I understand that this
will break compatibility with 2.8 a bit more, but it would makes things
simpler I think.
BTW: Is the same discussion true for camelCaseLinks and matchEnglishPlurals,
and if so, should we drop that too ?
/Harry
2009/10/31 Janne Jalkanen <Ja...@ecyrd.com>
>
> Almost. JCR is by definition case-sensitive, and the underlying
> implementation enforces that (the pages could very well be in a JDBC
> database). So the exact details how Priha stores the data is unimportant.
>
> The problem is that JSPWiki as currently written is case-sensitive, which
> means that using links like [this page] and [This page] and [This Page]
> actually refer to different pages. We just do some magic where we normalize
> the page names to some casing rules, but that is breaking down right now,
> and is not really case-insensitive. It's just a guess and causes all sorts
> of interesting problems like with ReferenceManager (e.g. when the page does
> not exist, what exactly should the right spelling be?)
>
> So I think the correct solution for 3.0 should be just to define that page
> names are case insensitive.
>
> (To convolute the thing slightly, in English a normalization where all
> words are capitalized, e.g. "This Is A Page" is okay, since that's the way
> you write headlines. However, in Finnish this kind of normalization is
> simply wrong and looks really bad. Case insensitivity solves this problem
> neatly.)
>
> /Janne
>
>
> On Oct 31, 2009, at 20:29 , Harry Metske wrote:
>
> let me see if I understand this problem correctly:
>>
>> We currently save the name and the case of a PageName in the name of file
>> (2.8) or the name of a directory (3.0 / priha), right ?
>> If you run on a platform that is not (completely) case-sensitive with
>> regard
>> to file/dir names, this get's us into trouble, right ?
>> If that's the case and we want the preserve platform neutrality, we should
>> use something else to hold the name and case of pagenames, and wiki:title
>> seems a proper solution for that.
>>
>> /Harry
>>
>> 2009/10/31 Janne Jalkanen <Ja...@ecyrd.com>
>>
>> Yup, getting back on this...
>>>
>>> It seems to me that the following patch fixes the issue, BUT it does
>>> expose
>>> quite a lot of other problems, mostly related to the fact that JSPWiki
>>> (and
>>> our tests) assume that page names stay in the same case as it was
>>> created.
>>> However, if we lowercase all page names as they are stored, the case
>>> information is lost. If we do not, then there's no way that we can
>>> really
>>> get the JCR name from an arbitrarily cased page name.
>>>
>>> One possibility is to add a new attribute, "wiki:title", which would
>>> contain the page name as originally created, and would be the "display"
>>> name.
>>>
>>> /Janne
>>>
>>> ### Eclipse Workspace Patch 1.0
>>> #P JSPWiki
>>> Index: src/java/org/apache/wiki/content/WikiPath.java
>>> ===================================================================
>>> --- src/java/org/apache/wiki/content/WikiPath.java (revision 831483)
>>> +++ src/java/org/apache/wiki/content/WikiPath.java (working copy)
>>> @@ -193,22 +193,24 @@
>>> * String representation. This is to fulfil the general contract of
>>> * equals().
>>> *
>>> - * @return int
>>> + * @return {@inheritDoc}
>>> */
>>> + // FIXME: Slow, since it creates a new String every time.
>>> public int hashCode()
>>> {
>>> - return m_stringRepresentation.hashCode();
>>> + return m_stringRepresentation.toLowerCase().hashCode();
>>> }
>>>
>>> /**
>>> * A WikiPath is compared using it's toString() method.
>>> *
>>> * @param o The Object to compare against.
>>> - * @return int
>>> + * @return {@inheritDoc}
>>> */
>>> + // FIXME: Slow, since it creates a new String every time.
>>> public int compareTo( WikiPath o )
>>> {
>>> - return toString().compareTo( o.toString() );
>>> + return toString().toLowerCase().compareTo(
>>> o.toString().toLowerCase() );
>>> }
>>>
>>> /**
>>> @@ -226,11 +228,11 @@
>>> {
>>> WikiPath n = (WikiPath) o;
>>>
>>> - return m_space.equals( n.m_space ) && m_path.equals(
>>> n.m_path
>>> );
>>> + return m_space.equalsIgnoreCase( n.m_space ) &&
>>> m_path.equalsIgnoreCase( n.m_path );
>>> }
>>> else if( o instanceof String )
>>> {
>>> - return toString().equals( o );
>>> + return toString().equalsIgnoreCase( (String)o );
>>> }
>>> return false;
>>> }
>>> Index: src/java/org/apache/wiki/content/ContentManager.java
>>> ===================================================================
>>> --- src/java/org/apache/wiki/content/ContentManager.java (revision
>>> 831483)
>>> +++ src/java/org/apache/wiki/content/ContentManager.java (working
>>> copy)
>>> @@ -113,7 +113,7 @@
>>> */
>>> public static final String DEFAULT_SPACE = "Main";
>>>
>>> - private static final String JCR_DEFAULT_SPACE =
>>> "pages/"+DEFAULT_SPACE;
>>> + private static final String JCR_DEFAULT_SPACE =
>>> "pages/"+DEFAULT_SPACE.toLowerCase();
>>>
>>> private static final String JCR_PAGES_NODE = "pages";
>>>
>>> @@ -1433,8 +1433,8 @@
>>> String spaceName;
>>> String spacePath;
>>>
>>> - spaceName = wikiName.getSpace();
>>> - spacePath = wikiName.getPath();
>>> + spaceName = wikiName.getSpace().toLowerCase();
>>> + spacePath = wikiName.getPath().toLowerCase();
>>>
>>> return "/"+JCR_PAGES_NODE+"/"+spaceName+"/"+spacePath;
>>>
>>> }
>>>
>>>
>>> On Oct 28, 2009, at 22:25 , Janne Jalkanen wrote:
>>>
>>>
>>> Hm. This seems to be a bug in JSPWiki, actually. JCR Names *are* case
>>>> sensitive, so we should actually be normalizing the name to "this is a
>>>> test". The fact that it's created with an upper-case name suggests that
>>>> JSPWiki is not normalizing the name properly.
>>>>
>>>> /Janne
>>>>
>>>> On Oct 28, 2009, at 20:17 , Harry Metske wrote:
>>>>
>>>> frustrated by the one remaining failing unit test I took a closer look
>>>> at
>>>>
>>>>> why WikiEngineTest.testSpacedNames1() fails.
>>>>> I can only conclude that 2 of the 3 tests are wrong.
>>>>> First a page is created with name "This is a test", this eventually
>>>>> resulting in a directory being created somewhere deep down the priha
>>>>> repo
>>>>> :
>>>>>
>>>>> metskem@gneisenau
>>>>> ~/workspace/JSPWiki/build/tests/priha/workspaces/jspwiki/pages/Main
>>>>> $ ls -l
>>>>> total 12
>>>>> -rw-r--r-- 1 metskem metskem 43 2009-10-28 17:55 jcr:primaryType.data
>>>>> -rw-r--r-- 1 metskem metskem 82 2009-10-28 17:55 jcr:primaryType.info
>>>>> drwxr-xr-x 2 metskem metskem 4096 2009-10-28 19:07 This is a test
>>>>>
>>>>> Then we do 3 tests:
>>>>>
>>>>> assertEquals( "normal", "puppaa", m_engine.getText("This is a
>>>>> test").trim() );
>>>>> assertEquals( "lowercase", "puppaa", m_engine.getText("this is a
>>>>> test").trim() );
>>>>> assertEquals( "randomcase", "puppaa", m_engine.getText("ThiS Is a
>>>>> teSt").trim() );
>>>>>
>>>>> Only the first one succeeds, the second and third one fail ( of course
>>>>> I
>>>>> would say), at least on Linux with priha, file/dir names are case
>>>>> sensitive.
>>>>>
>>>>> What am I missing, and if nothing, can I remove the last two tests ?
>>>>>
>>>>> thanks,
>>>>> Harry
>>>>>
>>>>> 2009/10/27 Harry Metske <ha...@gmail.com>
>>>>>
>>>>> I just did a fresh svn checkout, and ran "ant clean tests" from the
>>>>>
>>>>>> cmdline.
>>>>>> This gives me 3 failures and 13 errors:
>>>>>> http://www.computerhok.nl/tmp/junit-noframes.html
>>>>>>
>>>>>> The WikiEngineTest.testSpacedNames1() always fails (Linux versus
>>>>>> Mac/Windows)
>>>>>>
>>>>>> Here's an overview of more tests :
>>>>>> http://www.computerhok.nl/tmp/jspwiki-testresult.html
>>>>>>
>>>>>> regards,
>>>>>> Harry
>>>>>>
>>>>>> 2009/10/27 Andrew Jaquith <an...@gmail.com>
>>>>>>
>>>>>> Sounds like we have a few issues here:
>>>>>>
>>>>>>
>>>>>>> 1) Guitests. I'll see what I can find. Probably something minor. I
>>>>>>> know the "tests" target runs all test classes ending in "*Test" and
>>>>>>> ignores "AllTests", while Eclipse (and probably guitests) just runs
>>>>>>> the AllTests classes. It's likely that one or more of the AllTests
>>>>>>> classes is failing to include, oh, about 34 tests. :)
>>>>>>>
>>>>>>> 2) Graceful LDAP fail (inside the tests themselves). Any ideas on how
>>>>>>> to implement? The easy way would be to look for a localhost listener
>>>>>>> on 4890 (where the OpenLDAP test fixture listens) and then not run
>>>>>>> the
>>>>>>> tests if it isn't found. Should they FAIL or PASS in that case? It
>>>>>>> sounds like passing is the right thing to do.
>>>>>>>
>>>>>>> 3) Differences in your test pass rate versus mine. Not sure why your
>>>>>>> "ant tests" run would produce different results than mine. I did try
>>>>>>> running mine with a completely new, checked-out branch. Because I
>>>>>>> can't know what changes you might have in your local branch, could
>>>>>>> you
>>>>>>> check out a clean copy and diff the tree versus yours? SOMETHING is
>>>>>>> different. Also, I'd like to know what Harry and others are seeing.
>>>>>>> Gents, any clues?
>>>>>>>
>>>>>>> I agree that all three methods should return the same number of test
>>>>>>> cases, and pass/fail the same ways. I also agree that tests should be
>>>>>>> self-contained. That was part of the rationale for the Ant script
>>>>>>> tweaks I checked in recently.
>>>>>>>
>>>>>>> Eclipse, by the way, hasn't been reliable for me, for testing, for a
>>>>>>> while. I tend to exhaust memory somewhere around JSPWikiMarkupParser.
>>>>>>> But I haven't tried it in the last few months (i.e. before my massive
>>>>>>> bug-hunting campaign).
>>>>>>>
>>>>>>> Andrew
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Oct 27, 2009 at 3:25 AM, Janne Jalkanen
>>>>>>> <Ja...@ecyrd.com> wrote:
>>>>>>>
>>>>>>> Interestingly, I applied your most recent checkins applied (and I
>>>>>>>> have
>>>>>>>>
>>>>>>>>> small one patch to JSPWikiMarkupParserTest that I haven't checked
>>>>>>>>> in).
>>>>>>>>> I am running 100% clean, with no errors. Total number of tests:
>>>>>>>>> 1024
>>>>>>>>> -- a nice round number. :) WikiEngineTest.testOldVersionVars has
>>>>>>>>> been running fine for me for a while.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> There's no way it should've run, unless you have some old
>>>>>>>> code/config
>>>>>>>>
>>>>>>>> files
>>>>>>>
>>>>>>> lying around. Can you check out a previous version to a clean
>>>>>>>> directory
>>>>>>>>
>>>>>>>> and
>>>>>>>
>>>>>>> see if it runs?
>>>>>>>>
>>>>>>>> As a control case, I also checked out a new built from trunk, and
>>>>>>>>
>>>>>>>>> simply typed 'ant tests'. I used a vanilla build with absolutely no
>>>>>>>>> customizations, even to build.properties. It ran completely clean
>>>>>>>>> also
>>>>>>>>> except for 1 JSPWikiMarkupParserTest test (because I haven't
>>>>>>>>> checked
>>>>>>>>> in that fix), 1024 tests total.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Running the AllTests from Eclipse or with "ant guitests" results in
>>>>>>>> 990
>>>>>>>>
>>>>>>>> test
>>>>>>>
>>>>>>> cases. "ant tests" is the only one giving 1024 tests, and I get 12
>>>>>>>>
>>>>>>>> failures
>>>>>>>
>>>>>>> and 14 errors for it. LdapAuthorizerTest, LdapUserDatabaseTest and
>>>>>>>> XMLUserDatabaseTest all fail with all tests.
>>>>>>>>
>>>>>>>> What I find odd is that guitests and tests targets should give the
>>>>>>>> same
>>>>>>>> results, since they both are run from build.xml.
>>>>>>>>
>>>>>>>> The only other item causing the discrepancy would be if you don't
>>>>>>>>
>>>>>>>>> have
>>>>>>>>> a local LDAP server running for the LDAP tests. Those should cause,
>>>>>>>>> at
>>>>>>>>> most, 14 failures or errors. I'll add in some code to build.xml to
>>>>>>>>> set
>>>>>>>>> up the LDAP fixtures and/or disable the tests if the OpenLDAP
>>>>>>>>> executable isn't available.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I think it's probably a better idea to do the test directly in the
>>>>>>>> tests
>>>>>>>> itself. The JCR TCK throws a NonExecutableException when the test
>>>>>>>> case
>>>>>>>> cannot be executed (and this shows up as a passed test).
>>>>>>>>
>>>>>>>> I think it's important that all three methods give the same number
>>>>>>>> of
>>>>>>>>
>>>>>>>> test
>>>>>>>
>>>>>>> cases; if the number is not reliable, it's too easy to forget to run
>>>>>>>>
>>>>>>>> certain
>>>>>>>
>>>>>>> tests.
>>>>>>>>
>>>>>>>> Also, I sometimes run all tests for a given package from within
>>>>>>>> Eclipse.
>>>>>>>>
>>>>>>>> I'd
>>>>>>>
>>>>>>> like the test cases to be self-contained enough so that I don't have
>>>>>>>> to
>>>>>>>> remember which tests are supposed to run under which conditions.
>>>>>>>>
>>>>>>>> /Janne
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>
>
Re: 2 last failing unit tests
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
Almost. JCR is by definition case-sensitive, and the underlying
implementation enforces that (the pages could very well be in a JDBC
database). So the exact details how Priha stores the data is
unimportant.
The problem is that JSPWiki as currently written is case-sensitive,
which means that using links like [this page] and [This page] and
[This Page] actually refer to different pages. We just do some magic
where we normalize the page names to some casing rules, but that is
breaking down right now, and is not really case-insensitive. It's
just a guess and causes all sorts of interesting problems like with
ReferenceManager (e.g. when the page does not exist, what exactly
should the right spelling be?)
So I think the correct solution for 3.0 should be just to define that
page names are case insensitive.
(To convolute the thing slightly, in English a normalization where all
words are capitalized, e.g. "This Is A Page" is okay, since that's the
way you write headlines. However, in Finnish this kind of
normalization is simply wrong and looks really bad. Case
insensitivity solves this problem neatly.)
/Janne
On Oct 31, 2009, at 20:29 , Harry Metske wrote:
> let me see if I understand this problem correctly:
>
> We currently save the name and the case of a PageName in the name of
> file
> (2.8) or the name of a directory (3.0 / priha), right ?
> If you run on a platform that is not (completely) case-sensitive
> with regard
> to file/dir names, this get's us into trouble, right ?
> If that's the case and we want the preserve platform neutrality, we
> should
> use something else to hold the name and case of pagenames, and
> wiki:title
> seems a proper solution for that.
>
> /Harry
>
> 2009/10/31 Janne Jalkanen <Ja...@ecyrd.com>
>
>> Yup, getting back on this...
>>
>> It seems to me that the following patch fixes the issue, BUT it
>> does expose
>> quite a lot of other problems, mostly related to the fact that
>> JSPWiki (and
>> our tests) assume that page names stay in the same case as it was
>> created.
>> However, if we lowercase all page names as they are stored, the case
>> information is lost. If we do not, then there's no way that we can
>> really
>> get the JCR name from an arbitrarily cased page name.
>>
>> One possibility is to add a new attribute, "wiki:title", which would
>> contain the page name as originally created, and would be the
>> "display"
>> name.
>>
>> /Janne
>>
>> ### Eclipse Workspace Patch 1.0
>> #P JSPWiki
>> Index: src/java/org/apache/wiki/content/WikiPath.java
>> ===================================================================
>> --- src/java/org/apache/wiki/content/WikiPath.java (revision
>> 831483)
>> +++ src/java/org/apache/wiki/content/WikiPath.java (working
>> copy)
>> @@ -193,22 +193,24 @@
>> * String representation. This is to fulfil the general contract
>> of
>> * equals().
>> *
>> - * @return int
>> + * @return {@inheritDoc}
>> */
>> + // FIXME: Slow, since it creates a new String every time.
>> public int hashCode()
>> {
>> - return m_stringRepresentation.hashCode();
>> + return m_stringRepresentation.toLowerCase().hashCode();
>> }
>>
>> /**
>> * A WikiPath is compared using it's toString() method.
>> *
>> * @param o The Object to compare against.
>> - * @return int
>> + * @return {@inheritDoc}
>> */
>> + // FIXME: Slow, since it creates a new String every time.
>> public int compareTo( WikiPath o )
>> {
>> - return toString().compareTo( o.toString() );
>> + return toString().toLowerCase().compareTo(
>> o.toString().toLowerCase() );
>> }
>>
>> /**
>> @@ -226,11 +228,11 @@
>> {
>> WikiPath n = (WikiPath) o;
>>
>> - return m_space.equals( n.m_space ) &&
>> m_path.equals( n.m_path
>> );
>> + return m_space.equalsIgnoreCase( n.m_space ) &&
>> m_path.equalsIgnoreCase( n.m_path );
>> }
>> else if( o instanceof String )
>> {
>> - return toString().equals( o );
>> + return toString().equalsIgnoreCase( (String)o );
>> }
>> return false;
>> }
>> Index: src/java/org/apache/wiki/content/ContentManager.java
>> ===================================================================
>> --- src/java/org/apache/wiki/content/ContentManager.java
>> (revision
>> 831483)
>> +++ src/java/org/apache/wiki/content/ContentManager.java
>> (working
>> copy)
>> @@ -113,7 +113,7 @@
>> */
>> public static final String DEFAULT_SPACE = "Main";
>>
>> - private static final String JCR_DEFAULT_SPACE =
>> "pages/"+DEFAULT_SPACE;
>> + private static final String JCR_DEFAULT_SPACE =
>> "pages/"+DEFAULT_SPACE.toLowerCase();
>>
>> private static final String JCR_PAGES_NODE = "pages";
>>
>> @@ -1433,8 +1433,8 @@
>> String spaceName;
>> String spacePath;
>>
>> - spaceName = wikiName.getSpace();
>> - spacePath = wikiName.getPath();
>> + spaceName = wikiName.getSpace().toLowerCase();
>> + spacePath = wikiName.getPath().toLowerCase();
>>
>> return "/"+JCR_PAGES_NODE+"/"+spaceName+"/"+spacePath;
>>
>> }
>>
>>
>> On Oct 28, 2009, at 22:25 , Janne Jalkanen wrote:
>>
>>
>>> Hm. This seems to be a bug in JSPWiki, actually. JCR Names *are*
>>> case
>>> sensitive, so we should actually be normalizing the name to "this
>>> is a
>>> test". The fact that it's created with an upper-case name
>>> suggests that
>>> JSPWiki is not normalizing the name properly.
>>>
>>> /Janne
>>>
>>> On Oct 28, 2009, at 20:17 , Harry Metske wrote:
>>>
>>> frustrated by the one remaining failing unit test I took a closer
>>> look at
>>>> why WikiEngineTest.testSpacedNames1() fails.
>>>> I can only conclude that 2 of the 3 tests are wrong.
>>>> First a page is created with name "This is a test", this eventually
>>>> resulting in a directory being created somewhere deep down the
>>>> priha repo
>>>> :
>>>>
>>>> metskem@gneisenau
>>>> ~/workspace/JSPWiki/build/tests/priha/workspaces/jspwiki/pages/Main
>>>> $ ls -l
>>>> total 12
>>>> -rw-r--r-- 1 metskem metskem 43 2009-10-28 17:55
>>>> jcr:primaryType.data
>>>> -rw-r--r-- 1 metskem metskem 82 2009-10-28 17:55
>>>> jcr:primaryType.info
>>>> drwxr-xr-x 2 metskem metskem 4096 2009-10-28 19:07 This is a test
>>>>
>>>> Then we do 3 tests:
>>>>
>>>> assertEquals( "normal", "puppaa", m_engine.getText("This is a
>>>> test").trim() );
>>>> assertEquals( "lowercase", "puppaa", m_engine.getText("this is a
>>>> test").trim() );
>>>> assertEquals( "randomcase", "puppaa", m_engine.getText("ThiS Is a
>>>> teSt").trim() );
>>>>
>>>> Only the first one succeeds, the second and third one fail ( of
>>>> course I
>>>> would say), at least on Linux with priha, file/dir names are case
>>>> sensitive.
>>>>
>>>> What am I missing, and if nothing, can I remove the last two
>>>> tests ?
>>>>
>>>> thanks,
>>>> Harry
>>>>
>>>> 2009/10/27 Harry Metske <ha...@gmail.com>
>>>>
>>>> I just did a fresh svn checkout, and ran "ant clean tests" from the
>>>>> cmdline.
>>>>> This gives me 3 failures and 13 errors:
>>>>> http://www.computerhok.nl/tmp/junit-noframes.html
>>>>>
>>>>> The WikiEngineTest.testSpacedNames1() always fails (Linux versus
>>>>> Mac/Windows)
>>>>>
>>>>> Here's an overview of more tests :
>>>>> http://www.computerhok.nl/tmp/jspwiki-testresult.html
>>>>>
>>>>> regards,
>>>>> Harry
>>>>>
>>>>> 2009/10/27 Andrew Jaquith <an...@gmail.com>
>>>>>
>>>>> Sounds like we have a few issues here:
>>>>>
>>>>>>
>>>>>> 1) Guitests. I'll see what I can find. Probably something
>>>>>> minor. I
>>>>>> know the "tests" target runs all test classes ending in "*Test"
>>>>>> and
>>>>>> ignores "AllTests", while Eclipse (and probably guitests) just
>>>>>> runs
>>>>>> the AllTests classes. It's likely that one or more of the
>>>>>> AllTests
>>>>>> classes is failing to include, oh, about 34 tests. :)
>>>>>>
>>>>>> 2) Graceful LDAP fail (inside the tests themselves). Any ideas
>>>>>> on how
>>>>>> to implement? The easy way would be to look for a localhost
>>>>>> listener
>>>>>> on 4890 (where the OpenLDAP test fixture listens) and then not
>>>>>> run the
>>>>>> tests if it isn't found. Should they FAIL or PASS in that case?
>>>>>> It
>>>>>> sounds like passing is the right thing to do.
>>>>>>
>>>>>> 3) Differences in your test pass rate versus mine. Not sure why
>>>>>> your
>>>>>> "ant tests" run would produce different results than mine. I
>>>>>> did try
>>>>>> running mine with a completely new, checked-out branch. Because I
>>>>>> can't know what changes you might have in your local branch,
>>>>>> could you
>>>>>> check out a clean copy and diff the tree versus yours?
>>>>>> SOMETHING is
>>>>>> different. Also, I'd like to know what Harry and others are
>>>>>> seeing.
>>>>>> Gents, any clues?
>>>>>>
>>>>>> I agree that all three methods should return the same number of
>>>>>> test
>>>>>> cases, and pass/fail the same ways. I also agree that tests
>>>>>> should be
>>>>>> self-contained. That was part of the rationale for the Ant script
>>>>>> tweaks I checked in recently.
>>>>>>
>>>>>> Eclipse, by the way, hasn't been reliable for me, for testing,
>>>>>> for a
>>>>>> while. I tend to exhaust memory somewhere around
>>>>>> JSPWikiMarkupParser.
>>>>>> But I haven't tried it in the last few months (i.e. before my
>>>>>> massive
>>>>>> bug-hunting campaign).
>>>>>>
>>>>>> Andrew
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Oct 27, 2009 at 3:25 AM, Janne Jalkanen
>>>>>> <Ja...@ecyrd.com> wrote:
>>>>>>
>>>>>>> Interestingly, I applied your most recent checkins applied
>>>>>>> (and I have
>>>>>>>> small one patch to JSPWikiMarkupParserTest that I haven't
>>>>>>>> checked
>>>>>>>> in).
>>>>>>>> I am running 100% clean, with no errors. Total number of
>>>>>>>> tests: 1024
>>>>>>>> -- a nice round number. :)
>>>>>>>> WikiEngineTest.testOldVersionVars has
>>>>>>>> been running fine for me for a while.
>>>>>>>>
>>>>>>>
>>>>>>> There's no way it should've run, unless you have some old code/
>>>>>>> config
>>>>>>>
>>>>>> files
>>>>>>
>>>>>>> lying around. Can you check out a previous version to a clean
>>>>>>> directory
>>>>>>>
>>>>>> and
>>>>>>
>>>>>>> see if it runs?
>>>>>>>
>>>>>>> As a control case, I also checked out a new built from trunk,
>>>>>>> and
>>>>>>>> simply typed 'ant tests'. I used a vanilla build with
>>>>>>>> absolutely no
>>>>>>>> customizations, even to build.properties. It ran completely
>>>>>>>> clean
>>>>>>>> also
>>>>>>>> except for 1 JSPWikiMarkupParserTest test (because I haven't
>>>>>>>> checked
>>>>>>>> in that fix), 1024 tests total.
>>>>>>>>
>>>>>>>
>>>>>>> Running the AllTests from Eclipse or with "ant guitests"
>>>>>>> results in
>>>>>>> 990
>>>>>>>
>>>>>> test
>>>>>>
>>>>>>> cases. "ant tests" is the only one giving 1024 tests, and I
>>>>>>> get 12
>>>>>>>
>>>>>> failures
>>>>>>
>>>>>>> and 14 errors for it. LdapAuthorizerTest,
>>>>>>> LdapUserDatabaseTest and
>>>>>>> XMLUserDatabaseTest all fail with all tests.
>>>>>>>
>>>>>>> What I find odd is that guitests and tests targets should give
>>>>>>> the
>>>>>>> same
>>>>>>> results, since they both are run from build.xml.
>>>>>>>
>>>>>>> The only other item causing the discrepancy would be if you
>>>>>>> don't
>>>>>>>> have
>>>>>>>> a local LDAP server running for the LDAP tests. Those should
>>>>>>>> cause,
>>>>>>>> at
>>>>>>>> most, 14 failures or errors. I'll add in some code to
>>>>>>>> build.xml to
>>>>>>>> set
>>>>>>>> up the LDAP fixtures and/or disable the tests if the OpenLDAP
>>>>>>>> executable isn't available.
>>>>>>>>
>>>>>>>
>>>>>>> I think it's probably a better idea to do the test directly in
>>>>>>> the
>>>>>>> tests
>>>>>>> itself. The JCR TCK throws a NonExecutableException when the
>>>>>>> test
>>>>>>> case
>>>>>>> cannot be executed (and this shows up as a passed test).
>>>>>>>
>>>>>>> I think it's important that all three methods give the same
>>>>>>> number of
>>>>>>>
>>>>>> test
>>>>>>
>>>>>>> cases; if the number is not reliable, it's too easy to forget
>>>>>>> to run
>>>>>>>
>>>>>> certain
>>>>>>
>>>>>>> tests.
>>>>>>>
>>>>>>> Also, I sometimes run all tests for a given package from within
>>>>>>> Eclipse.
>>>>>>>
>>>>>> I'd
>>>>>>
>>>>>>> like the test cases to be self-contained enough so that I
>>>>>>> don't have
>>>>>>> to
>>>>>>> remember which tests are supposed to run under which conditions.
>>>>>>>
>>>>>>> /Janne
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>
Re: 2 last failing unit tests
Posted by Harry Metske <ha...@gmail.com>.
let me see if I understand this problem correctly:
We currently save the name and the case of a PageName in the name of file
(2.8) or the name of a directory (3.0 / priha), right ?
If you run on a platform that is not (completely) case-sensitive with regard
to file/dir names, this get's us into trouble, right ?
If that's the case and we want the preserve platform neutrality, we should
use something else to hold the name and case of pagenames, and wiki:title
seems a proper solution for that.
/Harry
2009/10/31 Janne Jalkanen <Ja...@ecyrd.com>
> Yup, getting back on this...
>
> It seems to me that the following patch fixes the issue, BUT it does expose
> quite a lot of other problems, mostly related to the fact that JSPWiki (and
> our tests) assume that page names stay in the same case as it was created.
> However, if we lowercase all page names as they are stored, the case
> information is lost. If we do not, then there's no way that we can really
> get the JCR name from an arbitrarily cased page name.
>
> One possibility is to add a new attribute, "wiki:title", which would
> contain the page name as originally created, and would be the "display"
> name.
>
> /Janne
>
> ### Eclipse Workspace Patch 1.0
> #P JSPWiki
> Index: src/java/org/apache/wiki/content/WikiPath.java
> ===================================================================
> --- src/java/org/apache/wiki/content/WikiPath.java (revision 831483)
> +++ src/java/org/apache/wiki/content/WikiPath.java (working copy)
> @@ -193,22 +193,24 @@
> * String representation. This is to fulfil the general contract of
> * equals().
> *
> - * @return int
> + * @return {@inheritDoc}
> */
> + // FIXME: Slow, since it creates a new String every time.
> public int hashCode()
> {
> - return m_stringRepresentation.hashCode();
> + return m_stringRepresentation.toLowerCase().hashCode();
> }
>
> /**
> * A WikiPath is compared using it's toString() method.
> *
> * @param o The Object to compare against.
> - * @return int
> + * @return {@inheritDoc}
> */
> + // FIXME: Slow, since it creates a new String every time.
> public int compareTo( WikiPath o )
> {
> - return toString().compareTo( o.toString() );
> + return toString().toLowerCase().compareTo(
> o.toString().toLowerCase() );
> }
>
> /**
> @@ -226,11 +228,11 @@
> {
> WikiPath n = (WikiPath) o;
>
> - return m_space.equals( n.m_space ) && m_path.equals( n.m_path
> );
> + return m_space.equalsIgnoreCase( n.m_space ) &&
> m_path.equalsIgnoreCase( n.m_path );
> }
> else if( o instanceof String )
> {
> - return toString().equals( o );
> + return toString().equalsIgnoreCase( (String)o );
> }
> return false;
> }
> Index: src/java/org/apache/wiki/content/ContentManager.java
> ===================================================================
> --- src/java/org/apache/wiki/content/ContentManager.java (revision
> 831483)
> +++ src/java/org/apache/wiki/content/ContentManager.java (working
> copy)
> @@ -113,7 +113,7 @@
> */
> public static final String DEFAULT_SPACE = "Main";
>
> - private static final String JCR_DEFAULT_SPACE =
> "pages/"+DEFAULT_SPACE;
> + private static final String JCR_DEFAULT_SPACE =
> "pages/"+DEFAULT_SPACE.toLowerCase();
>
> private static final String JCR_PAGES_NODE = "pages";
>
> @@ -1433,8 +1433,8 @@
> String spaceName;
> String spacePath;
>
> - spaceName = wikiName.getSpace();
> - spacePath = wikiName.getPath();
> + spaceName = wikiName.getSpace().toLowerCase();
> + spacePath = wikiName.getPath().toLowerCase();
>
> return "/"+JCR_PAGES_NODE+"/"+spaceName+"/"+spacePath;
>
> }
>
>
> On Oct 28, 2009, at 22:25 , Janne Jalkanen wrote:
>
>
>> Hm. This seems to be a bug in JSPWiki, actually. JCR Names *are* case
>> sensitive, so we should actually be normalizing the name to "this is a
>> test". The fact that it's created with an upper-case name suggests that
>> JSPWiki is not normalizing the name properly.
>>
>> /Janne
>>
>> On Oct 28, 2009, at 20:17 , Harry Metske wrote:
>>
>> frustrated by the one remaining failing unit test I took a closer look at
>>> why WikiEngineTest.testSpacedNames1() fails.
>>> I can only conclude that 2 of the 3 tests are wrong.
>>> First a page is created with name "This is a test", this eventually
>>> resulting in a directory being created somewhere deep down the priha repo
>>> :
>>>
>>> metskem@gneisenau
>>> ~/workspace/JSPWiki/build/tests/priha/workspaces/jspwiki/pages/Main
>>> $ ls -l
>>> total 12
>>> -rw-r--r-- 1 metskem metskem 43 2009-10-28 17:55 jcr:primaryType.data
>>> -rw-r--r-- 1 metskem metskem 82 2009-10-28 17:55 jcr:primaryType.info
>>> drwxr-xr-x 2 metskem metskem 4096 2009-10-28 19:07 This is a test
>>>
>>> Then we do 3 tests:
>>>
>>> assertEquals( "normal", "puppaa", m_engine.getText("This is a
>>> test").trim() );
>>> assertEquals( "lowercase", "puppaa", m_engine.getText("this is a
>>> test").trim() );
>>> assertEquals( "randomcase", "puppaa", m_engine.getText("ThiS Is a
>>> teSt").trim() );
>>>
>>> Only the first one succeeds, the second and third one fail ( of course I
>>> would say), at least on Linux with priha, file/dir names are case
>>> sensitive.
>>>
>>> What am I missing, and if nothing, can I remove the last two tests ?
>>>
>>> thanks,
>>> Harry
>>>
>>> 2009/10/27 Harry Metske <ha...@gmail.com>
>>>
>>> I just did a fresh svn checkout, and ran "ant clean tests" from the
>>>> cmdline.
>>>> This gives me 3 failures and 13 errors:
>>>> http://www.computerhok.nl/tmp/junit-noframes.html
>>>>
>>>> The WikiEngineTest.testSpacedNames1() always fails (Linux versus
>>>> Mac/Windows)
>>>>
>>>> Here's an overview of more tests :
>>>> http://www.computerhok.nl/tmp/jspwiki-testresult.html
>>>>
>>>> regards,
>>>> Harry
>>>>
>>>> 2009/10/27 Andrew Jaquith <an...@gmail.com>
>>>>
>>>> Sounds like we have a few issues here:
>>>>
>>>>>
>>>>> 1) Guitests. I'll see what I can find. Probably something minor. I
>>>>> know the "tests" target runs all test classes ending in "*Test" and
>>>>> ignores "AllTests", while Eclipse (and probably guitests) just runs
>>>>> the AllTests classes. It's likely that one or more of the AllTests
>>>>> classes is failing to include, oh, about 34 tests. :)
>>>>>
>>>>> 2) Graceful LDAP fail (inside the tests themselves). Any ideas on how
>>>>> to implement? The easy way would be to look for a localhost listener
>>>>> on 4890 (where the OpenLDAP test fixture listens) and then not run the
>>>>> tests if it isn't found. Should they FAIL or PASS in that case? It
>>>>> sounds like passing is the right thing to do.
>>>>>
>>>>> 3) Differences in your test pass rate versus mine. Not sure why your
>>>>> "ant tests" run would produce different results than mine. I did try
>>>>> running mine with a completely new, checked-out branch. Because I
>>>>> can't know what changes you might have in your local branch, could you
>>>>> check out a clean copy and diff the tree versus yours? SOMETHING is
>>>>> different. Also, I'd like to know what Harry and others are seeing.
>>>>> Gents, any clues?
>>>>>
>>>>> I agree that all three methods should return the same number of test
>>>>> cases, and pass/fail the same ways. I also agree that tests should be
>>>>> self-contained. That was part of the rationale for the Ant script
>>>>> tweaks I checked in recently.
>>>>>
>>>>> Eclipse, by the way, hasn't been reliable for me, for testing, for a
>>>>> while. I tend to exhaust memory somewhere around JSPWikiMarkupParser.
>>>>> But I haven't tried it in the last few months (i.e. before my massive
>>>>> bug-hunting campaign).
>>>>>
>>>>> Andrew
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Oct 27, 2009 at 3:25 AM, Janne Jalkanen
>>>>> <Ja...@ecyrd.com> wrote:
>>>>>
>>>>>> Interestingly, I applied your most recent checkins applied (and I have
>>>>>>> small one patch to JSPWikiMarkupParserTest that I haven't checked
>>>>>>> in).
>>>>>>> I am running 100% clean, with no errors. Total number of tests: 1024
>>>>>>> -- a nice round number. :) WikiEngineTest.testOldVersionVars has
>>>>>>> been running fine for me for a while.
>>>>>>>
>>>>>>
>>>>>> There's no way it should've run, unless you have some old code/config
>>>>>>
>>>>> files
>>>>>
>>>>>> lying around. Can you check out a previous version to a clean
>>>>>> directory
>>>>>>
>>>>> and
>>>>>
>>>>>> see if it runs?
>>>>>>
>>>>>> As a control case, I also checked out a new built from trunk, and
>>>>>>> simply typed 'ant tests'. I used a vanilla build with absolutely no
>>>>>>> customizations, even to build.properties. It ran completely clean
>>>>>>> also
>>>>>>> except for 1 JSPWikiMarkupParserTest test (because I haven't checked
>>>>>>> in that fix), 1024 tests total.
>>>>>>>
>>>>>>
>>>>>> Running the AllTests from Eclipse or with "ant guitests" results in
>>>>>> 990
>>>>>>
>>>>> test
>>>>>
>>>>>> cases. "ant tests" is the only one giving 1024 tests, and I get 12
>>>>>>
>>>>> failures
>>>>>
>>>>>> and 14 errors for it. LdapAuthorizerTest, LdapUserDatabaseTest and
>>>>>> XMLUserDatabaseTest all fail with all tests.
>>>>>>
>>>>>> What I find odd is that guitests and tests targets should give the
>>>>>> same
>>>>>> results, since they both are run from build.xml.
>>>>>>
>>>>>> The only other item causing the discrepancy would be if you don't
>>>>>>> have
>>>>>>> a local LDAP server running for the LDAP tests. Those should cause,
>>>>>>> at
>>>>>>> most, 14 failures or errors. I'll add in some code to build.xml to
>>>>>>> set
>>>>>>> up the LDAP fixtures and/or disable the tests if the OpenLDAP
>>>>>>> executable isn't available.
>>>>>>>
>>>>>>
>>>>>> I think it's probably a better idea to do the test directly in the
>>>>>> tests
>>>>>> itself. The JCR TCK throws a NonExecutableException when the test
>>>>>> case
>>>>>> cannot be executed (and this shows up as a passed test).
>>>>>>
>>>>>> I think it's important that all three methods give the same number of
>>>>>>
>>>>> test
>>>>>
>>>>>> cases; if the number is not reliable, it's too easy to forget to run
>>>>>>
>>>>> certain
>>>>>
>>>>>> tests.
>>>>>>
>>>>>> Also, I sometimes run all tests for a given package from within
>>>>>> Eclipse.
>>>>>>
>>>>> I'd
>>>>>
>>>>>> like the test cases to be self-contained enough so that I don't have
>>>>>> to
>>>>>> remember which tests are supposed to run under which conditions.
>>>>>>
>>>>>> /Janne
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>
Re: 2 last failing unit tests
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
Yup, getting back on this...
It seems to me that the following patch fixes the issue, BUT it does
expose quite a lot of other problems, mostly related to the fact that
JSPWiki (and our tests) assume that page names stay in the same case
as it was created. However, if we lowercase all page names as they
are stored, the case information is lost. If we do not, then there's
no way that we can really get the JCR name from an arbitrarily cased
page name.
One possibility is to add a new attribute, "wiki:title", which would
contain the page name as originally created, and would be the
"display" name.
/Janne
### Eclipse Workspace Patch 1.0
#P JSPWiki
Index: src/java/org/apache/wiki/content/WikiPath.java
===================================================================
--- src/java/org/apache/wiki/content/WikiPath.java (revision 831483)
+++ src/java/org/apache/wiki/content/WikiPath.java (working copy)
@@ -193,22 +193,24 @@
* String representation. This is to fulfil the general contract
of
* equals().
*
- * @return int
+ * @return {@inheritDoc}
*/
+ // FIXME: Slow, since it creates a new String every time.
public int hashCode()
{
- return m_stringRepresentation.hashCode();
+ return m_stringRepresentation.toLowerCase().hashCode();
}
/**
* A WikiPath is compared using it's toString() method.
*
* @param o The Object to compare against.
- * @return int
+ * @return {@inheritDoc}
*/
+ // FIXME: Slow, since it creates a new String every time.
public int compareTo( WikiPath o )
{
- return toString().compareTo( o.toString() );
+ return
toString().toLowerCase().compareTo( o.toString().toLowerCase() );
}
/**
@@ -226,11 +228,11 @@
{
WikiPath n = (WikiPath) o;
- return m_space.equals( n.m_space ) &&
m_path.equals( n.m_path );
+ return m_space.equalsIgnoreCase( n.m_space ) &&
m_path.equalsIgnoreCase( n.m_path );
}
else if( o instanceof String )
{
- return toString().equals( o );
+ return toString().equalsIgnoreCase( (String)o );
}
return false;
}
Index: src/java/org/apache/wiki/content/ContentManager.java
===================================================================
--- src/java/org/apache/wiki/content/ContentManager.java (revision
831483)
+++ src/java/org/apache/wiki/content/ContentManager.java (working copy)
@@ -113,7 +113,7 @@
*/
public static final String DEFAULT_SPACE = "Main";
- private static final String JCR_DEFAULT_SPACE =
"pages/"+DEFAULT_SPACE;
+ private static final String JCR_DEFAULT_SPACE =
"pages/"+DEFAULT_SPACE.toLowerCase();
private static final String JCR_PAGES_NODE = "pages";
@@ -1433,8 +1433,8 @@
String spaceName;
String spacePath;
- spaceName = wikiName.getSpace();
- spacePath = wikiName.getPath();
+ spaceName = wikiName.getSpace().toLowerCase();
+ spacePath = wikiName.getPath().toLowerCase();
return "/"+JCR_PAGES_NODE+"/"+spaceName+"/"+spacePath;
}
On Oct 28, 2009, at 22:25 , Janne Jalkanen wrote:
>
> Hm. This seems to be a bug in JSPWiki, actually. JCR Names *are*
> case sensitive, so we should actually be normalizing the name to
> "this is a test". The fact that it's created with an upper-case
> name suggests that JSPWiki is not normalizing the name properly.
>
> /Janne
>
> On Oct 28, 2009, at 20:17 , Harry Metske wrote:
>
>> frustrated by the one remaining failing unit test I took a closer
>> look at
>> why WikiEngineTest.testSpacedNames1() fails.
>> I can only conclude that 2 of the 3 tests are wrong.
>> First a page is created with name "This is a test", this eventually
>> resulting in a directory being created somewhere deep down the
>> priha repo :
>>
>> metskem@gneisenau~/workspace/JSPWiki/build/tests/priha/workspaces/
>> jspwiki/pages/Main
>> $ ls -l
>> total 12
>> -rw-r--r-- 1 metskem metskem 43 2009-10-28 17:55
>> jcr:primaryType.data
>> -rw-r--r-- 1 metskem metskem 82 2009-10-28 17:55
>> jcr:primaryType.info
>> drwxr-xr-x 2 metskem metskem 4096 2009-10-28 19:07 This is a test
>>
>> Then we do 3 tests:
>>
>> assertEquals( "normal", "puppaa", m_engine.getText("This is a
>> test").trim() );
>> assertEquals( "lowercase", "puppaa", m_engine.getText("this is a
>> test").trim() );
>> assertEquals( "randomcase", "puppaa", m_engine.getText("ThiS Is a
>> teSt").trim() );
>>
>> Only the first one succeeds, the second and third one fail ( of
>> course I
>> would say), at least on Linux with priha, file/dir names are case
>> sensitive.
>>
>> What am I missing, and if nothing, can I remove the last two tests ?
>>
>> thanks,
>> Harry
>>
>> 2009/10/27 Harry Metske <ha...@gmail.com>
>>
>>> I just did a fresh svn checkout, and ran "ant clean tests" from the
>>> cmdline.
>>> This gives me 3 failures and 13 errors:
>>> http://www.computerhok.nl/tmp/junit-noframes.html
>>>
>>> The WikiEngineTest.testSpacedNames1() always fails (Linux versus
>>> Mac/Windows)
>>>
>>> Here's an overview of more tests :
>>> http://www.computerhok.nl/tmp/jspwiki-testresult.html
>>>
>>> regards,
>>> Harry
>>>
>>> 2009/10/27 Andrew Jaquith <an...@gmail.com>
>>>
>>> Sounds like we have a few issues here:
>>>>
>>>> 1) Guitests. I'll see what I can find. Probably something minor. I
>>>> know the "tests" target runs all test classes ending in "*Test" and
>>>> ignores "AllTests", while Eclipse (and probably guitests) just runs
>>>> the AllTests classes. It's likely that one or more of the AllTests
>>>> classes is failing to include, oh, about 34 tests. :)
>>>>
>>>> 2) Graceful LDAP fail (inside the tests themselves). Any ideas on
>>>> how
>>>> to implement? The easy way would be to look for a localhost
>>>> listener
>>>> on 4890 (where the OpenLDAP test fixture listens) and then not
>>>> run the
>>>> tests if it isn't found. Should they FAIL or PASS in that case? It
>>>> sounds like passing is the right thing to do.
>>>>
>>>> 3) Differences in your test pass rate versus mine. Not sure why
>>>> your
>>>> "ant tests" run would produce different results than mine. I did
>>>> try
>>>> running mine with a completely new, checked-out branch. Because I
>>>> can't know what changes you might have in your local branch,
>>>> could you
>>>> check out a clean copy and diff the tree versus yours? SOMETHING is
>>>> different. Also, I'd like to know what Harry and others are seeing.
>>>> Gents, any clues?
>>>>
>>>> I agree that all three methods should return the same number of
>>>> test
>>>> cases, and pass/fail the same ways. I also agree that tests
>>>> should be
>>>> self-contained. That was part of the rationale for the Ant script
>>>> tweaks I checked in recently.
>>>>
>>>> Eclipse, by the way, hasn't been reliable for me, for testing,
>>>> for a
>>>> while. I tend to exhaust memory somewhere around
>>>> JSPWikiMarkupParser.
>>>> But I haven't tried it in the last few months (i.e. before my
>>>> massive
>>>> bug-hunting campaign).
>>>>
>>>> Andrew
>>>>
>>>>
>>>>
>>>> On Tue, Oct 27, 2009 at 3:25 AM, Janne Jalkanen
>>>> <Ja...@ecyrd.com> wrote:
>>>>>> Interestingly, I applied your most recent checkins applied (and
>>>>>> I have
>>>>>> small one patch to JSPWikiMarkupParserTest that I haven't
>>>>>> checked in).
>>>>>> I am running 100% clean, with no errors. Total number of tests:
>>>>>> 1024
>>>>>> -- a nice round number. :) WikiEngineTest.testOldVersionVars
>>>>>> has
>>>>>> been running fine for me for a while.
>>>>>
>>>>> There's no way it should've run, unless you have some old code/
>>>>> config
>>>> files
>>>>> lying around. Can you check out a previous version to a clean
>>>>> directory
>>>> and
>>>>> see if it runs?
>>>>>
>>>>>> As a control case, I also checked out a new built from trunk, and
>>>>>> simply typed 'ant tests'. I used a vanilla build with
>>>>>> absolutely no
>>>>>> customizations, even to build.properties. It ran completely
>>>>>> clean also
>>>>>> except for 1 JSPWikiMarkupParserTest test (because I haven't
>>>>>> checked
>>>>>> in that fix), 1024 tests total.
>>>>>
>>>>> Running the AllTests from Eclipse or with "ant guitests" results
>>>>> in 990
>>>> test
>>>>> cases. "ant tests" is the only one giving 1024 tests, and I get
>>>>> 12
>>>> failures
>>>>> and 14 errors for it. LdapAuthorizerTest, LdapUserDatabaseTest
>>>>> and
>>>>> XMLUserDatabaseTest all fail with all tests.
>>>>>
>>>>> What I find odd is that guitests and tests targets should give
>>>>> the same
>>>>> results, since they both are run from build.xml.
>>>>>
>>>>>> The only other item causing the discrepancy would be if you
>>>>>> don't have
>>>>>> a local LDAP server running for the LDAP tests. Those should
>>>>>> cause, at
>>>>>> most, 14 failures or errors. I'll add in some code to build.xml
>>>>>> to set
>>>>>> up the LDAP fixtures and/or disable the tests if the OpenLDAP
>>>>>> executable isn't available.
>>>>>
>>>>> I think it's probably a better idea to do the test directly in
>>>>> the tests
>>>>> itself. The JCR TCK throws a NonExecutableException when the
>>>>> test case
>>>>> cannot be executed (and this shows up as a passed test).
>>>>>
>>>>> I think it's important that all three methods give the same
>>>>> number of
>>>> test
>>>>> cases; if the number is not reliable, it's too easy to forget to
>>>>> run
>>>> certain
>>>>> tests.
>>>>>
>>>>> Also, I sometimes run all tests for a given package from within
>>>>> Eclipse.
>>>> I'd
>>>>> like the test cases to be self-contained enough so that I don't
>>>>> have to
>>>>> remember which tests are supposed to run under which conditions.
>>>>>
>>>>> /Janne
>>>>>
>>>>
>>>
>>>
Re: 2 last failing unit tests
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
Yup; now that there's a properly case-insensitive Priha FileProvider,
testSpacedNames1() is also failing on OSX.
/Janne
On Oct 28, 2009, at 22:25 , Janne Jalkanen wrote:
>
> Hm. This seems to be a bug in JSPWiki, actually. JCR Names *are*
> case sensitive, so we should actually be normalizing the name to
> "this is a test". The fact that it's created with an upper-case
> name suggests that JSPWiki is not normalizing the name properly.
>
> /Janne
>
> On Oct 28, 2009, at 20:17 , Harry Metske wrote:
>
>> frustrated by the one remaining failing unit test I took a closer
>> look at
>> why WikiEngineTest.testSpacedNames1() fails.
>> I can only conclude that 2 of the 3 tests are wrong.
>> First a page is created with name "This is a test", this eventually
>> resulting in a directory being created somewhere deep down the
>> priha repo :
>>
>> metskem@gneisenau~/workspace/JSPWiki/build/tests/priha/workspaces/
>> jspwiki/pages/Main
>> $ ls -l
>> total 12
>> -rw-r--r-- 1 metskem metskem 43 2009-10-28 17:55
>> jcr:primaryType.data
>> -rw-r--r-- 1 metskem metskem 82 2009-10-28 17:55
>> jcr:primaryType.info
>> drwxr-xr-x 2 metskem metskem 4096 2009-10-28 19:07 This is a test
>>
>> Then we do 3 tests:
>>
>> assertEquals( "normal", "puppaa", m_engine.getText("This is a
>> test").trim() );
>> assertEquals( "lowercase", "puppaa", m_engine.getText("this is a
>> test").trim() );
>> assertEquals( "randomcase", "puppaa", m_engine.getText("ThiS Is a
>> teSt").trim() );
>>
>> Only the first one succeeds, the second and third one fail ( of
>> course I
>> would say), at least on Linux with priha, file/dir names are case
>> sensitive.
>>
>> What am I missing, and if nothing, can I remove the last two tests ?
>>
>> thanks,
>> Harry
>>
>> 2009/10/27 Harry Metske <ha...@gmail.com>
>>
>>> I just did a fresh svn checkout, and ran "ant clean tests" from the
>>> cmdline.
>>> This gives me 3 failures and 13 errors:
>>> http://www.computerhok.nl/tmp/junit-noframes.html
>>>
>>> The WikiEngineTest.testSpacedNames1() always fails (Linux versus
>>> Mac/Windows)
>>>
>>> Here's an overview of more tests :
>>> http://www.computerhok.nl/tmp/jspwiki-testresult.html
>>>
>>> regards,
>>> Harry
>>>
>>> 2009/10/27 Andrew Jaquith <an...@gmail.com>
>>>
>>> Sounds like we have a few issues here:
>>>>
>>>> 1) Guitests. I'll see what I can find. Probably something minor. I
>>>> know the "tests" target runs all test classes ending in "*Test" and
>>>> ignores "AllTests", while Eclipse (and probably guitests) just runs
>>>> the AllTests classes. It's likely that one or more of the AllTests
>>>> classes is failing to include, oh, about 34 tests. :)
>>>>
>>>> 2) Graceful LDAP fail (inside the tests themselves). Any ideas on
>>>> how
>>>> to implement? The easy way would be to look for a localhost
>>>> listener
>>>> on 4890 (where the OpenLDAP test fixture listens) and then not
>>>> run the
>>>> tests if it isn't found. Should they FAIL or PASS in that case? It
>>>> sounds like passing is the right thing to do.
>>>>
>>>> 3) Differences in your test pass rate versus mine. Not sure why
>>>> your
>>>> "ant tests" run would produce different results than mine. I did
>>>> try
>>>> running mine with a completely new, checked-out branch. Because I
>>>> can't know what changes you might have in your local branch,
>>>> could you
>>>> check out a clean copy and diff the tree versus yours? SOMETHING is
>>>> different. Also, I'd like to know what Harry and others are seeing.
>>>> Gents, any clues?
>>>>
>>>> I agree that all three methods should return the same number of
>>>> test
>>>> cases, and pass/fail the same ways. I also agree that tests
>>>> should be
>>>> self-contained. That was part of the rationale for the Ant script
>>>> tweaks I checked in recently.
>>>>
>>>> Eclipse, by the way, hasn't been reliable for me, for testing,
>>>> for a
>>>> while. I tend to exhaust memory somewhere around
>>>> JSPWikiMarkupParser.
>>>> But I haven't tried it in the last few months (i.e. before my
>>>> massive
>>>> bug-hunting campaign).
>>>>
>>>> Andrew
>>>>
>>>>
>>>>
>>>> On Tue, Oct 27, 2009 at 3:25 AM, Janne Jalkanen
>>>> <Ja...@ecyrd.com> wrote:
>>>>>> Interestingly, I applied your most recent checkins applied (and
>>>>>> I have
>>>>>> small one patch to JSPWikiMarkupParserTest that I haven't
>>>>>> checked in).
>>>>>> I am running 100% clean, with no errors. Total number of tests:
>>>>>> 1024
>>>>>> -- a nice round number. :) WikiEngineTest.testOldVersionVars
>>>>>> has
>>>>>> been running fine for me for a while.
>>>>>
>>>>> There's no way it should've run, unless you have some old code/
>>>>> config
>>>> files
>>>>> lying around. Can you check out a previous version to a clean
>>>>> directory
>>>> and
>>>>> see if it runs?
>>>>>
>>>>>> As a control case, I also checked out a new built from trunk, and
>>>>>> simply typed 'ant tests'. I used a vanilla build with
>>>>>> absolutely no
>>>>>> customizations, even to build.properties. It ran completely
>>>>>> clean also
>>>>>> except for 1 JSPWikiMarkupParserTest test (because I haven't
>>>>>> checked
>>>>>> in that fix), 1024 tests total.
>>>>>
>>>>> Running the AllTests from Eclipse or with "ant guitests" results
>>>>> in 990
>>>> test
>>>>> cases. "ant tests" is the only one giving 1024 tests, and I get
>>>>> 12
>>>> failures
>>>>> and 14 errors for it. LdapAuthorizerTest, LdapUserDatabaseTest
>>>>> and
>>>>> XMLUserDatabaseTest all fail with all tests.
>>>>>
>>>>> What I find odd is that guitests and tests targets should give
>>>>> the same
>>>>> results, since they both are run from build.xml.
>>>>>
>>>>>> The only other item causing the discrepancy would be if you
>>>>>> don't have
>>>>>> a local LDAP server running for the LDAP tests. Those should
>>>>>> cause, at
>>>>>> most, 14 failures or errors. I'll add in some code to build.xml
>>>>>> to set
>>>>>> up the LDAP fixtures and/or disable the tests if the OpenLDAP
>>>>>> executable isn't available.
>>>>>
>>>>> I think it's probably a better idea to do the test directly in
>>>>> the tests
>>>>> itself. The JCR TCK throws a NonExecutableException when the
>>>>> test case
>>>>> cannot be executed (and this shows up as a passed test).
>>>>>
>>>>> I think it's important that all three methods give the same
>>>>> number of
>>>> test
>>>>> cases; if the number is not reliable, it's too easy to forget to
>>>>> run
>>>> certain
>>>>> tests.
>>>>>
>>>>> Also, I sometimes run all tests for a given package from within
>>>>> Eclipse.
>>>> I'd
>>>>> like the test cases to be self-contained enough so that I don't
>>>>> have to
>>>>> remember which tests are supposed to run under which conditions.
>>>>>
>>>>> /Janne
>>>>>
>>>>
>>>
>>>
Re: 2 last failing unit tests
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
Hm. This seems to be a bug in JSPWiki, actually. JCR Names *are* case
sensitive, so we should actually be normalizing the name to "this is a
test". The fact that it's created with an upper-case name suggests
that JSPWiki is not normalizing the name properly.
/Janne
On Oct 28, 2009, at 20:17 , Harry Metske wrote:
> frustrated by the one remaining failing unit test I took a closer
> look at
> why WikiEngineTest.testSpacedNames1() fails.
> I can only conclude that 2 of the 3 tests are wrong.
> First a page is created with name "This is a test", this eventually
> resulting in a directory being created somewhere deep down the priha
> repo :
>
> metskem@gneisenau~/workspace/JSPWiki/build/tests/priha/workspaces/
> jspwiki/pages/Main
> $ ls -l
> total 12
> -rw-r--r-- 1 metskem metskem 43 2009-10-28 17:55
> jcr:primaryType.data
> -rw-r--r-- 1 metskem metskem 82 2009-10-28 17:55
> jcr:primaryType.info
> drwxr-xr-x 2 metskem metskem 4096 2009-10-28 19:07 This is a test
>
> Then we do 3 tests:
>
> assertEquals( "normal", "puppaa", m_engine.getText("This is a
> test").trim() );
> assertEquals( "lowercase", "puppaa", m_engine.getText("this is a
> test").trim() );
> assertEquals( "randomcase", "puppaa", m_engine.getText("ThiS Is a
> teSt").trim() );
>
> Only the first one succeeds, the second and third one fail ( of
> course I
> would say), at least on Linux with priha, file/dir names are case
> sensitive.
>
> What am I missing, and if nothing, can I remove the last two tests ?
>
> thanks,
> Harry
>
> 2009/10/27 Harry Metske <ha...@gmail.com>
>
>> I just did a fresh svn checkout, and ran "ant clean tests" from the
>> cmdline.
>> This gives me 3 failures and 13 errors:
>> http://www.computerhok.nl/tmp/junit-noframes.html
>>
>> The WikiEngineTest.testSpacedNames1() always fails (Linux versus
>> Mac/Windows)
>>
>> Here's an overview of more tests :
>> http://www.computerhok.nl/tmp/jspwiki-testresult.html
>>
>> regards,
>> Harry
>>
>> 2009/10/27 Andrew Jaquith <an...@gmail.com>
>>
>> Sounds like we have a few issues here:
>>>
>>> 1) Guitests. I'll see what I can find. Probably something minor. I
>>> know the "tests" target runs all test classes ending in "*Test" and
>>> ignores "AllTests", while Eclipse (and probably guitests) just runs
>>> the AllTests classes. It's likely that one or more of the AllTests
>>> classes is failing to include, oh, about 34 tests. :)
>>>
>>> 2) Graceful LDAP fail (inside the tests themselves). Any ideas on
>>> how
>>> to implement? The easy way would be to look for a localhost listener
>>> on 4890 (where the OpenLDAP test fixture listens) and then not run
>>> the
>>> tests if it isn't found. Should they FAIL or PASS in that case? It
>>> sounds like passing is the right thing to do.
>>>
>>> 3) Differences in your test pass rate versus mine. Not sure why your
>>> "ant tests" run would produce different results than mine. I did try
>>> running mine with a completely new, checked-out branch. Because I
>>> can't know what changes you might have in your local branch, could
>>> you
>>> check out a clean copy and diff the tree versus yours? SOMETHING is
>>> different. Also, I'd like to know what Harry and others are seeing.
>>> Gents, any clues?
>>>
>>> I agree that all three methods should return the same number of test
>>> cases, and pass/fail the same ways. I also agree that tests should
>>> be
>>> self-contained. That was part of the rationale for the Ant script
>>> tweaks I checked in recently.
>>>
>>> Eclipse, by the way, hasn't been reliable for me, for testing, for a
>>> while. I tend to exhaust memory somewhere around
>>> JSPWikiMarkupParser.
>>> But I haven't tried it in the last few months (i.e. before my
>>> massive
>>> bug-hunting campaign).
>>>
>>> Andrew
>>>
>>>
>>>
>>> On Tue, Oct 27, 2009 at 3:25 AM, Janne Jalkanen
>>> <Ja...@ecyrd.com> wrote:
>>>>> Interestingly, I applied your most recent checkins applied (and
>>>>> I have
>>>>> small one patch to JSPWikiMarkupParserTest that I haven't
>>>>> checked in).
>>>>> I am running 100% clean, with no errors. Total number of tests:
>>>>> 1024
>>>>> -- a nice round number. :) WikiEngineTest.testOldVersionVars has
>>>>> been running fine for me for a while.
>>>>
>>>> There's no way it should've run, unless you have some old code/
>>>> config
>>> files
>>>> lying around. Can you check out a previous version to a clean
>>>> directory
>>> and
>>>> see if it runs?
>>>>
>>>>> As a control case, I also checked out a new built from trunk, and
>>>>> simply typed 'ant tests'. I used a vanilla build with absolutely
>>>>> no
>>>>> customizations, even to build.properties. It ran completely
>>>>> clean also
>>>>> except for 1 JSPWikiMarkupParserTest test (because I haven't
>>>>> checked
>>>>> in that fix), 1024 tests total.
>>>>
>>>> Running the AllTests from Eclipse or with "ant guitests" results
>>>> in 990
>>> test
>>>> cases. "ant tests" is the only one giving 1024 tests, and I get 12
>>> failures
>>>> and 14 errors for it. LdapAuthorizerTest, LdapUserDatabaseTest and
>>>> XMLUserDatabaseTest all fail with all tests.
>>>>
>>>> What I find odd is that guitests and tests targets should give
>>>> the same
>>>> results, since they both are run from build.xml.
>>>>
>>>>> The only other item causing the discrepancy would be if you
>>>>> don't have
>>>>> a local LDAP server running for the LDAP tests. Those should
>>>>> cause, at
>>>>> most, 14 failures or errors. I'll add in some code to build.xml
>>>>> to set
>>>>> up the LDAP fixtures and/or disable the tests if the OpenLDAP
>>>>> executable isn't available.
>>>>
>>>> I think it's probably a better idea to do the test directly in
>>>> the tests
>>>> itself. The JCR TCK throws a NonExecutableException when the
>>>> test case
>>>> cannot be executed (and this shows up as a passed test).
>>>>
>>>> I think it's important that all three methods give the same
>>>> number of
>>> test
>>>> cases; if the number is not reliable, it's too easy to forget to
>>>> run
>>> certain
>>>> tests.
>>>>
>>>> Also, I sometimes run all tests for a given package from within
>>>> Eclipse.
>>> I'd
>>>> like the test cases to be self-contained enough so that I don't
>>>> have to
>>>> remember which tests are supposed to run under which conditions.
>>>>
>>>> /Janne
>>>>
>>>
>>
>>
Re: 2 last failing unit tests
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
Could be that I've screwed up something with the FileProvider (I know
FileProvider.mangleName() is not doing everything it should). Anyone
want to help me out with some Priha-specific unit testing?
/Janne
On Oct 28, 2009, at 20:17 , Harry Metske wrote:
> frustrated by the one remaining failing unit test I took a closer
> look at
> why WikiEngineTest.testSpacedNames1() fails.
> I can only conclude that 2 of the 3 tests are wrong.
> First a page is created with name "This is a test", this eventually
> resulting in a directory being created somewhere deep down the priha
> repo :
>
> metskem@gneisenau~/workspace/JSPWiki/build/tests/priha/workspaces/
> jspwiki/pages/Main
> $ ls -l
> total 12
> -rw-r--r-- 1 metskem metskem 43 2009-10-28 17:55
> jcr:primaryType.data
> -rw-r--r-- 1 metskem metskem 82 2009-10-28 17:55
> jcr:primaryType.info
> drwxr-xr-x 2 metskem metskem 4096 2009-10-28 19:07 This is a test
>
> Then we do 3 tests:
>
> assertEquals( "normal", "puppaa", m_engine.getText("This is a
> test").trim() );
> assertEquals( "lowercase", "puppaa", m_engine.getText("this is a
> test").trim() );
> assertEquals( "randomcase", "puppaa", m_engine.getText("ThiS Is a
> teSt").trim() );
>
> Only the first one succeeds, the second and third one fail ( of
> course I
> would say), at least on Linux with priha, file/dir names are case
> sensitive.
>
> What am I missing, and if nothing, can I remove the last two tests ?
>
> thanks,
> Harry
>
> 2009/10/27 Harry Metske <ha...@gmail.com>
>
>> I just did a fresh svn checkout, and ran "ant clean tests" from the
>> cmdline.
>> This gives me 3 failures and 13 errors:
>> http://www.computerhok.nl/tmp/junit-noframes.html
>>
>> The WikiEngineTest.testSpacedNames1() always fails (Linux versus
>> Mac/Windows)
>>
>> Here's an overview of more tests :
>> http://www.computerhok.nl/tmp/jspwiki-testresult.html
>>
>> regards,
>> Harry
>>
>> 2009/10/27 Andrew Jaquith <an...@gmail.com>
>>
>> Sounds like we have a few issues here:
>>>
>>> 1) Guitests. I'll see what I can find. Probably something minor. I
>>> know the "tests" target runs all test classes ending in "*Test" and
>>> ignores "AllTests", while Eclipse (and probably guitests) just runs
>>> the AllTests classes. It's likely that one or more of the AllTests
>>> classes is failing to include, oh, about 34 tests. :)
>>>
>>> 2) Graceful LDAP fail (inside the tests themselves). Any ideas on
>>> how
>>> to implement? The easy way would be to look for a localhost listener
>>> on 4890 (where the OpenLDAP test fixture listens) and then not run
>>> the
>>> tests if it isn't found. Should they FAIL or PASS in that case? It
>>> sounds like passing is the right thing to do.
>>>
>>> 3) Differences in your test pass rate versus mine. Not sure why your
>>> "ant tests" run would produce different results than mine. I did try
>>> running mine with a completely new, checked-out branch. Because I
>>> can't know what changes you might have in your local branch, could
>>> you
>>> check out a clean copy and diff the tree versus yours? SOMETHING is
>>> different. Also, I'd like to know what Harry and others are seeing.
>>> Gents, any clues?
>>>
>>> I agree that all three methods should return the same number of test
>>> cases, and pass/fail the same ways. I also agree that tests should
>>> be
>>> self-contained. That was part of the rationale for the Ant script
>>> tweaks I checked in recently.
>>>
>>> Eclipse, by the way, hasn't been reliable for me, for testing, for a
>>> while. I tend to exhaust memory somewhere around
>>> JSPWikiMarkupParser.
>>> But I haven't tried it in the last few months (i.e. before my
>>> massive
>>> bug-hunting campaign).
>>>
>>> Andrew
>>>
>>>
>>>
>>> On Tue, Oct 27, 2009 at 3:25 AM, Janne Jalkanen
>>> <Ja...@ecyrd.com> wrote:
>>>>> Interestingly, I applied your most recent checkins applied (and
>>>>> I have
>>>>> small one patch to JSPWikiMarkupParserTest that I haven't
>>>>> checked in).
>>>>> I am running 100% clean, with no errors. Total number of tests:
>>>>> 1024
>>>>> -- a nice round number. :) WikiEngineTest.testOldVersionVars has
>>>>> been running fine for me for a while.
>>>>
>>>> There's no way it should've run, unless you have some old code/
>>>> config
>>> files
>>>> lying around. Can you check out a previous version to a clean
>>>> directory
>>> and
>>>> see if it runs?
>>>>
>>>>> As a control case, I also checked out a new built from trunk, and
>>>>> simply typed 'ant tests'. I used a vanilla build with absolutely
>>>>> no
>>>>> customizations, even to build.properties. It ran completely
>>>>> clean also
>>>>> except for 1 JSPWikiMarkupParserTest test (because I haven't
>>>>> checked
>>>>> in that fix), 1024 tests total.
>>>>
>>>> Running the AllTests from Eclipse or with "ant guitests" results
>>>> in 990
>>> test
>>>> cases. "ant tests" is the only one giving 1024 tests, and I get 12
>>> failures
>>>> and 14 errors for it. LdapAuthorizerTest, LdapUserDatabaseTest and
>>>> XMLUserDatabaseTest all fail with all tests.
>>>>
>>>> What I find odd is that guitests and tests targets should give
>>>> the same
>>>> results, since they both are run from build.xml.
>>>>
>>>>> The only other item causing the discrepancy would be if you
>>>>> don't have
>>>>> a local LDAP server running for the LDAP tests. Those should
>>>>> cause, at
>>>>> most, 14 failures or errors. I'll add in some code to build.xml
>>>>> to set
>>>>> up the LDAP fixtures and/or disable the tests if the OpenLDAP
>>>>> executable isn't available.
>>>>
>>>> I think it's probably a better idea to do the test directly in
>>>> the tests
>>>> itself. The JCR TCK throws a NonExecutableException when the
>>>> test case
>>>> cannot be executed (and this shows up as a passed test).
>>>>
>>>> I think it's important that all three methods give the same
>>>> number of
>>> test
>>>> cases; if the number is not reliable, it's too easy to forget to
>>>> run
>>> certain
>>>> tests.
>>>>
>>>> Also, I sometimes run all tests for a given package from within
>>>> Eclipse.
>>> I'd
>>>> like the test cases to be self-contained enough so that I don't
>>>> have to
>>>> remember which tests are supposed to run under which conditions.
>>>>
>>>> /Janne
>>>>
>>>
>>
>>
Re: 2 last failing unit tests
Posted by Harry Metske <ha...@gmail.com>.
frustrated by the one remaining failing unit test I took a closer look at
why WikiEngineTest.testSpacedNames1() fails.
I can only conclude that 2 of the 3 tests are wrong.
First a page is created with name "This is a test", this eventually
resulting in a directory being created somewhere deep down the priha repo :
metskem@gneisenau~/workspace/JSPWiki/build/tests/priha/workspaces/jspwiki/pages/Main
$ ls -l
total 12
-rw-r--r-- 1 metskem metskem 43 2009-10-28 17:55 jcr:primaryType.data
-rw-r--r-- 1 metskem metskem 82 2009-10-28 17:55 jcr:primaryType.info
drwxr-xr-x 2 metskem metskem 4096 2009-10-28 19:07 This is a test
Then we do 3 tests:
assertEquals( "normal", "puppaa", m_engine.getText("This is a
test").trim() );
assertEquals( "lowercase", "puppaa", m_engine.getText("this is a
test").trim() );
assertEquals( "randomcase", "puppaa", m_engine.getText("ThiS Is a
teSt").trim() );
Only the first one succeeds, the second and third one fail ( of course I
would say), at least on Linux with priha, file/dir names are case sensitive.
What am I missing, and if nothing, can I remove the last two tests ?
thanks,
Harry
2009/10/27 Harry Metske <ha...@gmail.com>
> I just did a fresh svn checkout, and ran "ant clean tests" from the
> cmdline.
> This gives me 3 failures and 13 errors:
> http://www.computerhok.nl/tmp/junit-noframes.html
>
> The WikiEngineTest.testSpacedNames1() always fails (Linux versus
> Mac/Windows)
>
> Here's an overview of more tests :
> http://www.computerhok.nl/tmp/jspwiki-testresult.html
>
> regards,
> Harry
>
> 2009/10/27 Andrew Jaquith <an...@gmail.com>
>
> Sounds like we have a few issues here:
>>
>> 1) Guitests. I'll see what I can find. Probably something minor. I
>> know the "tests" target runs all test classes ending in "*Test" and
>> ignores "AllTests", while Eclipse (and probably guitests) just runs
>> the AllTests classes. It's likely that one or more of the AllTests
>> classes is failing to include, oh, about 34 tests. :)
>>
>> 2) Graceful LDAP fail (inside the tests themselves). Any ideas on how
>> to implement? The easy way would be to look for a localhost listener
>> on 4890 (where the OpenLDAP test fixture listens) and then not run the
>> tests if it isn't found. Should they FAIL or PASS in that case? It
>> sounds like passing is the right thing to do.
>>
>> 3) Differences in your test pass rate versus mine. Not sure why your
>> "ant tests" run would produce different results than mine. I did try
>> running mine with a completely new, checked-out branch. Because I
>> can't know what changes you might have in your local branch, could you
>> check out a clean copy and diff the tree versus yours? SOMETHING is
>> different. Also, I'd like to know what Harry and others are seeing.
>> Gents, any clues?
>>
>> I agree that all three methods should return the same number of test
>> cases, and pass/fail the same ways. I also agree that tests should be
>> self-contained. That was part of the rationale for the Ant script
>> tweaks I checked in recently.
>>
>> Eclipse, by the way, hasn't been reliable for me, for testing, for a
>> while. I tend to exhaust memory somewhere around JSPWikiMarkupParser.
>> But I haven't tried it in the last few months (i.e. before my massive
>> bug-hunting campaign).
>>
>> Andrew
>>
>>
>>
>> On Tue, Oct 27, 2009 at 3:25 AM, Janne Jalkanen
>> <Ja...@ecyrd.com> wrote:
>> >> Interestingly, I applied your most recent checkins applied (and I have
>> >> small one patch to JSPWikiMarkupParserTest that I haven't checked in).
>> >> I am running 100% clean, with no errors. Total number of tests: 1024
>> >> -- a nice round number. :) WikiEngineTest.testOldVersionVars has
>> >> been running fine for me for a while.
>> >
>> > There's no way it should've run, unless you have some old code/config
>> files
>> > lying around. Can you check out a previous version to a clean directory
>> and
>> > see if it runs?
>> >
>> >> As a control case, I also checked out a new built from trunk, and
>> >> simply typed 'ant tests'. I used a vanilla build with absolutely no
>> >> customizations, even to build.properties. It ran completely clean also
>> >> except for 1 JSPWikiMarkupParserTest test (because I haven't checked
>> >> in that fix), 1024 tests total.
>> >
>> > Running the AllTests from Eclipse or with "ant guitests" results in 990
>> test
>> > cases. "ant tests" is the only one giving 1024 tests, and I get 12
>> failures
>> > and 14 errors for it. LdapAuthorizerTest, LdapUserDatabaseTest and
>> > XMLUserDatabaseTest all fail with all tests.
>> >
>> > What I find odd is that guitests and tests targets should give the same
>> > results, since they both are run from build.xml.
>> >
>> >> The only other item causing the discrepancy would be if you don't have
>> >> a local LDAP server running for the LDAP tests. Those should cause, at
>> >> most, 14 failures or errors. I'll add in some code to build.xml to set
>> >> up the LDAP fixtures and/or disable the tests if the OpenLDAP
>> >> executable isn't available.
>> >
>> > I think it's probably a better idea to do the test directly in the tests
>> > itself. The JCR TCK throws a NonExecutableException when the test case
>> > cannot be executed (and this shows up as a passed test).
>> >
>> > I think it's important that all three methods give the same number of
>> test
>> > cases; if the number is not reliable, it's too easy to forget to run
>> certain
>> > tests.
>> >
>> > Also, I sometimes run all tests for a given package from within Eclipse.
>> I'd
>> > like the test cases to be self-contained enough so that I don't have to
>> > remember which tests are supposed to run under which conditions.
>> >
>> > /Janne
>> >
>>
>
>
Re: 2 last failing unit tests
Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
Hi,
I've also made a fresh checkout + "ant clean tests"
I got 6 failures, and 661 errors. Ugh.
All errors look the same (except JDBCUserDatabaseTest module), and appear at
setUp(), for example (apologies for the long stack traces):
MockServletContext: JSPWiki: Unable to load and setup properties from
jspwiki.properties. Failed to start; please check log files for better
information.
------------- ---------------- ---------------
Testcase: testRemove took 0,125 sec
Caused an ERROR
JSPWiki: Unable to load and setup properties from jspwiki.properties. Failed
to start; please check log files for better information.
org.apache.wiki.api.WikiException: JSPWiki: Unable to load and setup
properties from jspwiki.properties. Failed to start; please check log files
for better information.
at org.apache.wiki.WikiEngine.<init>(WikiEngine.java:447)
at org.apache.wiki.TestEngine.<init>(TestEngine.java:146)
at
org.apache.wiki.workflow.DecisionQueueTest.setUp(DecisionQueueTest.java:60)
Caused by: org.apache.wiki.api.WikiException: Failed to start; please check
log files for better information.
at org.apache.wiki.WikiEngine.initialize(WikiEngine.java:655)
at org.apache.wiki.WikiEngine.<init>(WikiEngine.java:429)
... 12 more
Caused by: org.apache.wiki.api.WikiException: Failed to invoke class
org.apache.wiki.content.ContentManager, reason:
org.apache.wiki.api.WikiException: Failed to initialize the repository
content
at org.apache.wiki.util.ClassUtil.getMappedObject(ClassUtil.java:311)
at org.apache.wiki.util.ClassUtil.getMappedObject(ClassUtil.java:204)
at org.apache.wiki.WikiEngine.initialize(WikiEngine.java:565)
... 13 more
Caused by: java.lang.reflect.InvocationTargetException
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at org.apache.wiki.util.ClassUtil.getMappedObject(ClassUtil.java:276)
... 15 more
Caused by: org.apache.wiki.api.WikiException: Failed to initialize the
repository content
at
org.apache.wiki.content.ContentManager.<init>(ContentManager.java:305)
... 19 more
Caused by: org.priha.util.ConfigurationException: Cannot use the Priha
FileProvider repository while another instance of Priha is using it. If you
are sure there are no other instances using this same repository, please
remove the 'E:\Workspaces\JSPWiki\JSPWiki_svn\build\tests\priha\.prihalock'
file and restart.
at org.priha.providers.FileProvider.start(FileProvider.java:328)
at
org.priha.core.ProviderManager.instantiateProvider(ProviderManager.java:215)
at org.priha.core.ProviderManager.initialize(ProviderManager.java:117)
at org.priha.core.ProviderManager.<init>(ProviderManager.java:65)
at
org.priha.core.RepositoryImpl.getProviderManager(RepositoryImpl.java:117)
at org.priha.core.RepositoryImpl.login(RepositoryImpl.java:193)
at org.priha.core.RepositoryImpl.login(RepositoryImpl.java:39)
at
org.apache.wiki.content.ContentManager$JCRSessionManager.newSession(ContentManager.java:1795)
at
org.apache.wiki.content.ContentManager$JCRSessionManager.createSession(ContentManager.java:1779)
at
org.apache.wiki.content.ContentManager$JCRSessionManager.getSession(ContentManager.java:1839)
at
org.apache.wiki.content.ContentManager.initialize(ContentManager.java:318)
at
org.apache.wiki.content.ContentManager.<init>(ContentManager.java:301)
Digging around, I've found the following stack trace at VariableManagerTest,
which may explain the cause of so many errors (?):
INFO: Repository empty; setting up root node...
java.io.FileNotFoundException:
build\tests\priha\jcr:system\jcr:primaryType.data (El nombre de archivo,
directorio o etiqueta del volumen no es válido)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
at java.io.FileOutputStream.<init>(FileOutputStream.java:131)
at org.priha.providers.FileProvider.writeValue(FileProvider.java:574)
at
org.priha.providers.FileProvider.putPropertyValue(FileProvider.java:675)
at org.priha.core.ProviderManager.putProperty(ProviderManager.java:517)
at org.priha.core.SessionProvider.save(SessionProvider.java:427)
at org.priha.core.SessionImpl.saveNodes(SessionImpl.java:500)
at org.priha.core.SessionImpl.save(SessionImpl.java:485)
at org.priha.core.SessionImpl.repopulate(SessionImpl.java:472)
at org.priha.core.SessionImpl.<init>(SessionImpl.java:99)
at
org.priha.core.RepositoryImpl$SessionManager.openSession(RepositoryImpl.java:321)
at org.priha.core.RepositoryImpl.login(RepositoryImpl.java:195)
at org.priha.core.RepositoryImpl.login(RepositoryImpl.java:39)
at
org.apache.wiki.content.ContentManager$JCRSessionManager.newSession(ContentManager.java:1795)
at
org.apache.wiki.content.ContentManager$JCRSessionManager.createSession(ContentManager.java:1779)
at
org.apache.wiki.content.ContentManager$JCRSessionManager.getSession(ContentManager.java:1839)
at
org.apache.wiki.content.ContentManager.initialize(ContentManager.java:318)
at
org.apache.wiki.content.ContentManager.<init>(ContentManager.java:301)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at org.apache.wiki.util.ClassUtil.getMappedObject(ClassUtil.java:276)
at org.apache.wiki.util.ClassUtil.getMappedObject(ClassUtil.java:204)
at org.apache.wiki.WikiEngine.initialize(WikiEngine.java:565)
at org.apache.wiki.WikiEngine.<init>(WikiEngine.java:429)
at org.apache.wiki.TestEngine.<init>(TestEngine.java:146)
at
org.apache.wiki.VariableManagerTest.setUp(VariableManagerTest.java:64)
[...]
27-oct-2009 19:32:22 org.priha.core.RepositoryImpl <init>
INFO: G'day, Matilda! Priha 0.5.6 has been initialized.
27-oct-2009 19:32:22 org.priha.core.RepositoryImpl getProviderManager
INFO: Initializing providers...
27-oct-2009 19:32:22 org.priha.providers.FileProvider start
GRAVE: Cannot use the Priha FileProvider repository while another instance
of Priha is using it. If you are sure there are no other instances using
this same repository, please remove the
'E:\Workspaces\JSPWiki\JSPWiki_svn\build\tests\priha\.prihalock' file and
restart.
27-oct-2009 19:32:22 org.priha.core.RepositoryImpl <init>
INFO: G'day, Matilda! Priha 0.5.6 has been initialized.
27-oct-2009 19:32:22 org.priha.core.RepositoryImpl getProviderManager
which first line means invalid filename or directory (I'm running on
windows).
As for failures:
- CreoleToJSPWikiTranslatorTest:
- testBoldAcrossLineBreaks fails with following trace:
junit.framework.ComparisonFailure: expected:<...
...> but was:<......> [<-- notice expected newline]
- CommentedPropertiesTest:
- testRemove: junit.framework.AssertionFailedError: expected:<290> but
was:<288> at
org.apache.wiki.util.CommentedPropertiesTest.testRemove(CommentedPropertiesTest.java:139)
- testSetProperty: junit.framework.AssertionFailedError: expected:<376>
but was:<377> at
org.apache.wiki.util.CommentedPropertiesTest.testSetProperty(CommentedPropertiesTest.java:72)
- testSetEscapedProperty: junit.framework.ComparisonFailure:
expected:<......> but was:<...
...> [<-- notice unexpected newline here] at
org.apache.wiki.util.CommentedPropertiesTest.testSetEscapedProperty(CommentedPropertiesTest.java:86)
- testSetComment: junit.framework.AssertionFailedError at
org.apache.wiki.util.CommentedPropertiesTest.testSetComment(CommentedPropertiesTest.java:120)
As for JDBCUserDatabaseTest:
- JDBCUserDatabaseTest fails with AssertionFailedError at
org.apache.wiki.auth.user.JDBCUserDatabaseTest.testSave(JDBCUserDatabaseTest.java:450
- testRename is the only one which ends in success
- the rest are giving an error with the following message:
java.sql.SQLException:
File input/output error: jspwiki.log at
org.apache.wiki.auth.user.JDBCUserDatabaseTest.setUp(JDBCUserDatabaseTest.java:126)
Tomorrow at work I'll try on a ubuntu box to see if it makes a difference.
regards,
juan pablo
On Tue, Oct 27, 2009 at 6:16 PM, Harry Metske <ha...@gmail.com>wrote:
> I just did a fresh svn checkout, and ran "ant clean tests" from the
> cmdline.
> This gives me 3 failures and 13 errors:
> http://www.computerhok.nl/tmp/junit-noframes.html
>
> The WikiEngineTest.testSpacedNames1() always fails (Linux versus
> Mac/Windows)
>
> Here's an overview of more tests :
> http://www.computerhok.nl/tmp/jspwiki-testresult.html
>
> regards,
> Harry
>
> 2009/10/27 Andrew Jaquith <an...@gmail.com>
>
> > Sounds like we have a few issues here:
> >
> > 1) Guitests. I'll see what I can find. Probably something minor. I
> > know the "tests" target runs all test classes ending in "*Test" and
> > ignores "AllTests", while Eclipse (and probably guitests) just runs
> > the AllTests classes. It's likely that one or more of the AllTests
> > classes is failing to include, oh, about 34 tests. :)
> >
> > 2) Graceful LDAP fail (inside the tests themselves). Any ideas on how
> > to implement? The easy way would be to look for a localhost listener
> > on 4890 (where the OpenLDAP test fixture listens) and then not run the
> > tests if it isn't found. Should they FAIL or PASS in that case? It
> > sounds like passing is the right thing to do.
> >
> > 3) Differences in your test pass rate versus mine. Not sure why your
> > "ant tests" run would produce different results than mine. I did try
> > running mine with a completely new, checked-out branch. Because I
> > can't know what changes you might have in your local branch, could you
> > check out a clean copy and diff the tree versus yours? SOMETHING is
> > different. Also, I'd like to know what Harry and others are seeing.
> > Gents, any clues?
> >
> > I agree that all three methods should return the same number of test
> > cases, and pass/fail the same ways. I also agree that tests should be
> > self-contained. That was part of the rationale for the Ant script
> > tweaks I checked in recently.
> >
> > Eclipse, by the way, hasn't been reliable for me, for testing, for a
> > while. I tend to exhaust memory somewhere around JSPWikiMarkupParser.
> > But I haven't tried it in the last few months (i.e. before my massive
> > bug-hunting campaign).
> >
> > Andrew
> >
> >
> >
> > On Tue, Oct 27, 2009 at 3:25 AM, Janne Jalkanen
> > <Ja...@ecyrd.com> wrote:
> > >> Interestingly, I applied your most recent checkins applied (and I have
> > >> small one patch to JSPWikiMarkupParserTest that I haven't checked in).
> > >> I am running 100% clean, with no errors. Total number of tests: 1024
> > >> -- a nice round number. :) WikiEngineTest.testOldVersionVars has
> > >> been running fine for me for a while.
> > >
> > > There's no way it should've run, unless you have some old code/config
> > files
> > > lying around. Can you check out a previous version to a clean
> directory
> > and
> > > see if it runs?
> > >
> > >> As a control case, I also checked out a new built from trunk, and
> > >> simply typed 'ant tests'. I used a vanilla build with absolutely no
> > >> customizations, even to build.properties. It ran completely clean also
> > >> except for 1 JSPWikiMarkupParserTest test (because I haven't checked
> > >> in that fix), 1024 tests total.
> > >
> > > Running the AllTests from Eclipse or with "ant guitests" results in 990
> > test
> > > cases. "ant tests" is the only one giving 1024 tests, and I get 12
> > failures
> > > and 14 errors for it. LdapAuthorizerTest, LdapUserDatabaseTest and
> > > XMLUserDatabaseTest all fail with all tests.
> > >
> > > What I find odd is that guitests and tests targets should give the same
> > > results, since they both are run from build.xml.
> > >
> > >> The only other item causing the discrepancy would be if you don't have
> > >> a local LDAP server running for the LDAP tests. Those should cause, at
> > >> most, 14 failures or errors. I'll add in some code to build.xml to set
> > >> up the LDAP fixtures and/or disable the tests if the OpenLDAP
> > >> executable isn't available.
> > >
> > > I think it's probably a better idea to do the test directly in the
> tests
> > > itself. The JCR TCK throws a NonExecutableException when the test case
> > > cannot be executed (and this shows up as a passed test).
> > >
> > > I think it's important that all three methods give the same number of
> > test
> > > cases; if the number is not reliable, it's too easy to forget to run
> > certain
> > > tests.
> > >
> > > Also, I sometimes run all tests for a given package from within
> Eclipse.
> > I'd
> > > like the test cases to be self-contained enough so that I don't have to
> > > remember which tests are supposed to run under which conditions.
> > >
> > > /Janne
> > >
> >
>
Re: 2 last failing unit tests
Posted by Harry Metske <ha...@gmail.com>.
I just did a fresh svn checkout, and ran "ant clean tests" from the cmdline.
This gives me 3 failures and 13 errors:
http://www.computerhok.nl/tmp/junit-noframes.html
The WikiEngineTest.testSpacedNames1() always fails (Linux versus
Mac/Windows)
Here's an overview of more tests :
http://www.computerhok.nl/tmp/jspwiki-testresult.html
regards,
Harry
2009/10/27 Andrew Jaquith <an...@gmail.com>
> Sounds like we have a few issues here:
>
> 1) Guitests. I'll see what I can find. Probably something minor. I
> know the "tests" target runs all test classes ending in "*Test" and
> ignores "AllTests", while Eclipse (and probably guitests) just runs
> the AllTests classes. It's likely that one or more of the AllTests
> classes is failing to include, oh, about 34 tests. :)
>
> 2) Graceful LDAP fail (inside the tests themselves). Any ideas on how
> to implement? The easy way would be to look for a localhost listener
> on 4890 (where the OpenLDAP test fixture listens) and then not run the
> tests if it isn't found. Should they FAIL or PASS in that case? It
> sounds like passing is the right thing to do.
>
> 3) Differences in your test pass rate versus mine. Not sure why your
> "ant tests" run would produce different results than mine. I did try
> running mine with a completely new, checked-out branch. Because I
> can't know what changes you might have in your local branch, could you
> check out a clean copy and diff the tree versus yours? SOMETHING is
> different. Also, I'd like to know what Harry and others are seeing.
> Gents, any clues?
>
> I agree that all three methods should return the same number of test
> cases, and pass/fail the same ways. I also agree that tests should be
> self-contained. That was part of the rationale for the Ant script
> tweaks I checked in recently.
>
> Eclipse, by the way, hasn't been reliable for me, for testing, for a
> while. I tend to exhaust memory somewhere around JSPWikiMarkupParser.
> But I haven't tried it in the last few months (i.e. before my massive
> bug-hunting campaign).
>
> Andrew
>
>
>
> On Tue, Oct 27, 2009 at 3:25 AM, Janne Jalkanen
> <Ja...@ecyrd.com> wrote:
> >> Interestingly, I applied your most recent checkins applied (and I have
> >> small one patch to JSPWikiMarkupParserTest that I haven't checked in).
> >> I am running 100% clean, with no errors. Total number of tests: 1024
> >> -- a nice round number. :) WikiEngineTest.testOldVersionVars has
> >> been running fine for me for a while.
> >
> > There's no way it should've run, unless you have some old code/config
> files
> > lying around. Can you check out a previous version to a clean directory
> and
> > see if it runs?
> >
> >> As a control case, I also checked out a new built from trunk, and
> >> simply typed 'ant tests'. I used a vanilla build with absolutely no
> >> customizations, even to build.properties. It ran completely clean also
> >> except for 1 JSPWikiMarkupParserTest test (because I haven't checked
> >> in that fix), 1024 tests total.
> >
> > Running the AllTests from Eclipse or with "ant guitests" results in 990
> test
> > cases. "ant tests" is the only one giving 1024 tests, and I get 12
> failures
> > and 14 errors for it. LdapAuthorizerTest, LdapUserDatabaseTest and
> > XMLUserDatabaseTest all fail with all tests.
> >
> > What I find odd is that guitests and tests targets should give the same
> > results, since they both are run from build.xml.
> >
> >> The only other item causing the discrepancy would be if you don't have
> >> a local LDAP server running for the LDAP tests. Those should cause, at
> >> most, 14 failures or errors. I'll add in some code to build.xml to set
> >> up the LDAP fixtures and/or disable the tests if the OpenLDAP
> >> executable isn't available.
> >
> > I think it's probably a better idea to do the test directly in the tests
> > itself. The JCR TCK throws a NonExecutableException when the test case
> > cannot be executed (and this shows up as a passed test).
> >
> > I think it's important that all three methods give the same number of
> test
> > cases; if the number is not reliable, it's too easy to forget to run
> certain
> > tests.
> >
> > Also, I sometimes run all tests for a given package from within Eclipse.
> I'd
> > like the test cases to be self-contained enough so that I don't have to
> > remember which tests are supposed to run under which conditions.
> >
> > /Janne
> >
>
Re: 2 last failing unit tests
Posted by Andrew Jaquith <an...@gmail.com>.
Sounds like we have a few issues here:
1) Guitests. I'll see what I can find. Probably something minor. I
know the "tests" target runs all test classes ending in "*Test" and
ignores "AllTests", while Eclipse (and probably guitests) just runs
the AllTests classes. It's likely that one or more of the AllTests
classes is failing to include, oh, about 34 tests. :)
2) Graceful LDAP fail (inside the tests themselves). Any ideas on how
to implement? The easy way would be to look for a localhost listener
on 4890 (where the OpenLDAP test fixture listens) and then not run the
tests if it isn't found. Should they FAIL or PASS in that case? It
sounds like passing is the right thing to do.
3) Differences in your test pass rate versus mine. Not sure why your
"ant tests" run would produce different results than mine. I did try
running mine with a completely new, checked-out branch. Because I
can't know what changes you might have in your local branch, could you
check out a clean copy and diff the tree versus yours? SOMETHING is
different. Also, I'd like to know what Harry and others are seeing.
Gents, any clues?
I agree that all three methods should return the same number of test
cases, and pass/fail the same ways. I also agree that tests should be
self-contained. That was part of the rationale for the Ant script
tweaks I checked in recently.
Eclipse, by the way, hasn't been reliable for me, for testing, for a
while. I tend to exhaust memory somewhere around JSPWikiMarkupParser.
But I haven't tried it in the last few months (i.e. before my massive
bug-hunting campaign).
Andrew
On Tue, Oct 27, 2009 at 3:25 AM, Janne Jalkanen
<Ja...@ecyrd.com> wrote:
>> Interestingly, I applied your most recent checkins applied (and I have
>> small one patch to JSPWikiMarkupParserTest that I haven't checked in).
>> I am running 100% clean, with no errors. Total number of tests: 1024
>> -- a nice round number. :) WikiEngineTest.testOldVersionVars has
>> been running fine for me for a while.
>
> There's no way it should've run, unless you have some old code/config files
> lying around. Can you check out a previous version to a clean directory and
> see if it runs?
>
>> As a control case, I also checked out a new built from trunk, and
>> simply typed 'ant tests'. I used a vanilla build with absolutely no
>> customizations, even to build.properties. It ran completely clean also
>> except for 1 JSPWikiMarkupParserTest test (because I haven't checked
>> in that fix), 1024 tests total.
>
> Running the AllTests from Eclipse or with "ant guitests" results in 990 test
> cases. "ant tests" is the only one giving 1024 tests, and I get 12 failures
> and 14 errors for it. LdapAuthorizerTest, LdapUserDatabaseTest and
> XMLUserDatabaseTest all fail with all tests.
>
> What I find odd is that guitests and tests targets should give the same
> results, since they both are run from build.xml.
>
>> The only other item causing the discrepancy would be if you don't have
>> a local LDAP server running for the LDAP tests. Those should cause, at
>> most, 14 failures or errors. I'll add in some code to build.xml to set
>> up the LDAP fixtures and/or disable the tests if the OpenLDAP
>> executable isn't available.
>
> I think it's probably a better idea to do the test directly in the tests
> itself. The JCR TCK throws a NonExecutableException when the test case
> cannot be executed (and this shows up as a passed test).
>
> I think it's important that all three methods give the same number of test
> cases; if the number is not reliable, it's too easy to forget to run certain
> tests.
>
> Also, I sometimes run all tests for a given package from within Eclipse. I'd
> like the test cases to be self-contained enough so that I don't have to
> remember which tests are supposed to run under which conditions.
>
> /Janne
>
Re: 2 last failing unit tests
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> Interestingly, I applied your most recent checkins applied (and I have
> small one patch to JSPWikiMarkupParserTest that I haven't checked in).
> I am running 100% clean, with no errors. Total number of tests: 1024
> -- a nice round number. :) WikiEngineTest.testOldVersionVars has
> been running fine for me for a while.
There's no way it should've run, unless you have some old code/config
files lying around. Can you check out a previous version to a clean
directory and see if it runs?
> As a control case, I also checked out a new built from trunk, and
> simply typed 'ant tests'. I used a vanilla build with absolutely no
> customizations, even to build.properties. It ran completely clean also
> except for 1 JSPWikiMarkupParserTest test (because I haven't checked
> in that fix), 1024 tests total.
Running the AllTests from Eclipse or with "ant guitests" results in
990 test cases. "ant tests" is the only one giving 1024 tests, and I
get 12 failures and 14 errors for it. LdapAuthorizerTest,
LdapUserDatabaseTest and XMLUserDatabaseTest all fail with all tests.
What I find odd is that guitests and tests targets should give the
same results, since they both are run from build.xml.
> The only other item causing the discrepancy would be if you don't have
> a local LDAP server running for the LDAP tests. Those should cause, at
> most, 14 failures or errors. I'll add in some code to build.xml to set
> up the LDAP fixtures and/or disable the tests if the OpenLDAP
> executable isn't available.
I think it's probably a better idea to do the test directly in the
tests itself. The JCR TCK throws a NonExecutableException when the
test case cannot be executed (and this shows up as a passed test).
I think it's important that all three methods give the same number of
test cases; if the number is not reliable, it's too easy to forget to
run certain tests.
Also, I sometimes run all tests for a given package from within
Eclipse. I'd like the test cases to be self-contained enough so that I
don't have to remember which tests are supposed to run under which
conditions.
/Janne
Re: 2 last failing unit tests
Posted by Andrew Jaquith <an...@gmail.com>.
Interestingly, I applied your most recent checkins applied (and I have
small one patch to JSPWikiMarkupParserTest that I haven't checked in).
I am running 100% clean, with no errors. Total number of tests: 1024
-- a nice round number. :) WikiEngineTest.testOldVersionVars has
been running fine for me for a while.
As a control case, I also checked out a new built from trunk, and
simply typed 'ant tests'. I used a vanilla build with absolutely no
customizations, even to build.properties. It ran completely clean also
except for 1 JSPWikiMarkupParserTest test (because I haven't checked
in that fix), 1024 tests total.
The only other item causing the discrepancy would be if you don't have
a local LDAP server running for the LDAP tests. Those should cause, at
most, 14 failures or errors. I'll add in some code to build.xml to set
up the LDAP fixtures and/or disable the tests if the OpenLDAP
executable isn't available.
Other than those caveats (which at the moment would cause max 15
errors/failures), like me, you should be clean. And I don't understand
why you'd just see 990 tests... Hmm...
Andrew
On Mon, Oct 26, 2009 at 5:44 PM, Janne Jalkanen
<Ja...@ecyrd.com> wrote:
>
> I uploaded priha-0.5.6 which fixes these issues. However, I'm a bit
> puzzled.
>
> I fixed WikiEngineTest.testOldVersionVars() which under *no* circumstances
> should pass on your system - it was trying to load a configuration file
> which does not exist in the SVN *at all*. So it may be that you're not
> running all of the unit test cases. I have 990 tests that get run.
>
> Second, there were several cases still which did not call
> WikiEngine.shutdown() correctly - in fact, it's not a good idea to use
> assert() in setUp() or tearDown(), since if they fail, they will now cause a
> massive cascade of failures down the stream.
>
> Second, I get 46 errors and 12 failures on the current test case set.
>
> JDBCGroupDatabaseTest, LdapAuthorizerTest, JDBCUserDatabaseTest,
> LdapUserDatabaseTest, XMLUserDatabaseTest and HtmlStringToWikiTranslatorTest
> fail with all tests; JSPWikiMarkupParserTest fails at
> testHyperlinksExtNoFollow().
>
> Didn't take a closer look at these now, but looks like there's still plenty
> of work to do :-(
>
> (BTW, the tests take a very long time to run... Priha startup takes a couple
> of seconds, so if we could figure out a way to avoid that, it would be
> useful.)
>
> /Janne
>
> On Oct 26, 2009, at 20:13 , Andrew Jaquith wrote:
>
>> Hey Janne,
>>
>> I upgraded to Priha 0.5.5, PageRenamer.testBug25 and
>> testAttachmentChange are the only unit tests that still fail (other
>> than LDAP if an LDAP test server isn't running).
>>
>> Both are failing with messages similar to this...
>>
>> Could not rename page. Reason: Looks like this Node has been removed
>> by another session: /pages/Main/RenamedTest
>>
>> org.apache.wiki.api.WikiException: Could not rename page. Reason:
>> Looks like this Node has been removed by another session:
>> /pages/Main/RenamedTest
>> at
>> org.apache.wiki.content.ContentManager.renamePage(ContentManager.java:1373)
>> at org.apache.wiki.WikiEngine.renamePage(WikiEngine.java:2330)
>> at
>> org.apache.wiki.content.PageRenamerTest.testAttachmentChange(PageRenamerTest.java:237)
>> Caused by: 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:1369)
>>
>> I did a little digging, and what seems to happen is that
>> ContentManager calls SessionImpl.move() successfully. But then the
>> save() that immediately follows throws an error. Is there anything we
>> can do inside JSPWiki to fix this? (Probably not... feels like Priha).
>>
>> Any chance you could take a peek at this? I suspect we are close to
>> closing these.
>>
>> One more quick thing: the state of the build is stabilizing. The WAR
>> builds fine, but runs a little funny because something is complaining
>> about not finding certain JCR attributes when pages are displayed.
>> This has been true since the upgrade from Priha 0.3x. I will hunt
>> these issues down...
>>
>> Oh, and lastly, it'll be good to see you (and other local wikifolk)
>> next week in Boston...
>>
>> Andrew
>
>
Re: 2 last failing unit tests
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
I uploaded priha-0.5.6 which fixes these issues. However, I'm a bit
puzzled.
I fixed WikiEngineTest.testOldVersionVars() which under *no*
circumstances should pass on your system - it was trying to load a
configuration file which does not exist in the SVN *at all*. So it
may be that you're not running all of the unit test cases. I have 990
tests that get run.
Second, there were several cases still which did not call
WikiEngine.shutdown() correctly - in fact, it's not a good idea to use
assert() in setUp() or tearDown(), since if they fail, they will now
cause a massive cascade of failures down the stream.
Second, I get 46 errors and 12 failures on the current test case set.
JDBCGroupDatabaseTest, LdapAuthorizerTest, JDBCUserDatabaseTest,
LdapUserDatabaseTest, XMLUserDatabaseTest and
HtmlStringToWikiTranslatorTest fail with all tests;
JSPWikiMarkupParserTest fails at testHyperlinksExtNoFollow().
Didn't take a closer look at these now, but looks like there's still
plenty of work to do :-(
(BTW, the tests take a very long time to run... Priha startup takes a
couple of seconds, so if we could figure out a way to avoid that, it
would be useful.)
/Janne
On Oct 26, 2009, at 20:13 , Andrew Jaquith wrote:
> Hey Janne,
>
> I upgraded to Priha 0.5.5, PageRenamer.testBug25 and
> testAttachmentChange are the only unit tests that still fail (other
> than LDAP if an LDAP test server isn't running).
>
> Both are failing with messages similar to this...
>
> Could not rename page. Reason: Looks like this Node has been removed
> by another session: /pages/Main/RenamedTest
>
> org.apache.wiki.api.WikiException: Could not rename page. Reason:
> Looks like this Node has been removed by another session:
> /pages/Main/RenamedTest
> at
> org
> .apache.wiki.content.ContentManager.renamePage(ContentManager.java:
> 1373)
> at org.apache.wiki.WikiEngine.renamePage(WikiEngine.java:2330)
> at
> org
> .apache
> .wiki
> .content.PageRenamerTest.testAttachmentChange(PageRenamerTest.java:
> 237)
> Caused by: 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:
> 1369)
>
> I did a little digging, and what seems to happen is that
> ContentManager calls SessionImpl.move() successfully. But then the
> save() that immediately follows throws an error. Is there anything we
> can do inside JSPWiki to fix this? (Probably not... feels like Priha).
>
> Any chance you could take a peek at this? I suspect we are close to
> closing these.
>
> One more quick thing: the state of the build is stabilizing. The WAR
> builds fine, but runs a little funny because something is complaining
> about not finding certain JCR attributes when pages are displayed.
> This has been true since the upgrade from Priha 0.3x. I will hunt
> these issues down...
>
> Oh, and lastly, it'll be good to see you (and other local wikifolk)
> next week in Boston...
>
> Andrew