5 Replies Latest reply on Apr 7, 2009 4:16 AM by Andrew Rubinger

    Removing ClassLoading from jboss-bootstrap

    Andrew Rubinger Master

      https://jira.jboss.org/jira/browse/JBBOOT-24

      As it stands, Bootstrap is sensitive to arbitrary JARs on the application CP (and picked up by the extension ClassLoader). This becomes especially apparent when starting up from an Embedded environment, where we may have a full dependency set on the test CP.

      AS currently sidesteps this problem by careful inclusion of classes in the run.jar.

      What I'd like to do is remove setting of the TCCL from jboss-bootstrap entirely, leaving this task up to the client (launcher). Some local tests yield much better results and allow the bootstrap to become adaptable to a wider range of runtime environments.

      Can anyone weigh in on:

      * Removal of NoAnnotationCL - a URLCL which is commented to be used in RMI. Is this still the case?
      * AbstractServerImpl.start() to use the TCCL. Currently it's using 2 different CLs (one for starting the ServerImpl, one for the bootstraps).

      With no objections I'll plug ahead, test, and patch AS to match.

      S,
      ALR

        • 1. Re: Removing ClassLoading from jboss-bootstrap
          Scott Stark Master

           

          "ALRubinger" wrote:

          * Removal of NoAnnotationCL - a URLCL which is commented to be used in RMI. Is this still the case?

          This should no longer be useful as we should be using remoting for transport everywhere now.

          "ALRubinger" wrote:

          * AbstractServerImpl.start() to use the TCCL. Currently it's using 2 different CLs (one for starting the ServerImpl, one for the bootstraps).

          Don't know about that.

          • 2. Re: Removing ClassLoading from jboss-bootstrap
            Adrian Brock Master

             

            "scott.stark@jboss.org" wrote:
            "ALRubinger" wrote:

            * Removal of NoAnnotationCL - a URLCL which is commented to be used in RMI. Is this still the case?

            This should no longer be useful as we should be using remoting for transport everywhere now.


            Other people still use RMI and so do we if we want to talk to old jboss servers.
            We don't want all the junk going across the wire that RMI adds if you use
            a plain URL classloader.

            • 3. Re: Removing ClassLoading from jboss-bootstrap
              Adrian Brock Master

               

              "ALRubinger" wrote:
              https://jira.jboss.org/jira/browse/JBBOOT-24

              As it stands, Bootstrap is sensitive to arbitrary JARs on the application CP (and picked up by the extension ClassLoader). This becomes especially apparent when starting up from an Embedded environment, where we may have a full dependency set on the test CP.

              AS currently sidesteps this problem by careful inclusion of classes in the run.jar.

              What I'd like to do is remove setting of the TCCL from jboss-bootstrap entirely, leaving this task up to the client (launcher). Some local tests yield much better results and allow the bootstrap to become adaptable to a wider range of runtime environments.


              The basic idea is to have a pluggable bootstrap. The bootstrap.start() should run
              under its own classloader as TCL not the classpath otherwise all sort of side effects
              break (e.g. loading property editors, and other dynamic classloading, etc.).

              In JBoss the bootstrap is two stage (actually it is multiple).

              1) To load the bootstrap implementation itself (the mc + profile service)
              2) To load the bootstrap xmls

              As long as the called code doesn't have to worry about setting the TCL itself
              (error prone and it is not likely to know what the correct CL is)
              I don't have a problem.

              • 4. Re: Removing ClassLoading from jboss-bootstrap
                Carlo de Wolf Master

                 

                "adrian@jboss.org" wrote:
                The basic idea is to have a pluggable bootstrap. The bootstrap.start() should run
                under its own classloader as TCL not the classpath otherwise all sort of side effects
                break (e.g. loading property editors, and other dynamic classloading, etc.).

                I still don't see how this can happen?
                The app classloader contains virtually nothing.
                "adrian@jboss.org" wrote:
                In JBoss the bootstrap is two stage (actually it is multiple).

                1) To load the bootstrap implementation itself (the mc + profile service)

                Profile Service isn't in scope yet. We're at rock bottom, stage #1, a bootstrapping framework with which Reloaded can bootstrap Profile Service itself.
                "adrian@jboss.org" wrote:

                2) To load the bootstrap xmls

                As long as the called code doesn't have to worry about setting the TCL itself
                (error prone and it is not likely to know what the correct CL is)
                I don't have a problem.

                I think I'm getting it: Bootstrap should execute the following 'psuedo' descriptor:
                <deployment>
                 <classloader>preboot-cl</classloader>
                 <bean class="org.jboss.bootstrap.MCServerImpl"/>
                 <bean class="org.jboss.bootstrap.BootstrapDeployer"/>
                 <classloader name="preboot-cl">
                 bits and pieces specified by the launcher
                 </classloader>
                </deployment>



                • 5. Re: Removing ClassLoading from jboss-bootstrap
                  Andrew Rubinger Master

                   

                  "adrian@jboss.org" wrote:
                  As long as the called code doesn't have to worry about setting the TCL itself (error prone and it is not likely to know what the correct CL is) I don't have a problem.


                  For this bit, I'd been planning on:

                  * A series of *Launcher* impls to set the appropriate CLs. Clients of these can stay ignorant.
                  * Removing CL entirely from bootstrap.

                  S,
                  ALR