On 23/01/14 17:24, Juan Pablo Santos Rodríguez wrote:
Hi Brian,
just seen you've already filed a JIRA.
Yes. I am fine-tuning the code at this moment, so please wait until I
attach my proposed change. You can then review it and modify it as you
feel best.
If you want to attach a patch in
there,
Attaching a patch file is trivial under bugzilla. I can't find out how
to do it with a JIRA, but I have stumbled over a recipe on some other
project's mailing list. Surely a search on JIRA for "how do I attach a
patch to a JIRA" should come up with an FAQ or wiki page recipe as the
FIRST hit, rather than a bug against Atlassian from 2006?
I'd go for adding TestEngine.emptyWorkDir(null); at setUp().
Yes, that is essential. I thought it was more logical done in
tearDown(), given that it is a class method which works from the current
"combined" properties, but that didn't do the job.
Also, I
would modify TestEngine.emptyWorkDir(Properties props) to check if cache is
enabled and, in that case, call CacheManager.getInstance().removalAll();
OK, I think I understand. I assumed that caching would always be enabled
given the choice of properties taken by the suite, but perhaps your
suggestion would make the test more bullet-proof?
Regarding the page renaming, it was to confirm that those pages
specifically where causing the tests failures. Mi idea was to look into
other tests for those page name references in order to locate the tests
which are not properly cleaning up after execution. However, there are +100
occurrences of those pages under src/test/java, so it doesn't seem as
something straightforward..
I agree. In the short term it is better to isolate this suite from that
kind of pollution. We can chase down other cases as they arise.
Oh yes, I have reverted those file name changes. I have also coded a
more general way to delete all pages in the wiki directory. I think it
is better placed in the TestEngine class, rather than in
ReferenceManagerTest.tearDown.
It did occur to me that, rather than each suite sharing the same (or
nearly) properties, which include explicit directory paths, we ought to
consider changing the way the suites set themselves up. Probably by
generating system-unique paths for each test subdirectory.
I just stopped my debugger during setup and looked inside
jspwiki-war/target/test-classes/. As well as testrepository/ and
testworkdir/, there are several other directories e.g.
testrepository1390499022308/ and testworkdir1390499022308/, so some of
the suites are already doing the kind of "unique runtime environment"
trick I had in mind. It should be done EVERYWHERE.
Let's just fix this particular bug for now, though.
Look out for my svn patch tomorrow, I hope.
Thanks,
Brian
br,
juan pablo
On Tue, Jan 21, 2014 at 8:25 PM, Brian Burch <br...@pingtoo.com> wrote:
On 21/01/14 17:37, Brian Burch wrote:
On 21/01/14 16:51, Brian Burch wrote:
On 20/01/14 20:50, Juan Pablo Santos Rodríguez wrote:
Hi Brian,
would mind performing a couple of changes to see if they solve your
build
issue:
1) substitute lines 50-63 on setUp at ReferenceManagerTest, with the
following lines:
TestEngine.emptyWorkDir(null);
CacheManager.getInstance().removalAll();
and then mvn clean install
2) change all references to TestPage to another name i.e. replace all
"TestPage" occurences on ReferenceManagerTest with anything else,
like, for
example "RMTestPage". Same for "FooBar" (for example to "RMFooBar"), and
then mvn clean install. I suspect those two pages are created by other
tests, leaving unwanted data. This doesn't have to be done after first
point, but rather as another independent test, to see if those pages are
causing the issue by being created and not cleaned up on another test
case
I have started the second change and it has gone haywire! I'm trying to
debug the reason why half the tests are failing.
ReferenceManager.findReferrers() uses a null return to signal that it
did not find any matching pages.
Would you please commit a change to ReferenceManagerTest where EVERY
call to findReferrers which expects a non-null value is followed by:
assertNotNull("referrers expected", c);
I appreciate that these tests would normally have a non-null value
assigned to c, but in my broken case the resultant NPE's within jUnit's
assertTrue are untidy and a bit confusing.
Meanwhile, I will return to figure out what I have done wrong.
My fault! I didn't realise the pagenames had to be capitalised in this
test, so I was using things like bbFooBar and they were getting
capitalised by the engine to BbFooBar.
I am working my way through each test case and adding lots of comments
as well as the assertNotNull tests. I'll submit a patch file soon.
OK, Juan Pablo, the second suggestion resolves the failures too. You were
correct in suspecting the rogue files were being left by another test
suite, but I don't know which one.
The fact that my laptop always failed from a command prompt or under
netbeans, while both cases worked on my desktop, suggests it is a timing
and/or parallelism bug. The desktop is dual-core, while the failing laptop
is quad-core. The individual processor speeds are about the same.
I have added a LOT of comments to the test class and tidied-up the
assertions. I think these changes should be committed, but am unsure about
the best approach.
1. Do you think the best solution is 1 or 2 of your suggestions? I think
the cleanest is number 1, because it guarantees the (dirty) page directory
is emptied out before each test case. Option 2 leaves the clash exposed,
but avoids it for now by using less common page names.
2. Should I open a JIRA for the bug and then append my patch? I'm a little
confused after working on tomcat, where the bugs/enhancements are managed
via apache bugzilla.
Regards,
Brian
Thanks,
Brian
thx + br,
juan pablo
On Sat, Jan 18, 2014 at 5:32 PM, Craig L Russell
<craig.russ...@oracle.com>wrote:
On Jan 18, 2014, at 3:31 AM, Brian Burch wrote:
On 18/01/14 10:32, Harry Metske wrote:
Brian,
there is a small mvn cheatsheet in the root of the project (I ask
myself
this same question too every time) :
http://svn.apache.org/viewvc/jspwiki/trunk/mvn_cheat-sheet.
txt?view=markup
So this would be the mvn equivalent: mvn test
-Dtest=org.apache.wiki.ReferenceManagerTest
In my experience, there's no need to qualify the name of the test.
Maven
does a match on the name given, regardless of its fully qualified
name. So
the above should be -Dtest=ReferenceManagerTest and should work
whatever
the current directory.
Regards,
Craig
Thanks for your suggestion Harry.
1. It failed "no test found" when I ran it under the highest
project. I
guessed right that it would work once I cd'ed into the jspwiki-war
subdirectory.
2. I set the compiler parameter in front of the "test" goal (I was
happier with ant style), rather than after as you suggested. That
worked
for me.
3. The single test suite runs ok under maven from a linux command
prompt
- all 18 cases successful.
Hmmm. Useful diagnostic information in a negative sort of way.
Looks like I need some help choosing break points. Pity I will be
forced
to run the entire project test suite under netbeans to reproduce the
failure!!!
Brian
kind regards,
Harry
On 18 January 2014 11:26, Brian Burch <br...@pingtoo.com> wrote:
On 18/01/14 01:03, Juan Pablo Santos Rodríguez wrote:
(changed thread subject in order to not pollute the vote thread)
Hi Brian,
a couple of questions:
did you an "mvn install" or "mvn clean install"? if the first, did
you do
it on a fresh copy or over a working copy?
Clean checkout, then "mvn install".
Just to be paranoid, I have now done "svn update" (nothing changed),
"mvn
clean install". The same 2 tests fail, although everything else
succeeds.
can you run those tests individually on your IDE? maybe there
is an
issue
related to tests execution order
(https://builds.apache.org/job/JSPWiki/does the build fine, as
https://analysis.apache.org/jenkins/job/jspwiki/, and I cannot
reproduce
on
my local environment)
I just opened rc2 as a new project under netbeans and ran the suite
org.apache.wiki.ReferenceManagerTest. ALL 18 tests pass.
In my experience, it is less likely to be a suite execution order
problem.
Much more likely there is a test case exec order problem.
I mostly work with ant projects. Can you save me time by telling
me the
maven equivalent of the following:
ant -Dtest.entry=org.apache.wiki.ReferenceManagerTest test
so I can see what happens to the test when it is executed on its own
outside my ide?
could you verify you have an
$WORKSPACE/jspwiki-war/target/test-classes/testworkdir/refmgr.ser
file
when
the tests fail?
That file still exists after the "mvn install" has failed. It is
binary -
is there any point looking inside it?
Regards,
Brian
br,
juan pablo
On Fri, Jan 17, 2014 at 10:54 AM, Brian Burch <br...@pingtoo.com>
wrote:
On 15/01/14 20:48, Harry Metske wrote:
+1
kind regards,
Harry
I only started working on 2.10 this week, so I don't want to
spoil
the
party!
I checked out the trunk at r1557110 on my main dev machine and it
built
and tested perfectly.
Yesterday, while preparing for a trip, I checked out the trunk at
r1559044
on my laptop. mvn install fails two tests.
Rather than mess around with the evolving trunk, I have just
checked
out
RC2 on my laptop. The two tests fail in the same way as the trunk.
The
following report is taken from RC2:
------------------------------------------------------------
-------------------
Test set: org.apache.wiki.ReferenceManagerTest
------------------------------------------------------------
-------------------
Tests run: 18, Failures: 0, Errors: 2, Skipped: 0, Time elapsed:
0.95 sec
<<< FAILURE! - in org.apache.wiki.ReferenceManagerTest
testUpdateBothExist(org.apache.wiki.ReferenceManagerTest) Time
elapsed:
0.063 sec <<< ERROR!
java.lang.NullPointerException: null
at org.apache.wiki.providers.BasicAttachmentProvider.
deleteAttachment(BasicAttachmentProvider.java:692)
at org.apache.wiki.providers.CachingAttachmentProvider.
deleteAttachment(CachingAttachmentProvider.java:327)
at org.apache.wiki.attachment.AttachmentManager.
deleteAttachment(
AttachmentManager.java:605)
at
org.apache.wiki.WikiEngine.deletePage(WikiEngine.java:2188)
at org.apache.wiki.ReferenceManagerTest.tearDown(
ReferenceManagerTest.java:76)
testSelf(org.apache.wiki.ReferenceManagerTest) Time elapsed:
0.045
sec
<<< ERROR!
org.apache.wiki.InternalWikiException: Refmgr out of sync: page
Foobar
refers to Foobars, which has null referrers.
at org.apache.wiki.ReferenceManager.pageRemoved(
ReferenceManager.java:625)
at org.apache.wiki.ReferenceManager.actionPerformed(
ReferenceManager.java:1177)
at org.apache.wiki.event.WikiEventManager$
WikiEventDelegate.fireEvent(WikiEventManager.java:562)
at org.apache.wiki.event.WikiEventManager.fireEvent(
WikiEventManager.java:344)
at
org.apache.wiki.PageManager.fireEvent(PageManager.java:701)
at
org.apache.wiki.PageManager.deletePage(PageManager.java:548)
at
org.apache.wiki.WikiEngine.deletePage(WikiEngine.java:2191)
at org.apache.wiki.ReferenceManagerTest.tearDown(
ReferenceManagerTest.java:77)
Both systems run ubuntu 13.10 and are fairly similar - the laptop
has the
low latency kernel and the desktop uses generic. Both run 32 bit
3.11.0-15
kernels. I don't think this is a relevant factor.
Both systems run the same default jdk:
java version "1.7.0_25"
OpenJDK Runtime Environment (IcedTea 2.3.12)
(7u25-2.3.12-4ubuntu3)
OpenJDK Server VM (build 23.7-b01, mixed mode)
I haven't yet checked out RC2 on my desktop, but I expect it would
work.
Is this a known problem? If not, what can I do to help diagnose it
further?
Regards,
Brian
On 14 January 2014 23:08, Juan Pablo Santos Rodríguez <
juanpablo.san...@gmail.com> wrote:
This is a release vote for Apache JSPWiki, version 2.10.0. The
vote
will
be
open for at least 72 hours from now.
It fixes the following issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?
projectId=12310732&version=12323941
Note that we are voting upon the source (tag), binaries are
provided
for
convenience.
Everybody is encouraged to vote.
Source and binary files:
http://people.apache.org/~juanpablo/releases/2.10.0-rc2
Nexus staging repo:
https://repository.apache.org/content/repositories/
orgapachejspwiki-1000/
The tag to be voted upon:
http://svn.apache.org/repos/asf/jspwiki/tags/jspwiki_2_10_0_rc2
JSPWiki's KEYS file containing PGP keys we use to sign the
release:
http://svn.apache.org/repos/asf/jspwiki/tags/jspwiki_2_10_
0_rc2/KEYS
*** Please download, test and vote:
[ ] +1 Approve the release
[ ] 0 Don't mind
[ ] -1 Disapprove the release (please provide specific comments)
br,
juan pablo
Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:craig.russ...@oracle.com
P.S. A good JDO? O, Gasp!
