On 14/02/2014 17:34, Konstantin Kolinko wrote: <snip/>
> 1. org.apache.catalina.startup.TestHostConfigAutomaticDeployment > fails consistently with all connectors when running with JDK 6u45. > It runs successfully with 7u51. > The failures: > > [[[ > Testsuite: org.apache.catalina.startup.TestHostConfigAutomaticDeployment > Tests run: 137, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 49,956 sec > > Testcase: testModifyXmlExtwarUpdateExtwar took 0,251 sec > FAILED > expected:<[stopstart]> but was:<[]> > junit.framework.AssertionFailedError: expected:<[stopstart]> but was:<[]> > at > org.apache.catalina.startup.TestHostConfigAutomaticDeployment.doTestModify(TestHostConfigAutomaticDeployment.java:1220) > at > org.apache.catalina.startup.TestHostConfigAutomaticDeployment.doTestModify(TestHostConfigAutomaticDeployment.java:1079) > at > org.apache.catalina.startup.TestHostConfigAutomaticDeployment.testModifyXmlExtwarUpdateExtwar(TestHostConfigAutomaticDeployment.java:1004) > > Testcase: testModifyWarUpdateWar took 0,196 sec > FAILED > expected not same > junit.framework.AssertionFailedError: expected not same > at > org.apache.catalina.startup.TestHostConfigAutomaticDeployment.doTestModify(TestHostConfigAutomaticDeployment.java:1222) > at > org.apache.catalina.startup.TestHostConfigAutomaticDeployment.doTestModify(TestHostConfigAutomaticDeployment.java:1079) > at > org.apache.catalina.startup.TestHostConfigAutomaticDeployment.testModifyWarUpdateWar(TestHostConfigAutomaticDeployment.java:966) > > Testcase: testModifyXmlWarUpdateWar took 0,195 sec > FAILED > expected:<[stopstart]> but was:<[]> > junit.framework.AssertionFailedError: expected:<[stopstart]> but was:<[]> > at > org.apache.catalina.startup.TestHostConfigAutomaticDeployment.doTestModify(TestHostConfigAutomaticDeployment.java:1220) > at > org.apache.catalina.startup.TestHostConfigAutomaticDeployment.doTestModify(TestHostConfigAutomaticDeployment.java:1079) > at > org.apache.catalina.startup.TestHostConfigAutomaticDeployment.testModifyXmlWarUpdateWar(TestHostConfigAutomaticDeployment.java:1046) > ]]] This looks to be caused by a JVM bug (which is fixed in 1.7.x). The file is unnecessarily locked in some cases which prevents the last modified time being changed. The best description I found of the issue was on StackOverflow [1]. I'm not sure if it is exactly what we are seeing but it looks to be pretty close. I'll add a check to see if the time has been changed and explicitly fail with a note about this problem if it doesn't. Mark [1] http://stackoverflow.com/questions/1144635/setting-the-last-modified-time-of-a-directory-opened-for-readdirectorychangesw --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org