You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Kevin Jackson <fo...@gmail.com> on 2007/10/27 10:39:19 UTC
Bugs in release branch
Hi,
On Windows with JDK6, the following tests fail:
FileUtilsTest.testHasErrorInCase()
RmicAdvancedTest.testXnew
RmicAdvancedTest.testXnewForked
Error org.apache.xerces.parsers.XIncludeAwareParserConfiguration
cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration
RmicAdvancedTest.testXnewCompiler
Error org.apache.xerces.parsers.XIncludeAwareParserConfiguration
cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration
RmicAdvancedTest.testIDL
Error org.apache.xerces.parsers.XIncludeAwareParserConfiguration
cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration
RmicAdvancedTest.testIIOP
Error org.apache.xerces.parsers.XIncludeAwareParserConfiguration
cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration
LocatorTest.testNetworkURI
Failure Expected file:\\PC03\jclasses\lib\ant-1.7.0.jar to resolve to
\\PC03\jclasses\lib\ant-1.7.0.jar but got
D:\\PC03\jclasses\lib\ant-1.7.0.jar
expected:<[]\\PC03\jclasses\lib\...> but
was:<[D:]\\PC03\jclasses\lib\...>
LocatorTest.testUnixNetworkPath
Failure Expected file://cluster/home/ant/lib to resolve to
//cluster/home/ant/lib but got D:\\cluster\home\ant\lib
expected:<[//cluster/home/ant/]lib> but
was:<[D:\\cluster\home\ant\]lib>
LocatorTest.testUnixNetworkPath13
Failure Expected file://cluster/home/ant/lib to resolve to
//cluster/home/ant/lib but got D:\\cluster\home\ant\lib
expected:<[//cluster/home/ant/]lib> but
was:<[D:\\cluster\home\ant\]lib>
LocatorTest.testUnixPath
Failure Expected file:/home/ant/lib to resolve to /home/ant/lib but
got D:\home\ant\lib expected:<[/home/ant/]lib> but
was:<[D:\home\ant\]lib>
LocatorTest.testInternationalURI
Failure Expected file:/D:/L/u00f6wenbrau/aus/M/u00fcnchen to resolve
to /L\u00f6wenbrau/aus/M\u00fcnchen but got
D:\L\u00f6wenbrau\aus\M\u00fcnchen
expected:<[/L\u00f6wenbrau/aus/]M\u00fcnchen> but
was:<[D:\L\u00f6wenbrau\aus\]M\u00fcnchen>
LocatorTest.testOddLowAsciiURI
Failure Expected file:/D:/hash%23/%20and%20/percent%25 to resolve to
/hash#/ and /percent% but got D:\hash#\ and \percent%
expected:<[/hash#/ and /]percent%> but was:<[D:\hash#\ and \]percent%>
Does anyone else have these errors from the current 1.7.1 branch?
Thanks,
Kev
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Bugs in release branch
Posted by Steve Loughran <st...@apache.org>.
Jesse Glick wrote:
> Stefan Bodewig wrote:
>>>> file://cluster/home/ant/lib
>>> This is probably illegal too; AFAIK the host field is meaningless
>>> for a file-protocol URL.
>>
>> I think it is not (SMB or NFS), something like "ls //nfserver/homes/mine"
>> translates into a file URI with host.
>
> Not on Unix; NFS mounts still look like regular FS paths, e.g.
>
> /net/some.server/home/bob -> file:/net/some.server/home/bob/
>
> which has an empty and elided host field.
Apollo workstations had a filesystem with the //hostname prefix; its
where windows grabbed it form
>
> Windows has \\server\path UNC paths for which the JRE has AFAIK never
> gotten URIs quite right. You can search bugs.sun.com for "UNC URI" or
> something like that and get the story.
>
> Anyway, it seems that the test is attempting to manipulate file: URLs
> for file path syntaxes which cannot exist on the host OS. This is a
> mistake, I think. A Unix system cannot be expected to interpret
> "\\workserver\Documents and Folders\" as a real file path during a unit
> test, and a Windows system cannot be expected to treat "/home/bob" as a
> file path independent of any drive letter.
>
> -J.
>
I'll look at it after the rmic tests
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Bugs in release branch
Posted by Jesse Glick <je...@sun.com>.
Stefan Bodewig wrote:
>>> file://cluster/home/ant/lib
>> This is probably illegal too; AFAIK the host field is meaningless
>> for a file-protocol URL.
>
> I think it is not (SMB or NFS), something like "ls //nfserver/homes/mine"
> translates into a file URI with host.
Not on Unix; NFS mounts still look like regular FS paths, e.g.
/net/some.server/home/bob -> file:/net/some.server/home/bob/
which has an empty and elided host field.
Windows has \\server\path UNC paths for which the JRE has AFAIK never
gotten URIs quite right. You can search bugs.sun.com for "UNC URI" or
something like that and get the story.
Anyway, it seems that the test is attempting to manipulate file: URLs
for file path syntaxes which cannot exist on the host OS. This is a
mistake, I think. A Unix system cannot be expected to interpret
"\\workserver\Documents and Folders\" as a real file path during a unit
test, and a Windows system cannot be expected to treat "/home/bob" as a
file path independent of any drive letter.
-J.
--
jesse.glick@sun.com netbeans.org ant.apache.org hudson.dev.java.net
http://google.com/search?q=e%5E%28pi*i%29%2B1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Bugs in release branch
Posted by Stefan Bodewig <bo...@apache.org>.
On Sat, 27 Oct 2007, Jesse Glick <je...@sun.com> wrote:
> Kevin Jackson wrote:
>> LocatorTest.testNetworkURI
>> file:\\PC03\jclasses\lib\ant-1.7.0.jar
>
> This is not a syntactically valid URI, I think.
Agreed.
>> LocatorTest.testUnixNetworkPath
>> file://cluster/home/ant/lib
>
> This is probably illegal too; AFAIK the host field is meaningless
> for a file-protocol URL.
I think it is not (SMB or NFS), something like "ls //nfserver/homes/mine"
translates into a file URI with host.
>> LocatorTest.testUnixPath Expected file:/home/ant/lib to resolve to
>> /home/ant/lib but got D:\home\ant\lib expected:<[/home/ant/]lib>
>> but was:<[D:\home\ant\]lib>
>
> Doesn't look like a bug to me, looks correct, assuming you are
> running on a Windows machine.
Agreed again.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Bugs in release branch
Posted by Steve Loughran <st...@apache.org>.
Jesse Glick wrote:
> Kevin Jackson wrote:
>> LocatorTest.testNetworkURI
>> file:\\PC03\jclasses\lib\ant-1.7.0.jar
>
> This is not a syntactically valid URI, I think.
>
>> LocatorTest.testUnixNetworkPath
>> file://cluster/home/ant/lib
>
> This is probably illegal too; AFAIK the host field is meaningless for a
> file-protocol URL.
I wrote these tests. I seem to recall the whole area being a big source
of trouble. hostnames are valid in some URLs (think nfs), but the uri
handler in the JVM made a mess of them. This was stopping people running
ant off a fileshare
>
>> LocatorTest.testUnixPath
>> Expected file:/home/ant/lib to resolve to /home/ant/lib but got
>> D:\home\ant\lib
>> expected:<[/home/ant/]lib> but was:<[D:\home\ant\]lib>
>
> Doesn't look like a bug to me, looks correct, assuming you are running
> on a Windows machine. Same for the subsequent failures.
>
> -J.
>
--
Steve Loughran http://www.1060.org/blogxter/publish/5
Author: Ant in Action http://antbook.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Bugs in release branch
Posted by Jesse Glick <je...@sun.com>.
Kevin Jackson wrote:
> LocatorTest.testNetworkURI
> file:\\PC03\jclasses\lib\ant-1.7.0.jar
This is not a syntactically valid URI, I think.
> LocatorTest.testUnixNetworkPath
> file://cluster/home/ant/lib
This is probably illegal too; AFAIK the host field is meaningless for a
file-protocol URL.
> LocatorTest.testUnixPath
> Expected file:/home/ant/lib to resolve to /home/ant/lib but got D:\home\ant\lib
> expected:<[/home/ant/]lib> but was:<[D:\home\ant\]lib>
Doesn't look like a bug to me, looks correct, assuming you are running
on a Windows machine. Same for the subsequent failures.
-J.
--
jesse.glick@sun.com netbeans.org ant.apache.org hudson.dev.java.net
http://google.com/search?q=e%5E%28pi*i%29%2B1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Bugs in release branch
Posted by Steve Loughran <st...@apache.org>.
Kev Jackson wrote:
>
>> The windows tests will still be failing with bad paths, but now we can
>> decide what the correct strings are and add them to the tests, then
>> fix any locator bugs that exist.
> I guess they always passed on gump as it was running on linux/bsd, which
> is why we didn't see any problems until now.
>
> And yes most of the tests looked fine to me before which was why I
> couldn't believe no-one else was having a problem - now I know, I'm the
> only one using windows!
I hope to set up a vmware image of win2k03 server running hudson or
bamboo soonish; I could set it to do ant head too. It will stop me doing
windows proof work.
Last week I added the file sshexec.sf to the repository, alongside an
existing file sshExec. Everything works for me, but someone else got
wierd errors from SVN about being unable to copy a file because it
existed. Even clean checkouts didnt work.
of course, the reason is simple, windows doesnt like two files of the
same name in the same directory; I'd broken the build.
Which is why I need a CI server on windows, because the linux ones catch
different problems.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Bugs in release branch
Posted by Kev Jackson <fo...@gmail.com>.
> The windows tests will still be failing with bad paths, but now we can
> decide what the correct strings are and add them to the tests, then
> fix any locator bugs that exist.
I guess they always passed on gump as it was running on linux/bsd, which
is why we didn't see any problems until now.
And yes most of the tests looked fine to me before which was why I
couldn't believe no-one else was having a problem - now I know, I'm the
only one using windows!
Kev
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Bugs in release branch
Posted by Steve Loughran <st...@apache.org>.
I've tweaked the locator tests to take a string of expected values for
both windows and unix systems, so we can hard code what we expect for both
Steve Loughran wrote:
>
>>
>> LocatorTest.testInternationalURI
>> Failure Expected file:/D:/L/u00f6wenbrau/aus/M/u00fcnchen to resolve
>> to /L\u00f6wenbrau/aus/M\u00fcnchen but got
>> D:\L\u00f6wenbrau\aus\M\u00fcnchen
>> expected:<[/L\u00f6wenbrau/aus/]M\u00fcnchen> but
>> was:<[D:\L\u00f6wenbrau\aus\]M\u00fcnchen>
>
> again, the results look correct.
actuall
[junit] Testcase: testInternationalURI took 0.003 sec
[junit] FAILED
[junit] expected 0xf6 (\u00f6), but got 5c '\' expected:<246> but
was:<92>
[junit] junit.framework.AssertionFailedError: expected 0xf6
(\u00f6), but got 5c '\' expected:<246> but was:<92>
There was a bug in the tests here, we were double escaping the \u
symbol. I've fixed that and got the string being returned, so we now
test for the explicit unicode char coming back. Oh, and I handle the
current directory being stuck in ahead of the path by moving to relative
paths and prefixing the cwd in the comparison.
here's the new test, that passes on unix
public void testInternationalURI() throws Exception {
String result=assertResolves("L\u00f6wenbrau.aus.M\u00fcnchen");
char umlauted = result.charAt(1);
assertEquals("expected 0xf6 (\u00f6), but got
"+Integer.toHexString(umlauted)+" '"+umlauted+"'",
0xf6, umlauted);
}
The windows tests will still be failing with bad paths, but now we can
decide what the correct strings are and add them to the tests, then fix
any locator bugs that exist.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Bugs in release branch
Posted by Steve Loughran <st...@apache.org>.
Kevin Jackson wrote:
> LocatorTest.testNetworkURI
> Failure Expected file:\\PC03\jclasses\lib\ant-1.7.0.jar to resolve to
> \\PC03\jclasses\lib\ant-1.7.0.jar but got
> D:\\PC03\jclasses\lib\ant-1.7.0.jar
> expected:<[]\\PC03\jclasses\lib\...> but
> was:<[D:]\\PC03\jclasses\lib\...>
I dont think this is correct.
C:\>dir \\morzine\slo\projects.tar
Volume in drive \\morzine\slo is slo
Volume Serial Number is 10BB-0117
Directory of \\morzine\slo
2006-03-24 10:14 6,451,200 projects.tar
1 File(s) 6,451,200 bytes
0 Dir(s) 401,221,718,016 bytes free
(a) its a valid path
(b) SATA disk drives are very big
>
> LocatorTest.testUnixNetworkPath
> Failure Expected file://cluster/home/ant/lib to resolve to
> //cluster/home/ant/lib but got D:\\cluster\home\ant\lib
> expected:<[//cluster/home/ant/]lib> but
> was:<[D:\\cluster\home\ant\]lib>
should maybe go to \\cluster\home\ant\lib
>
> LocatorTest.testUnixNetworkPath13
> Failure Expected file://cluster/home/ant/lib to resolve to
> //cluster/home/ant/lib but got D:\\cluster\home\ant\lib
> expected:<[//cluster/home/ant/]lib> but
> was:<[D:\\cluster\home\ant\]lib>
same
>
> LocatorTest.testUnixPath
> Failure Expected file:/home/ant/lib to resolve to /home/ant/lib but
> got D:\home\ant\lib expected:<[/home/ant/]lib> but
> was:<[D:\home\ant\]lib>
looks correct
>
> LocatorTest.testInternationalURI
> Failure Expected file:/D:/L/u00f6wenbrau/aus/M/u00fcnchen to resolve
> to /L\u00f6wenbrau/aus/M\u00fcnchen but got
> D:\L\u00f6wenbrau\aus\M\u00fcnchen
> expected:<[/L\u00f6wenbrau/aus/]M\u00fcnchen> but
> was:<[D:\L\u00f6wenbrau\aus\]M\u00fcnchen>
again, the results look correct.
> LocatorTest.testOddLowAsciiURI
> Failure Expected file:/D:/hash%23/%20and%20/percent%25 to resolve to
> /hash#/ and /percent% but got D:\hash#\ and \percent%
> expected:<[/hash#/ and /]percent%> but was:<[D:\hash#\ and \]percent%>
looks ok
>
> Does anyone else have these errors from the current 1.7.1 branch?
No, because I'm not running windows right now :)
Looking at the locator code, we used to choose between java.net.URI on
Java1.4+, and our own uri mapping logic on java <=1.3, but switched to
only using our own code as we got tired of URI mapping issues in the
java classes.
It looks like
(1) -all the tests are unix-centric
(2) -//hostname/file is a legitimate path in windows; should map to
\\hostname\file with no drive prefix
We can fix (1) by declaring the expected string for windows too.
(2) this is a bug to fix
--
Steve Loughran http://www.1060.org/blogxter/publish/5
Author: Ant in Action http://antbook.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Bugs in release branch
Posted by Martijn Kruithof <jm...@kruithof.xs4all.nl>.
Hi
Using ant 1.7.1 alpha on jdk 1.6 i have the same junit test failures ( 7
failures and 5 errors) and some antunit testcases fail 1 error, 2
failures (Furthermore it blocks halfway the test until user input is
received imo this is annoying for automated testing.)
results: http://kruithof.xs4all.nl/ant/ant-17branch-16
Using ant 1.7.1 alpha on jdk 1.4 i have for junit 7 failures (the same
ones) / no errors and 4 failures and 7 errors on the antunit test cases.
results: http://kruithof.xs4all.nl/ant/ant-17branch-14
Using ant 1.8 alpha on jdk 1.6 i have for junit 6 errors and 6 failures
and for antunit 3 failures and 7 errors (also this one blocks halfway
the test until user input is received)
results: http://kruithof.xs4all.nl/ant/ant-trunk-16
Using ant 1.8 alpha on jdk 1.4 i have for junit 1 error and 6 failures
(the same ones) / 3 failures and 7 errors on the antunit test cases.
results: http://kruithof.xs4all.nl/ant/ant-trunk-14
Martijn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Bugs in release branch -rmic
Posted by Steve Loughran <st...@apache.org>.
Kevin Jackson wrote:
> Hi,
>
> On Windows with JDK6, the following tests fail:
I see the rmi tests on linux+the latest jdk6 too.
>
> RmicAdvancedTest.testXnew
rmic.testXnew:
[base-rmic] RMI Compiling 1 class to
/home/slo/Java/Apache/ant/src/etc/testcases/taskdefs/rmic/build
[base-rmic] rmic: error - Doclet class sun.rmi.rmic.newrmic.Main does
not contain a start method
[base-rmic] 1 error
Well, there's our problem.
Actually, this whole area was trouble, look at this bug. that the
XNewRmic compiler points to
http://issues.apache.org/bugzilla/show_bug.cgi?id=38732
and, from the command line, xnewForked works
======================================================================
Entering project
In /home/slo/Java/Apache/ant/src/etc/testcases/taskdefs/rmic
======================================================================
rmic.testXnewForked:
[base-rmic] RMI Compiling 1 class to
/home/slo/Java/Apache/ant/src/etc/testcases/taskdefs/rmic/build
1. the testXnew should be skipped for Java6; don't know about
successors. But ignore this particular failure as it is something going
in rmic that we can't handle.
>
> RmicAdvancedTest.testXnewForked
> Error org.apache.xerces.parsers.XIncludeAwareParserConfiguration
> cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration
Now, this is fun. This routine works from the command line.
But under junit,
[junit] org.apache.xerces.parsers.XIncludeAwareParserConfiguration
cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration
[junit] java.lang.ClassCastException:
org.apache.xerces.parsers.XIncludeAwareParserConfiguration cannot be
cast to org.apache.xerces.xni.parser.XMLParserConfiguration
[junit] at org.apache.xerces.parsers.SAXParser.<init>(Unknown
Source)
[junit] at org.apache.xerces.parsers.SAXParser.<init>(Unknown
Source)
[junit] at
org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.<init>(Unknown Source)
[junit] at org.apache.xerces.jaxp.SAXParserImpl.<init>(Unknown
Source)
[junit] at
org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source)
[junit] at
org.apache.tools.ant.util.JAXPUtils.newSAXParser(JAXPUtils.java:215)
[junit] at
org.apache.tools.ant.util.JAXPUtils.getNamespaceXMLReader(JAXPUtils.java:172)
[junit] at
org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:182)
[junit] at
org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:138)
[junit] at
org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:93)
[junit] at
org.apache.tools.ant.BuildFileTest.configureProject(BuildFileTest.java:289)
[junit] at
org.apache.tools.ant.BuildFileTest.configureProject(BuildFileTest.java:272)
[junit] at
org.apache.tools.ant.taskdefs.RmicAdvancedTest.setUp(RmicAdvancedTest.java:44)
Except, what happens if I coment out testXnew()?
apache-ant.junit-single-test-only:
[mkdir] Created dir: /home/slo/Java/Apache/ant/build/failingTests
[mkdir] Created dir: /home/slo/Java/Apache/ant/build/testcases/xml
[junit] Testsuite: org.apache.tools.ant.taskdefs.RmicAdvancedTest
[junit] Tests run: 23, Failures: 0, Errors: 0, Time elapsed: 9.004 sec
[junit] Testcase: testDefault took 0.597 sec
[junit] Testcase: testEmpty took 0.29 sec
[junit] Testcase: testRmic took 0.282 sec
[junit] Testcase: testRmicJArg took 0.284 sec
[junit] Testcase: testKaffe took 0.2 sec
[junit] Testcase: testWlrmic took 0.248 sec
[junit] Testcase: testWlrmicJArg took 0.171 sec
[junit] Testcase: testForkingAntClasspath took 0.745 sec
[junit] Testcase: testAntClasspath took 0.443 sec
[junit] Testcase: testBadName took 0.164 sec
[junit] Testcase: testExplicitClass took 0.289 sec
[junit] Testcase: testWrongClass took 0.196 sec
[junit] Testcase: testDefaultBadClass took 0.216 sec
[junit] Testcase: testMagicProperty took 0.185 sec
[junit] Testcase: testMagicPropertyOverridesEmptyString took 0.155 sec
[junit] Testcase: testMagicPropertyIsEmptyString took 0.227 sec
[junit] Testcase: testVersion11 took 0.216 sec
[junit] Testcase: testVersion12 took 0.262 sec
[junit] Testcase: testVersionCompat took 0.29 sec
[junit] Testcase: testXnewForked took 1.146 sec
[junit] Testcase: testXnewCompiler took 1.214 sec
[junit] Testcase: testIDL took 0.793 sec
[junit] Testcase: testIIOP took 0.348 sec
Hypothesis: running -Xnew compiler in Java6 unforked screws up Ant for
the rest of the life of the process, by fiddling with the XML factories.
Whoever wrote that code made some assumptions about running in a self
contained process that doesnt hold.
Here's some options
1. Turn off testXNew
-stops rmic failing, stops the followon tests failing. hides any
problems with rmic on java
2 patch SunRmic to see the -Xnew parameter, and fail the build, tell
the user they need to fork the jvm
-changes test outcome on java6+, but leads to a better end user experience
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org