9 Replies Latest reply on Nov 21, 2006 2:40 PM by Scott Stark

    Another problem with jar urls

    Scott Stark Master

      Another example of why we need to drop jar urls is that one cannot obtain an InputStream from which to copy the jar:

       public void testJarURLCopy()
       throws Exception
       FileOutputStream fos = new FileOutputStream("/tmp/x.jar");
       JarOutputStream jos = new JarOutputStream(fos);
       JarEntry je = new JarEntry("META-INF/MANIFEST.MF");
       jos.write("Manifest-Version: 1.0\r\n".getBytes());
       FileInputStream fis = new FileInputStream("/tmp/x.jar");
       byte[] buffer = new byte[128];
       int read;
       int count = 0;
       while( (read = fis.read(buffer)) > 0 )
       count += read;
       System.out.println("Read "+count+" bytes from x.jar");
       URL jarURL = new URL("jar:file:/tmp/x.jar!/");
       InputStream is = jarURL.openStream();
       int count2 = 0;
       while( (read = is.read(buffer)) > 0 )
       count2 += read;
       System.out.println("Read "+count+" bytes from x.jar");
       assert count == count2 : "expected count == count2";

      Running this produces:
      [starksm@succubus x]$ java tstjar
      Read 189 bytes from x.jar
      Exception in thread "main" java.io.IOException: no entry name specified
       at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:129)
       at java.net.URL.openStream(URL.java:1007)
       at tstjar.main(tstjar.java:31)

      To work around this in the vfs level the openStream implementation of a jar needs to detect if it refers to the jar itself and unwrap the jar url to obtain a usable url connection.
      We do need to move to custom vfs urls and handlers to have consistent behvior.