-
1. Re: AbstractDeploymentUnit.getMetaDataFiles()
kabirkhan Oct 5, 2006 1:08 PM (in response to 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
-
2. Re: AbstractDeploymentUnit.getMetaDataFiles()
starksm64 Oct 5, 2006 1:49 PM (in response to kabirkhan)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()
kabirkhan Oct 5, 2006 6:26 PM (in response to 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
-
4. Re: AbstractDeploymentUnit.getMetaDataFiles()
kabirkhan Oct 5, 2006 7:22 PM (in response to 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 -
5. Re: AbstractDeploymentUnit.getMetaDataFiles()
starksm64 Oct 6, 2006 1:11 AM (in response to kabirkhan)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()
starksm64 Oct 7, 2006 8:55 AM (in response to kabirkhan)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()
starksm64 Oct 13, 2006 1:35 AM (in response to kabirkhan)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 Oct 13, 2006 8:37 AM (in response to kabirkhan)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 Oct 13, 2006 9:34 AM (in response to kabirkhan)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()
starksm64 Oct 13, 2006 1:11 PM (in response to kabirkhan)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()
starksm64 Oct 18, 2006 6:28 PM (in response to kabirkhan)"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()
starksm64 Oct 19, 2006 1:48 AM (in response to kabirkhan)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()
starksm64 Oct 19, 2006 2:29 AM (in response to kabirkhan)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 Oct 19, 2006 2:20 PM (in response to kabirkhan)"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