1 2 Previous Next 19 Replies Latest reply on Oct 20, 2006 6:22 PM by Bill Burke

    AbstractDeploymentUnit.getMetaDataFiles() "broken" for archi

    Kabir Khan Master

      Whenever loading up from an unpacked archive AbstractDeploymentUnit.getMetaDataFiles() finds the metadata files in question, but when the archive is not unpacked an empty list is returned.

      Is this a known problem/not implemented yet?

        • 1. Re: AbstractDeploymentUnit.getMetaDataFiles()
          Kabir Khan Master

          JarEntryHandler.getChildren() doesn't really look like it has been implemented, it always returns an empty list - unlike FileHandler.getChildren() which actually does something

          • 2. Re: AbstractDeploymentUnit.getMetaDataFiles()
            Scott Stark Master

            A JarEntryHandler cannot represent a filesystem directory. An unpacked archive should be handled by the file context implementation rather than the jar context implementation. Something must be getting confused. Can you update one of the org.jboss.test.virtual.test.* tests in the mc container project to illustrate the problem?

            • 3. Re: AbstractDeploymentUnit.getMetaDataFiles()
              Kabir Khan Master

              I meant that for a packed archive, AbstractDeploymentUnit.getMetaDataFiles() ends up in JarEntryHandler.getChildren(), which returns an empty list. I will show this with a test

              • 4. Re: AbstractDeploymentUnit.getMetaDataFiles()
                Kabir Khan Master

                I've added some tests to FileVFSUnitTestCase:
                -testGetMetaDataUnpackedJar()
                -testGetMetaDataPackedJar()

                These use the same code to access the children as where it ends up in AbstractDeploymentContext.getMetaDataFiles(). The unpacked one works, the packed one fails, i.e. returns an empty list

                • 5. Re: AbstractDeploymentUnit.getMetaDataFiles()
                  Scott Stark Master

                  Ok, I see. Yes, the JarEntryHandler.getChildren is inconsistent with the testcase usage. There is no proper notion of a directory in a jar in terms of java.util.jar.* providing a parent/child api, so either the entries associated with a jar directory that share the same prefix will need to be added, or we will have to implement a special List that lazily traverses the jar entries and only returns those that have the directory entry prefix. The latter is probably the easiest way to do this.

                  • 6. Re: AbstractDeploymentUnit.getMetaDataFiles()
                    Scott Stark Master

                    I committed an initial implementation of the getChildren and checked in as the current snapshot version. This is passing the unit test.

                    • 7. Re: AbstractDeploymentUnit.getMetaDataFiles()
                      Scott Stark Master

                      I found a problem with the lazy getChildren implementation. It produces incorrect relative path names on the resulting directory entries. The following two tests are failing because of this:

                      JarVirtualFileHandlerTest.testSubSubChildPathName
                      FileVFSUnitTestCase.testClassScan

                      The directory entry children are going to have to be linked with their parent entry when the jar is parsed in the JarHandler.initJarFile to get the paths correct is looks like.

                      • 8. Re: AbstractDeploymentUnit.getMetaDataFiles()
                        Bill Burke Master

                        I also found a problem with URL creation for jars.

                        deploy/foo.jar creates a URL

                        jar:file:/.../deploy/foo.jar!/

                        With a URL like this, you cannot do url.openStream() although, for some strange reason, you can do url.openConnection()

                        Do we want to change the URL for jars so that they don't have the foo.jar?

                        • 9. Re: AbstractDeploymentUnit.getMetaDataFiles()
                          Adrian Brock Master

                          There is a FIXME in the VFS to revisit the jar url stuff.

                          For the top level url of the jar, it would make sense to just use
                          the real url, not the jar: url.

                          • 10. Re: AbstractDeploymentUnit.getMetaDataFiles()
                            Scott Stark Master

                            I have always thought jar urls were fundamentally flawed since they never have dealt with nested jars, and mix content with another protocol. Its also not really a protocol issue. I would like jar urls to disappear and whether or not a file was a compressed archive be a detail of the VFS.

                            • 11. Re: AbstractDeploymentUnit.getMetaDataFiles()
                              Scott Stark Master

                               

                              "scott.stark@jboss.org" wrote:
                              I found a problem with the lazy getChildren implementation. It produces incorrect relative path names on the resulting directory entries. The following two tests are failing because of this:

                              JarVirtualFileHandlerTest.testSubSubChildPathName
                              FileVFSUnitTestCase.testClassScan

                              The directory entry children are going to have to be linked with their parent entry when the jar is parsed in the JarHandler.initJarFile to get the paths correct is looks like.


                              This has been rewritten to make the jar handlers proper structural file handlers with the correct parent/child relationships between entries. All of the vfs unit tests are now passing.


                              • 12. Re: AbstractDeploymentUnit.getMetaDataFiles()
                                Scott Stark Master

                                While testing this against jboss-head I ran into some unusual jars that don't have all the directory entries:

                                [starksm@succubus JBossMC]$ jar -tf /home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.Beta/server/default/lib/jpl-util.jar
                                META-INF/MANIFEST.MF
                                org/gjt/lindfors/util/BoundBuffer$1.class
                                org/gjt/lindfors/util/BoundBuffer.class
                                org/gjt/lindfors/util/EventGenerator.class
                                org/gjt/lindfors/util/EventGeneratorSupport$1.class
                                org/gjt/lindfors/util/EventGeneratorSupport.class
                                org/gjt/lindfors/util/Library.class
                                org/gjt/lindfors/util/LocalizationSupport$1.class
                                org/gjt/lindfors/util/LocalizationSupport.class
                                org/gjt/lindfors/util/Pair.class
                                org/gjt/lindfors/util/PluggableVisualizer.class
                                org/gjt/lindfors/util/strategy/VisualizerStrategy.class
                                org/gjt/lindfors/util/StreamReaderThread.class
                                org/gjt/lindfors/util/support/VisualizerSupport.class
                                org/gjt/lindfors/util/Trace.class
                                org/gjt/lindfors/util/TypeSupport.class
                                org/gjt/lindfors/util/Visualizable.class
                                org/
                                org/gjt/
                                org/gjt/lindfors/
                                org/gjt/lindfors/gui/
                                org/gjt/lindfors/gui/AboutDialog$CloseDialogAction.class
                                org/gjt/lindfors/gui/AboutDialog.class
                                


                                a quick workaround is just to add these to the parent jar handler, but I'm not sure if this is going to work with the structured file handler logic. I'm testing this.


                                • 13. Re: AbstractDeploymentUnit.getMetaDataFiles()
                                  Scott Stark Master

                                  This is a problem because some jars are not being recognized because they only have a META-INF/MANIFEST entry (no META-INF dir entry) and are not being added to the deployment classpath because the JarStructure test for a META-INF entry is failing. The jbossws.sar/wsdl4j.jar is another example that causes this NCDFE:

                                  Caused by: java.lang.NoClassDefFoundError: javax/wsdl/WSDLException
                                  at jrockit.reflect.InitialConstructorInvoker.newInstance([Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
                                  at java.lang.reflect.Constructor.newInstance([Ljava.lang.Object;J)Ljava.lang.Object;(Unknown Source)
                                  at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:1242)
                                  at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:286)
                                  at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:3

                                  Looks like some synthentic parent entries will be needed.

                                  • 14. Re: AbstractDeploymentUnit.getMetaDataFiles()
                                    Bill Burke Master

                                     

                                    "scott.stark@jboss.org" wrote:
                                    I have always thought jar urls were fundamentally flawed since they never have dealt with nested jars, and mix content with another protocol. Its also not really a protocol issue. I would like jar urls to disappear and whether or not a file was a compressed archive be a detail of the VFS.


                                    That's great you want to do this, but various SPIs in JavaEE5 require passing valid URLs. I'm running into this problem right now with nested jars within an EAR. PU need to pass in URL of the persistence.xml file but it is fucked up URL:

                                    jar:file:/.../foo.ear!/ejb.jar/META-INF/persistence.xml

                                    URL handler tries to open ejb.jar/META-INF/persistence.xml as a JarEntry within foo.ear (which its not obviously)

                                    Are we going to do:

                                    vfs:file:/.../foo.ear/ejb.jar/META-INF/persistence.xml?

                                    Is this something I can work on please as it is blocking me.

                                    Thanks,

                                    Bill

                                    1 2 Previous Next