AbstractDeploymentUnit.getMetaDataFiles() "broken" for archi

[kabirkhan]

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?

[kabirkhan]

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

[starksm64]

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?

[kabirkhan]

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

[kabirkhan]

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

[starksm64]

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.

[starksm64]

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

[starksm64]

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.

[bill.burke]

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?

[adrian.brock]

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.

[starksm64]

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.

[starksm64]

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.

[starksm64]

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.

[starksm64]

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.

[bill.burke]

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