9 Replies Latest reply on Jun 1, 2009 3:58 PM by alrubinger

    Classloading vs. VFS

    jesper.pedersen

      I get the following trace:

      Caused by: java.net.MalformedURLException: unknown protocol: vfsfile
       at java.net.URL.<init>(URL.java:574)
       at java.net.URL.<init>(URL.java:464)
       at java.net.URL.<init>(URL.java:413)
       at org.jboss.virtual.plugins.context.file.FileHandler.<init>(FileHandler.java:77)
       at org.jboss.virtual.plugins.context.file.FileHandler.<init>(FileHandler.java:93)
       at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:322)
       at org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:260)
       at org.jboss.virtual.plugins.context.file.FileSystemContext.getRoot(FileSystemContext.java:207)
       at org.jboss.virtual.VFS.getRoot(VFS.java:292)
       at org.jboss.virtual.VFS.createNewRoot(VFS.java:186)
       at org.jboss.virtual.VFS.getRoot(VFS.java:201)
       at org.jboss.classloading.spi.vfs.dependency.VFSClassLoaderPolicyModule.getVirtualFile(VFSClassLoaderPolicyModule.java:196)
       at org.jboss.classloading.spi.vfs.dependency.VFSClassLoaderPolicyModule.determineVFSRoots(VFSClassLoaderPolicyModule.java:170)
       ... 41 more
      


      when I try to install a bean that calls VFS.init().

      This is the first bean installed into the server bootstrap - my Main only setup bootstrap-0.1.2 with a URLCL which contains all the dependencies (VFS 2.2.0.M4).

      If I don't declare a I get a NoClassDefFoundError which points in the direction of bootstrap.

      *But* shouldn't VFS make sure that the protocol handler is installed before doing anything with it ?

        • 1. Re: Classloading vs. VFS
          alrubinger

          This results from parsing a bootstrap.xml with hooks to VFS before VFS itself has been init'd. I've addressed this in jboss-bootstrap-impl-as by a manual hack:

          https://jira.jboss.org/jira/browse/JBBOOT-67
          http://fisheye.jboss.org/changelog/JBossAS/?cs=88598

          So for users of MCServer who need VFS, you've gotta do something similar. But a better solution is for some initvfs.xml to come along early in the bootstrap chain, install an MC Bean which will init VFS, and then all should be good.

          Looks like the NCDFE is blocking you from doing that. Which is another issue alltogether. Due to parent>child delegation and leaking of class references, we've got to be very careful what's on the application CP, URLCL, etc. Note that in Branch_5_x of AS right now we prove that things can work. :)

          S,
          ALR

          • 2. Re: Classloading vs. VFS
            jesper.pedersen

             


            So for users of MCServer who need VFS, you've gotta do something similar. But a better solution is for some initvfs.xml to come along early in the bootstrap chain, install an MC Bean which will init VFS, and then all should be good.

            That is the solution I use currently.


            Looks like the NCDFE is blocking you from doing that. Which is another issue alltogether. Due to parent>child delegation and leaking of class references, we've got to be very careful what's on the application CP, URLCL, etc.

            I only have an AppCL which has my Main and is a parent to the URLCL which has all the JARs. The URLCL is passed to the ServerFactory in bootstrap.

            That is the way the ServerFactory is documented and more importantly the way I want my classloader architecture before the MC kicks in.


            Note that in Branch_5_x of AS right now we prove that things can work. :)

            I see AS usage of bootstrap as a very nice proof-of-concept. However AS shouldn't mandate the way bootstrap should work. There are other projects in the World.

            We should make sure that impl-mc meets most of the requirements for projects using the MC as the foundation. Otherwise each project has to implement an extension to fill in the blanks.

            • 3. Re: Classloading vs. VFS
              alrubinger

               

              "jesper.pedersen" wrote:

              Looks like the NCDFE is blocking you from doing that. Which is another issue alltogether. Due to parent>child delegation and leaking of class references, we've got to be very careful what's on the application CP, URLCL, etc.

              I only have an AppCL which has my Main and is a parent to the URLCL which has all the JARs. The URLCL is passed to the ServerFactory in bootstrap.


              Right, what I'm getting at is the "all the JARs" part. Take a look at how restrictive/careful we've gotta be in AS, for example:

              /**
               * The default list of boot libraries. Does not include
               * the JAXP or JMX impl, users of this class should add the
               * proper libraries.
               * TODO: use vfs to list the root directory
               * http://www.jboss.org/index.html?module=bb&op=viewtopic&t=153175
               *
               * Copied from legacy bootstrap ServerLoader
               * //TODO JBAS-6920
               */
               @Deprecated
               public static final String[] DEFAULT_BOOT_LIBRARY_LIST =
               {
               // Concurrent
               "concurrent.jar",
               // Logging
               "log4j-boot.jar",
               "jboss-logging-spi.jar",
               "jboss-logging-log4j.jar",
               "jboss-logging-jdk.jar",
               "jboss-logmanager.jar",
               "jboss-logbridge.jar",
               // Common jars
               "jboss-common-core.jar",
               "jboss-xml-binding.jar",
               // Bootstrap
               "jboss-bootstrap-spi.jar",
               "jboss-bootstrap-spi-as.jar",
               "jboss-bootstrap-spi-mc.jar",
               "jboss-bootstrap-impl-base.jar",
               "jboss-bootstrap-impl-as.jar",
               "jboss-bootstrap-impl-mc.jar",
               // Microcontainer
               "javassist.jar",
               "jboss-reflect.jar",
               "jboss-mdr.jar",
               "jboss-dependency.jar",
               "jboss-kernel.jar",
               "jboss-metatype.jar",
               "jboss-managed.jar",
               // Fixme ClassLoading
               "jboss-vfs.jar",
               "jboss-classloading-spi.jar",
               "jboss-classloader.jar",
               "jboss-classloading.jar",
               "jboss-classloading-vfs.jar",
               // Fixme aop
               "jboss-aop.jar",
               "jboss-aop-mc-int.jar",
               "trove.jar",};


              That's in Main. Any more/less leads to NCDFE.

              "jesper.pedersen" wrote:
              We should make sure that impl-mc meets most of the requirements for projects using the MC as the foundation. Otherwise each project has to implement an extension to fill in the blanks.


              So I suppose the question on the table is whether MCServer should init VFS automatically. While convenient, the thing there is that this isn't really MCServer's job (because it implies VFS will always be used). Opinions?

              S,
              ALR

              • 4. Re: Classloading vs. VFS
                jesper.pedersen

                Yeah, and do we want to create that hard dependency between the MC and VFS ?

                Another question is if bootstrap/MC should make assumptions about CLs. I think having to define a DEFAULT_BOOT_LIBRARY_LIST is something we should think about.

                • 5. Re: Classloading vs. VFS
                  alrubinger

                   

                  "jesper.pedersen" wrote:
                  Another question is if bootstrap/MC should make assumptions about CLs. I think having to define a DEFAULT_BOOT_LIBRARY_LIST is something we should think about.


                  We don't. :) We boot library list is of the AS Main, not bootstrap. It can be removed from its explicit form if we change the build to only put stuff in $JBOSS_HOME/lib which should be part of the boot CL.

                  S,
                  ALR

                  • 6. Re: Classloading vs. VFS
                    jesper.pedersen

                     


                    We don't. :) We boot library list is of the AS Main, not bootstrap. It can be removed from its explicit form if we change the build to only put stuff in $JBOSS_HOME/lib which should be part of the boot CL.


                    My point is here - why do we have to define a DEFAULT_BOOT_LIBRARY_LIBS in our Main ? Splitting our classloader structure into multiple layers shouldn't be needed.

                    Passing the classloader defined in Main to the bootstrap implementation should be enough.

                    And I'm not talking about the AS; I'm talking about projects that uses the MC as a foundation and bootstrap to get it up and running.

                    • 7. Re: Classloading vs. VFS
                      alrubinger

                       

                      "jesper.pedersen" wrote:
                      My point is here - why do we have to define a DEFAULT_BOOT_LIBRARY_LIBS in our Main ? Splitting our classloader structure into multiple layers shouldn't be needed.

                      Passing the classloader defined in Main to the bootstrap implementation should be enough.


                      You've lost me. All I do in AS Main is pass the CL to the bootstrap impl.

                      ClassLoader newCl = new URLClassLoader(allTheStuffInBootLib);
                      Server server = ServerFactory.createServer(newCl);
                      Thread.currentThread().setContextClassLoader(newCl);
                      server.start();


                      What are you proposing should be done instead?

                      S,
                      ALR

                      • 8. Re: Classloading vs. VFS
                        jesper.pedersen

                        The same - but allTheInBootLib IS all the stuff in lib which is > DEFAULT_BOOT_LIBRARY_LIBS.

                        I only have a single lib/ directory where the entire container is located.

                        • 9. Re: Classloading vs. VFS
                          alrubinger

                          Ran through this a bit today. Came across in the JCA Standalone:

                          Caused by: java.net.MalformedURLException: unknown protocol: vfsfile


                          ...as Jesper's been encountering.

                          It's this logic which fully inits VFS:

                          http://anonsvn.jboss.org/repos/jbossas/projects/bootstrap/trunk/impl-as/src/main/java/org/jboss/bootstrap/impl/as/lifecycle/VfsInitializingLifecycleEventHandler.java

                          Note the installation of the protocol handlers.

                          Let's work through this first, get it committed to SVN, then address the ClassLoading issues. :)

                          S,
                          ALR