[VFS-23] [vfs] VFS discards host part of URL when commons-httpclient jar not in classpath

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed

Environment

Operating System: other
Platform: Other

• Bugzilla Id: 35520
• Assignee: Unassigned
• Reporter: Jacob Kjome
• Created: 28/Jun/05 14:36
• Updated: 25/Mar/08 07:52
• Resolved: 25/Mar/08 07:52

Description

I built VFS from source on 20050625. I tried using it to download the new
3.0-rc3 of commons-httpclient using the <vfs:copy> ant task. Here's the output...

D:\dev\TheHartford\mtk\utility-targets.incl:404: Could not determine the type of
file
"http:///dist/jakarta/commons/httpclient/binary/commons-httpclient-3.0-rc3.tar.gz".

line 404 is:
<vfs:v-copy src="@

{srcfile}

" destfile="${dependenciesdir}/aFile" overwrite="true"/>

Notice the URL in the error. Something must be cutting off some of the
important parts of that URL. Here's the URL I actually passed to it...

http://archive.apache.org/dist/jakarta/commons/httpclient/binary/commons-httpclient-3.0-rc3.tar.gz

VFS seems to have discarded "archive.apache.org". That's not so good! For a
sanity check, I moved back to a verson of VFS built on 20050603 (just after the
fix committed for COM-2096 ). Here's the output...

[vfs:v-copy] Copying
http://archive.apache.org/dist/jakarta/commons/httpclient/binary/commons-httpclient-3.0-rc3.tar.gz
to file://D:/dev/java_repository/aFile

Hmmm... success! So, it seems that there is a bug somewhere in the more recent
code that is discarding part of the URL. The reason I found this is that I use
the VFS task to bootstrap itself. It starts by downloading VFS and its core
dependencies using Ant's <get> task. Then the bootstrapping moves to VFS
itself. As it downloads more optional dependencies, it gains more power to
perform operations that only the optional dependencies will provide for.
commons-httpclient is one of those optional dependencies that provides the basis
for much of the more interesting features of VFS. VFS can't use it before it
downloads it, so VFS must fall back to its own basic http functionality to
download commons-httpclient. As it happens, it seems that VFS's basic http
fallback code discards the host part of the URL. If commons-httpclient is
provided to VFS beforehand, it has not problem.

Steps to reproduce:
1. Use commons-vfs without commons-httpclient in the classpath to download a
file using http (URL for httpclient is the only one I tested)
2. Watch it fail

This shouldn't be hard to reproduce, but if you want a ready-made testcase, just
modify the testcase I added to COM-2096 (
http://issues.apache.org/bugzilla/attachment.cgi?id=15197 ) by adding the
following target...

<target name="test-vfs-3">
<echo>commons-httpclient Available? ${commons-httpclient.available}</echo>
<util-macroDownload
srcfile="http://archive.apache.org/dist/jakarta/commons/httpclient/binary/commons-httpclient-3.0-rc3.tar.gz"

destfile="${librarycachedir}/commons-httpclient-3.0-rc3.tar.gz"
projectname="commons-httpclient"/>
<echo>commons-httpclient Available? ${commons-httpclient.available}</echo>
</target>

Jake