DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=35520>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35520 Summary: [vfs] VFS discards host part of URL when commons- httpclient jar not in classpath Product: Commons Version: unspecified Platform: Other OS/Version: other Status: NEW Severity: major Priority: P2 Component: VFS AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] 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 bug 34942 ). 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 bug 34942 ( 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 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
