New vote coming right up.
On May 29, 2009, at 8:32 PM, David Blevins wrote:
On May 29, 2009, at 7:51 PM, Jonathan Gallimore wrote:
Well done for finding it - having fiddled around with a debugger
for a while
and getting nowhere, I was thinking of doing a similar thing myself.
Yeah, first time I've pulled that trick out. Been tempted to do it
several times but have usually been lucky enough to find the issue
sooner with the debugger approach. Usually I'm the one who breaks
things, makes it easier to guess what happened :)
I have absolutely no idea why the tests pass on the VM I set up
(I'm running
them on the VM again to make sure I wasn't seeing things, and they
still
pass), I'm seeing the same error as everyone else on my work laptop
though.
I have also run the tests on Ubuntu 9.04 (Jaunty) on both x86 and
x86_64.
The 32 bit machine was running Java 1.6.0_13 while the 64 bit
machine was
running Java 1.6.0_11. The tests passed on both.
I can probably find a Windows machine to run a CI server on - is
that any
use, or does it need to run on official Apache machines?
That would be fantastic.
-David
On Sat, May 30, 2009 at 3:22 AM, David Blevins <[email protected]
>wrote:
On May 29, 2009, at 5:14 PM, David Blevins wrote:
On May 29, 2009, at 12:52 PM, Jean-Louis MONTEIRO wrote:
ubuntu jaunty (9.04) 64 bits / JDK Sun 1.6.0_13-b03 64-Bit
--> Test fails
http://www.nabble.com/file/p23786057/ubuntu-jaunty-64Bit_JDK1.6.0_13-64-64Bit.log
ubuntu-jaunty-64Bit_JDK1.6.0_13-64-64Bit.log
This failure looks like tomcat may have taken too long to start
and the
client timed out. The second log posted definitely looks like
what I'm
seeing.
I tried a route similar to Jon and grabbed a copy of Parallels
and set it
up with WinXP SP2.
cd \test
set JAVA_HOME=C:\Program Files\Java\jdk1.6.0_14
set ANT_HOME=C:\test\apache-ant-1.7.1
set PATH=%PATH%;%ANT_HOME%\bin
ant test:all
Got the expected 29 failures.
All these CI systems we have are on linux and mac.. we totally
need a
windows setup that runs this script like every day. Stuff like
this takes
so much less time when you can narrow it down to an svn revision.
So on the notion that it's easier to fix if we knew the revision I
went
ahead and did a binary search. Basically just started with middle
revision
between now and when 3.1 was released and kept splitting it in
half till i
pinned down the revision.
svn up -r $(( ($BEGIN + $END) / 2 )) && mvn clean install $skip -
Dassemble
&& installjars.sh
If the tests failed I'd set END to the current version, if they
passed I'd
set BEGIN to the current version and then just rerun.
So anyway, this is the commit that did it:
http://svn.apache.org/viewvc?rev=769395&view=rev
It claims to be for windows, still checking it out. If I revert
the change
on my copy of trunk then all itests pass on windows with no
issues. I
suspect the context path we get from Tomcat is URL syntax and not
path
syntax, so the fix actually breaks things on windows rather than
fixes
anything. I suspect that it's the test case that is faulty. Not
sure what
the issue is, but I remember seeing people on Tuscany complain
with similar
path issues.
Still looking at the test case in question..
Anyway we should be good to re-roll soon.
-David
