Bug 59104 - <makeurl> generates the wrong URL on Windows
Summary: <makeurl> generates the wrong URL on Windows
Status: NEW
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.9.4
Hardware: PC All
: P2 normal (vote)
Target Milestone: ---
Assignee: Ant Notifications List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-03 04:09 UTC by Trejkaz (pen name)
Modified: 2017-12-09 04:44 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Trejkaz (pen name) 2016-03-03 04:09:07 UTC
In our build, we are using <makeurl> to generate the URL for log4j.configuration:

    <makeurl file="${project.dir}/src/config/log4j.properties"
             property="log4j.configuration.url"/>

On Windows, log4j fails to loadf the configuration, because the URL Ant has generated is missing one slash.

[exec] log4j:ERROR Could not read configuration file from URL [file://H:/hudson/sharedspace/trunk/os/windows/src/config/log4j.properties].
java.net.UnknownHostException: H
	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:184)
	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
	at java.net.Socket.connect(Socket.java:589)
	at java.net.Socket.connect(Socket.java:538)
	at sun.net.ftp.impl.FtpClient.doConnect(FtpClient.java:957)
	at sun.net.ftp.impl.FtpClient.tryConnect(FtpClient.java:917)
	at sun.net.ftp.impl.FtpClient.connect(FtpClient.java:1012)
	at sun.net.ftp.impl.FtpClient.connect(FtpClient.java:998)
	at sun.net.www.protocol.ftp.FtpURLConnection.connect(FtpURLConnection.java:294)
	at sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(FtpURLConnection.java:393)
	at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:557)
	at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:526)
	at org.apache.log4j.LogManager.<clinit>(LogManager.java:127)
	at org.apache.log4j.Logger.getRootLogger(Logger.java:135)
	at Main.main(Main.java:59)

So as you can see, it has generated:
    file://H:/hudson/sharedspace/trunk/os/windows/src/config/log4j.properties
But it should have been:
    file:///H:/hudson/sharedspace/trunk/os/windows/src/config/log4j.properties

Ant isn't doing anything particularly mysterious to convert it:

        return new File(path).toURI().toASCIIString();

But back in v1.6.5, there was code that appears to be special casing this exact thing:

        // catch exception if normalize thinks this is not an absolute path
        try {
            path = normalize(path).getAbsolutePath();
            sb.append("//");
            // add an extra slash for filesystems with drive-specifiers
            if (!path.startsWith(File.separator)) {
                sb.append("/");
            }
        } catch (BuildException e) {
            // relative path
        }

So I think it's fair to consider this a regression in Ant even if the real bug is in the JRE.

The code in v1.9.6 is using the same utility method, so I'm assuming it will cause the same behaviour and haven't tried upgrading to it.
Comment 1 Jaikiran Pai 2017-11-05 02:59:18 UTC
Is this still reproducible? I don't have a Windows setup to test this. Can you tell us a bit more about which Java vendor and version you are using? You can paste the output of the following command:

java -version
Comment 2 Trejkaz (pen name) 2017-11-05 03:27:20 UTC
It's just Oracle's Java 8u92... but enough time has passed that we have stopped using Ant for the area where the problem originally occurred anyway.
Comment 3 Jaikiran Pai 2017-11-05 03:50:56 UTC
Thank you for providing that detail. I'm curious on this one since this one has now been reported in more than one place. I'll try and see if this can be narrowed down to something specific, once I get access to some Windows setup.
Comment 4 Jan Mat 2017-11-07 20:42:02 UTC
I did a small test:
<project>
    <mkdir dir="bak"/>
    <makeurl file="build.xml" property="url"/>
    <echo>url=${url}</echo>
    <get src="${url}" dest="bak"/>
    <loadresource property="content">
        <url url="${url}"/>
    </loadresource>
    <echo>content=${content}</echo>
</project>

this worked on my win7 machine.


The code basically wrapps "new File(path).toURI().toASCIIString()", so we rely on the Java core. 

Maybe I haven't found the exact source ...
https://tools.ietf.org/html/rfc3986 (URI): have read some paragraphs where I think three slashes are mandatory, but also some paragraphs where I think two are ok.

I also found https://blogs.msdn.microsoft.com/ie/2006/12/06/file-uris-in-windows/
This basically sais:
* If you have an UNC path (with the computer name included) you have two slashes
* If you have a local path (with the drive letter included) you have three slashes

So maybe this conversion is wrong.
But than this is a bug in the Java core (I think).
Comment 5 Jaikiran Pai 2017-12-09 04:44:40 UTC
Jan, you are right - this most likely will end up being something (either a bug or a differing implementation) of the JRE. However, I haven't yet been able to narrow it down to a specific set of OS and JRE combination. This same issue has been reported in various different places (in Ant and Ivy) in various different use cases and that's what made me look into this. Most of the times (almost always?), the issue has been reported on Windows. I don't have access to any Windows system to be able to spend some time to narrow this down.