JBVFS 2.0.0.Beta10/2.0.0.CR1 releases

[starksm64]

We need a vfs release with bug fixes for current jbossas issues, but there are too many open issues for the current 2.0.0.Beta10, so we need another release 2.0.0.Beta10 can be done prior to jbossas5.0.0.CR1.

These release needs to be a CR1 release as well. I have created 2.0.0.CR1 2.0.0.GA, and 2.0.1.Beta1 release targets. Most of the current 2.0.0.Beta10 issues will be moved to 2.0.0.CR1. These need to be further paired down to what will realistically get done for 2.0.0.GA

[starksm64]

There are a few tests that failing based on the os in use. On winxp I see:

Running org.jboss.test.virtual.test.FileVFSUnitTestCase
Tests run: 42, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 1.89 sec <<< FAILURE!
Running org.jboss.test.virtual.test.JARCacheUnitTestCase
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.125 sec <<< FAILURE!
Running org.jboss.test.virtual.test.URLExistsUnitTestCase
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.078 sec <<< FAILURE!

3 of these are due to not being able to delete a tmp file.

On osx I see:

Running org.jboss.test.virtual.test.FileVFSUnitTestCase
Tests run: 42, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.89 sec <<< FAILURE!
Running org.jboss.test.virtual.test.JARCacheUnitTestCase
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.125 sec <<< FAILURE!

There is a common FileVFSUnitTestCase failure due to a class file not being copied from the resources dir. This was commented out with a FIXME, so I uncommented it as it works in eclipse. Some addition test setup will be required for surefire, or a reworking of the test resources.

The JARCacheUnitTestCase failure is due to the JBVFS-2 issue. On winxp this test fails earlier with another file delete failure.

[alesj]

I can to the intermediate release.
I'll try to fix some my JIRA issues before doing that + getting mstruk to contribute/commit his changes.

btw: did you try your JBVFS-17 fix with level 2+ nested jar?

[starksm64]

org.jboss.test.virtual.test.NoCopyJarsUnitTestCase.testInnerJarFilesOnlyFileSerialization showed the problem with serialization of an outer.jar/jar1-filesonly.jar type of VirtualFile. This works after the fix where accessing a file in jar1-filesonly.jar after deserialization is validated. Is that a level2 jar to you?

[alesj]

Is that a level2 jar to you?

No.
See the (failing) test that I just added:
- NoCopyJarsUnitTestCase.testLevelZips

[starksm64]

I fixed the writing of the more deeply nested jars, but this fails to deserialize because the underlying sun.net.www.protocol.jar.JarURLConnection does not understand nested jars:

java.io.FileNotFoundException: JAR entry level2.zip!/level3.zip not found in C:\home\svn\JBossMC\VFS\trunk\target\classes\vfs\test\level1.zip
 at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:114)
 at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:69)
 at org.jboss.virtual.plugins.context.jar.AbstractJarHandler.readObject(AbstractJarHandler.java:213)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
 at org.jboss.test.AbstractTestCase.deserialize(AbstractTestCase.java:352)
 at org.jboss.test.AbstractTestCase.serializeDeserialize(AbstractTestCase.java:367)
 at org.jboss.test.virtual.test.NoCopyJarsUnitTestCase.testLevelZips(NoCopyJarsUnitTestCase.java:179)

To properly serialize jar files we have to provide our own jar: protocol implementation, or not rely on the jar file JarURLConnection.

[slaboure]

If needed, there seems to be an ASL2 implementation here:
http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/org/apache/harmony/luni/internal/net/www/protocol/jar/JarURLConnection.java?revision=542426&view=markup

[starksm64]

That still relies on a JarFile/ZipFile, which has native methods and is not serializable. I don't know why this has not been updated to a pure java implementation by now. The harmony impl is no different:
http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/archive/src/main/java/java/util/zip/ZipFile.java?revision=628014&view=markup

There are java impls of zip/jar archives out there, I looked at a couple when starting the vfs work but they were not what I was looking for. Everything can be done off of the JarInputStream/ZipInputStream, but its not the most efficient.