Hi Brian, just seen you've already filed a JIRA. If you want to attach a patch in there, I'd go for adding TestEngine.emptyWorkDir(null); at setUp(). Also, I would modify TestEngine.emptyWorkDir(Properties props) to check if cache is enabled and, in that case, call CacheManager.getInstance().removalAll();
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.. br, juan pablo On Tue, Jan 21, 2014 at 8:25 PM, Brian Burch <[email protected]> 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 >>>> <[email protected]>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 <[email protected]> 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 <[email protected]> >>>>>>>>> >>>>>>>> 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 < >>>>>>>>>> >>>>>>>>>> [email protected]> 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:[email protected] >>>>> P.S. A good JDO? O, Gasp! >>>>> >>>>> >>>>> >>>> >
