12 Replies Latest reply on Mar 12, 2008 9:43 AM by alesj

    Silent failover on broken jar file

    alesj

      We do this in our VFS code:

       if (file.isFile() && JarUtils.isArchive(file.getName()))
       {
       String name = file.getName();
       try
       {
       return new JarHandler(this, parent, file, file.toURL(), name);
       }
       catch (IOException e)
       {
       log.debug(e.getMessage());
       }
       }
       return createVirtualFileHandler(parent, file, fileURL);
      


      And since we moved over to VFS.getChild returning null, instead of VFS.findChild which heavily complained when it didn't found what we were looking for, a lot of things gets silently suppressed - e.g. trying to find META-INF on a broken jar file == trying to find a META-INF child on a FileHandler, resulting in a silent null being returned. And this is true for all file lookups on this broken jar, meaning even more silent nulls being returned.
      But the problem is that from 'outside' this file looks OK, except for this debug message. :-)

      Should we throw exception fwd or at least do a warn?

        • 1. Re: Silent failover on broken jar file
          starksm64

          What is a broken jar? It does not have to have a META-INF as it could just be a zip. The JarHandler will fail if its an unpacked jar.

          • 2. Re: Silent failover on broken jar file
            alesj

             

            "scott.stark@jboss.org" wrote:
            What is a broken jar? It does not have to have a META-INF as it could just be a zip. The JarHandler will fail if its an unpacked jar.

            That's expected.

            I had some IO problems with my .jar file. Some unexpected zip issues - e.g. corrupted zip. You don't expect this.

            What user expect is that this jar will play nicely or at least get a decent warning/error.
            But you don't.
            It all goes 'smoothly', but at the end nothing is deployed, since nothing can be found.
            And in the flood of debug messages nobody will ever notice that simple debug message, specially since it has no developer added info at the beginning.


            • 3. Re: Silent failover on broken jar file
              starksm64

              Fine, but be specific. What was the condition that was logged at debug level that should have been an exception? Not being able to create a JarHandler can mean its an unpacked jar or a corrupt archive. How do you tell the difference?

              • 4. Re: Silent failover on broken jar file
                alesj

                 

                "scott.stark@jboss.org" wrote:
                Not being able to create a JarHandler can mean its an unpacked jar or a corrupt archive. How do you tell the difference?

                I think we should be able to check for an unpacked jar pretty easily, right?
                And make that part of the code, not even going into trying to create JarHandler, and rely on exception to tell us that it was really an unpacked jar.
                And let the exception be only for corrupted archives, throwing it fwd.


                • 5. Re: Silent failover on broken jar file
                  starksm64

                  No, actually we can't. You would have to have the notion of a compressed directory to do this. This concept does not exist in the VFS api, so there is no distinction between a directory and an archive.

                  • 6. Re: Silent failover on broken jar file
                    alesj

                     

                    "alesj" wrote:
                    "scott.stark@jboss.org" wrote:
                    Not being able to create a JarHandler can mean its an unpacked jar or a corrupt archive. How do you tell the difference?

                    I think we should be able to check for an unpacked jar pretty easily, right?

                    But we already do that:
                     if (file.isFile() && JarUtils.isArchive(file.getName()))
                    




                    • 7. Re: Silent failover on broken jar file
                      starksm64

                      I don't know what file.isFile() api your talking about, VirtualFile or java.io.File. So looking for this statement in the vfs codebase, I find it in FileSystemContext.createVirtualFileHandler. and there it is java.io.File.isFile(). So for that usage, yes, we know whether its an unpacked jar or not. For that IOException, I don't know why we fall back to treating the corrupt jar as a non-structured file.

                      • 8. Re: Silent failover on broken jar file
                        alesj

                         

                        "scott.stark@jboss.org" wrote:
                        I don't know what file.isFile() api your talking about, VirtualFile or java.io.File. So looking for this statement in the vfs codebase, I find it in FileSystemContext.createVirtualFileHandler. and there it is java.io.File.isFile(). So for that usage, yes, we know whether its an unpacked jar or not. For that IOException, I don't know why we fall back to treating the corrupt jar as a non-structured file.

                        Yeah, sorry about that - not being precise enough.
                        That's the code I'm talking about. ;-)
                        Beats me too why we would do that. I did a simple fix, at least providing some more info in that debug msg.
                        But I think we should just fail.

                        • 9. Re: Silent failover on broken jar file

                           

                          "alesj" wrote:
                          We do this in our VFS code:
                           if (file.isFile() && JarUtils.isArchive(file.getName()))
                           {
                           String name = file.getName();
                           try
                           {
                           return new JarHandler(this, parent, file, file.toURL(), name);
                           }
                           catch (IOException e)
                           {
                           log.debug(e.getMessage());
                           }
                           }
                           return createVirtualFileHandler(parent, file, fileURL);
                          


                          And since we moved over to VFS.getChild returning null, instead of VFS.findChild which heavily complained when it didn't found what we were looking for, a lot of things gets silently suppressed - e.g. trying to find META-INF on a broken jar file == trying to find a META-INF child on a FileHandler, resulting in a silent null being returned. And this is true for all file lookups on this broken jar, meaning even more silent nulls being returned.
                          But the problem is that from 'outside' this file looks OK, except for this debug message. :-)

                          Should we throw exception fwd or at least do a warn?


                          How do you tell difference between a broken jar and a plain file that has
                          an extension that is the same as an archive? :-)

                          • 10. Re: Silent failover on broken jar file
                            alesj

                             

                            "adrian@jboss.org" wrote:

                            How do you tell difference between a broken jar and a plain file that has
                            an extension that is the same as an archive? :-)

                            While you can easily rename file, you probably cannot fix it.
                            But how many .jar files did you see that were not actually jars, opposed to broken zips. ;-)

                            • 11. Re: Silent failover on broken jar file

                               

                              "alesj" wrote:

                              While you can easily rename file, you probably cannot fix it.
                              But how many .jar files did you see that were not actually jars, opposed to broken zips. ;-)


                              You mean besides directories being unpacked jars? ;-)

                              I guess we could add an extra check that tries to open the raw stream
                              and see whether it contains the magic PK at the start:
                              http://en.wikipedia.org/wiki/Magic_number_(programming)
                              If it does then throw an IOException about the broken archive.

                              • 12. Re: Silent failover on broken jar file
                                alesj

                                 

                                "adrian@jboss.org" wrote:

                                You mean besides directories being unpacked jars? ;-)

                                We know it's a file.
                                See previous posts in this thread.