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

    Another problem with jar urls

    starksm64

      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.putNextEntry(je);
       jos.write("Manifest-Version: 1.0\r\n".getBytes());
       jos.write("\r\n".getBytes());
       jos.close();
      
       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;
       }
       fis.close();
       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;
       }
       is.close();
       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.


        • 1. Re: Another problem with jar urls
          bill.burke

          I found out that the hard way as well.... You have to do openConnection() typecast it to JarUrlConnection to gain access.

          Another way to do it which I experimented with was to *not* put "jar:" in front of jarfiles for the URL. I don't know why that was done in the first place other than to make the code a little easier to write.

          In my "vfsfile:" prototype, I had the Handlers spit out the "real" URLs while VirtualFile.toURL() would return a "vfsfile:" based URL. The AbstractJarHandler would always return a "file:" based URL. Only jarentries would return a "jar:" based one.

          • 2. Re: Another problem with jar urls
            starksm64

            As an intermediate change between doing a full vfs* url and the current jar: url, it would be better to just drop jar urls altogether. There is nothing good about them. After the beta next week I'll look at refactoring the jar handling to drop this as well as to allow for alternate jar handler implementations like truzip as I don't trust that we have sufficient control over the current java JarFile impl because of its native elements.

            • 3. Re: Another problem with jar urls
              bill.burke

              I could do this after Nov 20th. I've already done it once.

              • 4. Re: Another problem with jar urls
                starksm64

                Fine. We need the prototype checked in somewhere as well as some point to further validate.

                • 5. Re: Another problem with jar urls
                  bill.burke

                  BTW, I'm not a big fan of truzip. It is all java.io.File based and not much different than our VFS implementation other than the VFS being a better abstraction. Yes, they do have the jar compression algorithms available in open source, but it will take a lot of refactoring of truzip to get where we want.

                  • 6. Re: Another problem with jar urls
                    starksm64

                    I'm not sold on truzip so whatever works best is what we will use.

                    • 7. Re: Another problem with jar urls
                      starksm64

                      Are you ready to get going on this? I want to start tracking down the redeploy and sporadic startup issues.

                      • 8. Re: Another problem with jar urls
                        bill.burke

                        Can I start after thanksgiving? Was focusing cleaning up the 25% failures in the EJB3 testsuite.

                        If you say so, I would happily drop and start going on VFS.

                        What is the first thing you want? To have AbstractJarHandlers NOT use "jar:" based URLs?

                        • 9. Re: Another problem with jar urls
                          starksm64

                          The first thing needed is the ability to replace the jdk JarFile with another implementation to be able to better control caching and debugging.