4 Replies Latest reply on Mar 30, 2009 5:13 PM by Jesper Pedersen

    Explicit listing of Boot Classpath

    Andrew Rubinger Master

      Came across this while addressing: https://jira.jboss.org/jira/browse/JBAS-6698

      I was under the impression that anything in $JBOSS_HOME/lib should be on the boot CP. As such the ServerLoader in jboss-bootstrap constructs the CP by iterating through the contents of "lib" and adding each JAR.

      ServerLoader in AS/main instead has an explicit default boot library list:

      /**
       * 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
       */
       public static final String[] DEFAULT_BOOT_LIBRARY_LIST = {
       // 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",
       "jaxb-api.jar",
       // Bootstrap
       "jboss-bootstrap.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",
       };


      Using the jboss-bootstrap approach leads to:

      Failed to boot JBoss:
      java.lang.RuntimeException: Error creating annotation for @org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss.system:service=ServiceBindingManager", exposedInterface=org.jboss.services.binding.ServiceBindingManagerMBean.class, registerDirectly=true)
       at org.jboss.beans.metadata.plugins.AbstractAnnotationMetaData.getAnnotationInstance(AbstractAnnotationMetaData.java:128)
       at org.jboss.beans.metadata.plugins.AbstractAnnotationMetaData.getAnnotationInstance(AbstractAnnotationMetaData.java:100)
       at org.jboss.deployers.plugins.managed.BeanMetaDataICF.getManagedObjectClass(BeanMetaDataICF.java:119)
       at org.jboss.deployers.plugins.managed.BeanMetaDataICF.getManagedObjectClass(BeanMetaDataICF.java:50)
       at org.jboss.managed.plugins.factory.AbstractManagedObjectFactory.initManagedObject(AbstractManagedObjectFactory.java:342)
       at org.jboss.managed.api.factory.ManagedObjectFactory.initManagedObject(ManagedObjectFactory.java:77)
       at org.jboss.system.server.profileservice.ProfileServiceBootstrap.initBootstrapMDs(ProfileServiceBootstrap.java:439)
       at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:242)
       at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
       at org.jboss.Main.boot(Main.java:216)
       at org.jboss.Main$1.run(Main.java:546)
       at java.lang.Thread.run(Thread.java:595)
      Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: org.jboss.services.binding.ServiceBindingManagerMBean
       at org.jboss.annotation.factory.AnnotationCreator.visit(AnnotationCreator.java:241)
       at org.jboss.annotation.factory.ast.ASTIdentifier.jjtAccept(ASTIdentifier.java:37)
       at org.jboss.annotation.factory.AnnotationCreator.visit(AnnotationCreator.java:116)
       at org.jboss.annotation.factory.ast.ASTMemberValuePair.jjtAccept(ASTMemberValuePair.java:37)
       at org.jboss.annotation.factory.AnnotationCreator.createAnnotation(AnnotationCreator.java:403)
       at org.jboss.annotation.factory.AnnotationCreator.createAnnotation(AnnotationCreator.java:449)
       at org.jboss.beans.metadata.plugins.AbstractAnnotationMetaData.getAnnotationInstance(AbstractAnnotationMetaData.java:119)
       ... 11 more
      Caused by: java.lang.ClassNotFoundException: org.jboss.services.binding.ServiceBindingManagerMBean
       at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
       at java.security.AccessController.doPrivileged(Native Method)
       at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
       at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
       at java.lang.Class.forName0(Native Method)
       at java.lang.Class.forName(Class.java:242)
       at org.jboss.annotation.factory.AnnotationCreator.visit(AnnotationCreator.java:175)
       ... 17 more


      Probably the real issue is not a CNFE a this point, but the loading of some extra JAR is triggering some scanning/deployment prematurely.

      What's the correct approach - to stick with this explicit list, or put only stuff in $JBOSS_HOME/lib which can be used at boot?

      S,
      ALR

        • 1. Re: Explicit listing of Boot Classpath
          Andrew Rubinger Master

           

          "ALRubinger" wrote:
          Probably the real issue is not a CNFE a this point, but the loading of some extra JAR is triggering some scanning/deployment prematurely.


          If this is the case, might be good to go to a "scan lib directory, but apply some explicit excludes" logic as a more maintainable interim solution.

          S,
          ALR

          • 2. Re: Explicit listing of Boot Classpath
            Carlo de Wolf Master

            JBoss Bootstrap should only have these dependencies:

            [INFO] [dependency:tree]
            [INFO] org.jboss.bootstrap:jboss-bootstrap:jar:1.0.0-SNAPSHOT
            [INFO] +- org.jboss.logging:jboss-logging-log4j:jar:2.0.5.GA:test
            [INFO] | \- apache-log4j:log4j:jar:1.2.14:test
            [INFO] +- org.jboss.man:jboss-managed:jar:2.0.0.GA:compile
            [INFO] | +- org.jboss.man:jboss-metatype:jar:2.0.0.GA:compile
            [INFO] | | +- org.jboss:jboss-reflect:jar:2.0.1.GA:compile
            [INFO] | | +- org.jboss.logging:jboss-logging-spi:jar:2.0.5.GA:compile
            [INFO] | | \- org.jboss:jboss-common-core:jar:2.2.9.GA:compile
            [INFO] | +- org.jboss:jboss-mdr:jar:2.0.1.GA:compile
            [INFO] | \- sun-jaxb:jaxb-api:jar:2.1.4:compile
            [INFO] +- org.jboss.microcontainer:jboss-kernel:jar:2.0.4.GA:compile
            [INFO] | +- org.jboss.microcontainer:jboss-dependency:jar:2.0.4.GA:compile
            [INFO] | \- org.jboss:jbossxb:jar:2.0.0.GA:compile
            [INFO] | +- apache-xerces:xml-apis:jar:2.9.1:compile
            [INFO] | +- apache-xerces:xercesImpl:jar:2.9.1:compile
            [INFO] | +- wutka-dtdparser:dtdparser121:jar:1.2.1:compile
            [INFO] | \- javax.activation:activation:jar:1.1.1:compile
            [INFO] \- junit:junit:jar:4.5:test

            Maybe we can get rid of jboss-managed, I don't know.

            It's the job of the classloader facilities to come up with something that makes service binding manager deployable.

            • 3. Re: Explicit listing of Boot Classpath
              Andrew Rubinger Master

               

              "wolfc" wrote:
              It's the job of the classloader facilities to come up with something that makes service binding manager deployable.


              Yes. To be more clear on the target question:

              What's the correct approach - to stick with this explicit list, or put only stuff in $JBOSS_HOME/lib which can be used at boot?

              If it's the latter, I'll add lib scanning w/ a temporary excludes mechanism to jboss-bootstrap.

              S,
              ALR

              • 4. Re: Explicit listing of Boot Classpath
                Jesper Pedersen Master

                The idea of JBBOOT is to create custom configurations which may/may not contain the list of JAR files in its HOME_URL/lib directory.

                So I'll vote for the VFS scanning solution :)