1 2 Previous Next 16 Replies Latest reply on Mar 4, 2008 11:54 AM by Scott Stark

    cts config startup issue with current vfs trunk

    Scott Stark Master

      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.

        • 1. Re: cts config startup issue with current vfs trunk
          Ales Justin Master

           

          "scott.stark@jboss.org" 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.

          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.

          • 2. Re: cts config startup issue with current vfs trunk
            Scott Stark Master

            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.

            • 3. Re: cts config startup issue with current vfs trunk
              Scott Stark Master

               

              "alesj" wrote:
              "scott.stark@jboss.org" 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.


              • 4. Re: cts config startup issue with current vfs trunk
                Scott Stark Master

                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
                



                • 5. Re: cts config startup issue with current vfs trunk
                  Ales Justin Master

                  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?

                  • 6. Re: cts config startup issue with current vfs trunk
                    Scott Stark Master

                    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

                    • 7. Re: cts config startup issue with current vfs trunk
                      Ales Justin Master

                       

                      "scott.stark@jboss.org" wrote:

                      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.

                      • 8. Re: cts config startup issue with current vfs trunk
                        Scott Stark Master

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

                        • 9. Re: cts config startup issue with current vfs trunk
                          Scott Stark Master

                          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
                          



                          • 10. Re: cts config startup issue with current vfs trunk
                            Scott Stark Master

                             

                            "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.


                            • 11. Re: cts config startup issue with current vfs trunk
                              Ales Justin Master

                               

                              "scott.stark@jboss.org" wrote:

                              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.


                              • 12. Re: cts config startup issue with current vfs trunk
                                Ales Justin Master

                                 

                                "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. :-)

                                • 13. Re: cts config startup issue with current vfs trunk
                                  Scott Stark Master

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

                                  • 14. Re: cts config startup issue with current vfs trunk
                                    Ales Justin Master

                                     

                                    "scott.stark@jboss.org" wrote:
                                    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.

                                    1 2 Previous Next