cts config startup issue with current vfs trunk

[starksm64]

I'm trying to test a fix for JBVFS-17, and I'm seeing the startup problem Dimitris had mentioned seeing earlier, but I had not:

Caused by: java.lang.Error: Error visiting JarHandler@1535839050[path=derbyTesting.jar context=file:/home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.CR1/server/cts/lib/ real=file:/home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.CR1/server/cts/lib/derbyTesting.jar]
...
Caused by: java.net.MalformedURLException: no !/ in spec
 at java.net.URL.<init>(URL.java:601)
 at java.net.URL.<init>(URL.java:464)
 at java.net.URL.<init>(URL.java:413)
 at java.net.JarURLConnection.parseSpecs(JarURLConnection.java:161)
 at java.net.JarURLConnection.<init>(JarURLConnection.java:144)
 at sun.net.www.protocol.jar.JarURLConnection.<init>(JarURLConnection.java:61)
 at sun.net.www.protocol.jar.Handler.openConnection(Handler.java:24)
 at java.net.URL.openConnection(URL.java:943)
 at org.jboss.virtual.plugins.context.AbstractURLHandler.initCacheLastModified(AbstractURLHandler.java:72)
 ... 54 more
14:28:35,687 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):

*** CONTEXTS IN ERROR: Name -> Error

vfsfile:/home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.CR1/server/cts/conf/jboss-service.xml -> java.net.MalformedURLException: no !/ in spec

The sun jar protocol handler should not be getting called as only vfs* urls should be in use.

[alesj]

The sun jar protocol handler should not be getting called as only vfs* urls should be in use.

This is not the case, see that JarContextFactory also takes all jar* urls, and FileSystemContextFactory takes file.

The weird thing is that this url looks like it's broken from the beginning, since if you follow it from the start -> in JarContextFactory.getVFS, it is never modified, going all the way toAbstractURLHandler.initCacheLastModified.

[starksm64]

Jar urls are being created for the SynthenticDirEntryHandler types of empty directories in
jars. Eventually a nested jar:jar url is being created for a jar in derbyTesting.jar:

jar:jar:file:/home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.CR1/server/cts/lib/derbyTesting.jar!/org/apache/derbyTesting/functionTests/testData/v1/j1v1.jar!/META-INF/

that jar should not be in the lib dir, but we also should handling this correctly.

I also don't think we should be relying on the jdk jar: url handler to deal with the jar contents. It internally relies on JarFile which is not serializable.

[starksm64]

"alesj" wrote:

The sun jar protocol handler should not be getting called as only vfs* urls should be in use.

This is not the case, see that JarContextFactory also takes all jar* urls, and FileSystemContextFactory takes file.

We either need to supply our own jar protocol handler, or change the way JarContextFactory deals with jars.

[starksm64]

Some behavior has changed between 2.0.0.Beta9 and the current vfs trunk however as even after removing the derbyTesting.jar so that the server starts correctly, the test associated with JBCTS-752 now fails to deploy for a similar issue:

Caused by: org.jboss.deployers.spi.DeploymentException: Exception determining structure: AbstractVFSDeployment()
 at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
 at org.jboss.deployers.structure.spi.helpers.AbstractStructuralDeployers.determineStructure(AbstractStructuralDeployers.java:85)
 at org.jboss.deployers.plugins.main.MainDeployerImpl.determineStructure(MainDeployerImpl.java:743)
 at org.jboss.deployers.plugins.main.MainDeployerImpl.addDeployment(MainDeployerImpl.java:280)
 at org.jboss.deployers.plugins.main.MainDeployerImpl.addDeployment(MainDeployerImpl.java:237)
 at org.jboss.deployment.services.DeploymentManagerService.deploy_phase2(DeploymentManagerService.java:408)
 at org.jboss.deployment.services.DeploymentManagerService.deploy(DeploymentManagerService.java:295)
 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 org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
 ... 45 more
Caused by: java.lang.RuntimeException: Error determining structure: BeanMirrorSEI.ear
 at org.jboss.deployment.EARStructure.determineStructure(EARStructure.java:274)
 at org.jboss.deployers.vfs.plugins.structure.StructureDeployerWrapper.determineStructure(StructureDeployerWrapper.java:65)
 at org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl.doDetermineStructure(VFSStructuralDeployersImpl.java:194)
 at org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl.determineStructure(VFSStructuralDeployersImpl.java:218)
 at org.jboss.deployers.structure.spi.helpers.AbstractStructuralDeployers.determineStructure(AbstractStructuralDeployers.java:77)
 ... 55 more
Caused by: org.jboss.deployers.spi.DeploymentException: Error determining structure: BeanMirrorSEI_web.war
 at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
 at org.jboss.deployers.vfs.plugins.structure.explicit.DeclaredStructure.determineStructure(DeclaredStructure.java:87)
 at org.jboss.deployers.vfs.plugins.structure.StructureDeployerWrapper.determineStructure(StructureDeployerWrapper.java:65)
 at org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl.doDetermineStructure(VFSStructuralDeployersImpl.java:194)
 at org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl.determineStructure(VFSStructuralDeployersImpl.java:140)
 at org.jboss.deployment.EARStructure.determineStructure(EARStructure.java:256)
 ... 59 more
Caused by: java.lang.RuntimeException: java.net.MalformedURLException: no !/ in spec
 at org.jboss.virtual.plugins.context.AbstractURLHandler.initCacheLastModified(AbstractURLHandler.java:76)
 at org.jboss.virtual.plugins.context.AbstractURLHandler.<init>(AbstractURLHandler.java:65)
 at org.jboss.virtual.plugins.context.jar.SynthenticDirEntryHandler.<init>(SynthenticDirEntryHandler.java:77)
 at org.jboss.virtual.plugins.context.jar.AbstractStructuredJarHandler.createSynthenticParent(AbstractStructuredJarHandler.java:239)
 at org.jboss.virtual.plugins.context.jar.AbstractStructuredJarHandler.buildParents(AbstractStructuredJarHandler.java:227)
 at org.jboss.virtual.plugins.context.jar.AbstractStructuredJarHandler.initJarFile(AbstractStructuredJarHandler.java:166)
 at org.jboss.virtual.plugins.context.jar.NestedJarFromStream.init(NestedJarFromStream.java:91)
 at org.jboss.virtual.plugins.context.jar.NestedJarFromStream.getChild(NestedJarFromStream.java:108)
 at org.jboss.virtual.plugins.context.jar.NoCopyNestedJarHandler.getChild(NoCopyNestedJarHandler.java:130)
 at org.jboss.virtual.VirtualFile.getChild(VirtualFile.java:407)
 at org.jboss.deployers.vfs.plugins.structure.explicit.DeclaredStructure.determineStructure(DeclaredStructure.java:64)
 ... 63 more

[alesj]

Can you create a test for this issue + possible JIRA (if it doesn't exist yet)?
And I'll have a look over the weekend, or first thing Monday morning.

I remember that derby problem.
But I thought it was a misuse of initCacheLastModified.
Which I still think it is, in the case of nested jars - or do you really get the exact entry when you call url.openConnection.getLastModified?

[starksm64]

Need to get a testcase for this and fix it as this behavior does not exist for 2.0.0.Beta9.
http://jira.jboss.com/jira/browse/JBVFS-18

[alesj]

Caused by: java.lang.RuntimeException: java.net.MalformedURLException: no !/ in spec
 at org.jboss.virtual.plugins.context.AbstractURLHandler.initCacheLastModified(AbstractURLHandler.java:76)
 at org.jboss.virtual.plugins.context.AbstractURLHandler.<init>(AbstractURLHandler.java:65)
 at org.jboss.virtual.plugins.context.jar.SynthenticDirEntryHandler.<init>(SynthenticDirEntryHandler.java:77)

You shouldn't get that, since the initCacheLastModified method is overridden in SynthenticDirEntryHandler.
I thought I got that in the last VFS release.

[starksm64]

I'm working on test cases for both JBVFS-17 and JBVFS-18.

[starksm64]

My vfs workspace is at revision 70283 and I just did a clean rebuild. Still failing, maybe a different trace?

Caused by: java.lang.RuntimeException: java.net.MalformedURLException: no !/ in spec
 at org.jboss.virtual.plugins.context.AbstractURLHandler.initCacheLastModified(AbstractURLHandler.java:76)
 at org.jboss.virtual.plugins.context.AbstractURLHandler.<init>(AbstractURLHandler.java:65)
 at org.jboss.virtual.plugins.context.jar.SynthenticDirEntryHandler.<init>(SynthenticDirEntryHandler.java:77)
 at org.jboss.virtual.plugins.context.jar.AbstractStructuredJarHandler.createSynthenticParent(AbstractStructuredJarHandler.java:239)
 at org.jboss.virtual.plugins.context.jar.AbstractStructuredJarHandler.buildParents(AbstractStructuredJarHandler.java:227)
 at org.jboss.virtual.plugins.context.jar.AbstractStructuredJarHandler.initJarFile(AbstractStructuredJarHandler.java:166)
 at org.jboss.virtual.plugins.context.jar.NestedJarFromStream.init(NestedJarFromStream.java:91)
 at org.jboss.virtual.plugins.context.jar.NestedJarFromStream.getChild(NestedJarFromStream.java:108)
 at org.jboss.virtual.plugins.context.jar.NoCopyNestedJarHandler.getChild(NoCopyNestedJarHandler.java:130)
 at org.jboss.virtual.VirtualFile.getChild(VirtualFile.java:407)
 at org.jboss.deployers.vfs.plugins.structure.explicit.DeclaredStructure.determineStructure(DeclaredStructure.java:64)
 ... 63 more
Caused by: java.net.MalformedURLException: no !/ in spec
 at java.net.URL.<init>(URL.java:601)
 at java.net.URL.<init>(URL.java:464)
 at java.net.URL.<init>(URL.java:413)
 at java.net.JarURLConnection.parseSpecs(JarURLConnection.java:161)
 at java.net.JarURLConnection.<init>(JarURLConnection.java:144)
 at sun.net.www.protocol.jar.JarURLConnection.<init>(JarURLConnection.java:61)
 at sun.net.www.protocol.jar.Handler.openConnection(Handler.java:24)
 at java.net.URL.openConnection(URL.java:943)
 at org.jboss.virtual.plugins.context.AbstractURLHandler.initCacheLastModified(AbstractURLHandler.java:72)
 ... 73 more

[starksm64]

"alesj" wrote:

You shouldn't get that, since the initCacheLastModified method is overridden in SynthenticDirEntryHandler.
I thought I got that in the last VFS release.

It was, but this is the problem of trying to call an overloaded method from within a ctor. the SynthenticDirEntryHandler.initCacheLastModified does not exist at that point, and so is not used.

[alesj]

It was, but this is the problem of trying to call an overloaded method from within a ctor. the SynthenticDirEntryHandler.initCacheLastModified does not exist at that point, and so is not used.

No, that's not how OO works. ;-)
The overloaded method should be used.

Try it out, I did :-), since you did get me confused for a bit.

[alesj]

"alesj" wrote:

No, that's not how OO works. ;-)
The overloaded method should be used.

Though I remembered this from somewhere:
- http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#19124

Unlike C++, the Java programming language does not specify altered rules for method dispatch during the creation of a new class instance. If methods are invoked that are overridden in subclasses in the object being initialized, then these overriding methods are used, even before the new object is completely created.

Did some VM back in the days. :-)

[starksm64]

Hmm, must be an old c++ carry over I had. So why is the trace showing the super method?

[alesj]

So why is the trace showing the super method?

No idea.

Can you push in the tests and I'll see what's the deal on my machine.