Uploaded image for project: 'Commons VFS'
  1. Commons VFS
  2. VFS-23

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

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Environment:

      Operating System: other
      Platform: Other

    • Bugzilla Id:
      35520

      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

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              hoju Jacob Kjome
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: