9 Replies Latest reply on Sep 20, 2006 11:47 AM by adrian.brock

    Deployers and classloading - stumbling block

      We can't actually cutover head to the new deployers yet.
      There is one key piece missing.

      We don't have a mechanism to add deployers that are not
      in the bootstrap classpath.

      e.g. The rar deployer needs classes from jboss-jca.jar
      so it cannot be instantiated from deployer-beans.xml

      What I propose we do is we change the profile service
      to be more like the old JBoss4 mechanism such that
      it does something like:

      Pseudo code:

      // conf/jboss-service.xml - for the classpath
      DeploymentContext ctx = main.addDeployment(profile.getBootstrapURI());
      main.process();
      
      // Run the remainder of the bootstrap under the
      // bootstrap uri's classloader
      Thread current = Thread.currentThread();
      ClassLoader cl = ctx.getClassLoader();
      ClassLoader old = current.getContextClassLoader();
      current.setContextClassLoader(cl);
      try
      {
       main.addDeployments(profile.getDeployerURIs());
       main.process();
      
       // Now do the rest of the deployments
      }
      finally
      {
       current.setContextClasLoader(old);
      }
      


      Where we really want to get to is hot deployment of deployers
      which is an issue that I'll deal with on a different thread.

        • 1. Re: Deployers and classloading - stumbling block
          starksm64

          And why can't this simply be a configuration of the deployer in the deployer-beans.xml that specifies a class loader which references the deployer URI? I do not see a need for deployers to be hot deployable as leads to bootstrap problems that are not worth the complexity in my view.

          • 2. Re: Deployers and classloading - stumbling block

            That's fine as long as the deployers are playing by the rules
            and are self-contained or semi-self-contained (only reference
            other deployers metadata).

            If they reference the runtime then you are going to leak
            everything into the bootstrap classloaders.
            Once one gets in there, the rest will follow like dominos.

            The ideal should be to have two packages:
            1) That is the deployer and its metadata, e.g. the WebDeployer
            2) That is the runtime implementation e.g. web deployment and server

            i.e. The deployer parses the metadata and creates a
            ServiceMetaData or BeanMetaData with only string references
            to the runtime classes

            In practice, our implementations are a long way from this currently.

            Having something that is closer to JBoss4 as an incremental step
            is probably going to help us get things done faster?

            I think some form of hotdeployment of deployers is going to
            be done at some stage anyway.
            e.g. to support people playing with profiles where the results
            are more dynamic than a full reboot. :-)

            • 3. Re: Deployers and classloading - stumbling block

               

              "adrian@jboss.org" wrote:

              Having something that is closer to JBoss4 as an incremental step
              is probably going to help us get things done faster?


              It's certainly going to get us to a working server faster
              than waiting for all deployers to meet the ideal.

              • 4. Re: Deployers and classloading - stumbling block
                starksm64

                But what really needs to be hotdeployable is the deployment component, not the deployers. We do need to refactor the deployers to support this. Whether or not a deployer supports hot deployment is a function of its current implementation state.

                The only problem I have with statically defining deployers in the kernel bootstrap descriptor is not being able to refresh deployers. I view this as an issue with bootstrap class loader capabilities.

                The main issue is we need to get the deployer changes in trunk to get jboss5 moving, and the current suggestion to support full hotdeployment of deployers is a big wrench in this effort.

                • 5. Re: Deployers and classloading - stumbling block

                   

                  "scott.stark@jboss.org" wrote:

                  The main issue is we need to get the deployer changes in trunk to get jboss5 moving, and the current suggestion to support full hotdeployment of deployers is a big wrench in this effort.


                  I never suggested full hotdeployment was the solution we should
                  implement now.

                  My suggestion was an intermediate stage between the bootstrap
                  and the deployment where the deployers are added once the
                  server/lib/*.jars classloader is constructed.


                  Where we really want to get to is hot deployment of deployers
                  which is an issue that I'll deal with on a different thread.


                  • 6. Re: Deployers and classloading - stumbling block
                    starksm64

                     

                    "adrian@jboss.org" wrote:

                    I never suggested full hotdeployment was the solution we should
                    implement now.

                    My suggestion was an intermediate stage between the bootstrap
                    and the deployment where the deployers are added once the
                    server/lib/*.jars classloader is constructed.

                    And breaking up the current bootstrap to support this is fine. I was not clear on the timeframe of the subsequent "where we want to get to..." line. We still need to restore a contract for the admin aspect of a deployment as well.

                    • 7. Re: Deployers and classloading - stumbling block

                      I've implemented this by splitting it up into three sections:

                      * bootstrap - conf/jboss-service.xml
                      * deployers - server/config/deployers
                      * deployments - server/config/deploy

                      To prove it works, I've also got hacky but working versions
                      of the RARDeployer and ConnectionFactory deployer in JCA.

                      So we now have datasources and (as a consequence) jbossmq working.

                      The biggest hack is deciding what should be the thread context
                      classloader for the bootstrap (like the old server loader did).

                      For now, I'm using the "first" bootstrap deployment's classloader
                      which is ok in this case because there is only one.

                      Of course when the deployers have their own classloaders
                      this will be a none issue.

                      • 8. Re: Deployers and classloading - stumbling block
                        starksm64

                        Ok, I have seen the current changes. What I am currently working on is validating scoped service deployments as this is needed for jboss messasging.

                        • 9. Re: Deployers and classloading - stumbling block

                          That should already work, it is also used by the console manager:

                          2006-09-20 13:50:10,704 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@f800db, cl=org.jboss.mx.loading.UnifiedClassLoader3@5364{ url=null ,addedOrder=0}
                          2006-09-20 13:50:10,753 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@f800db, cl=org.jboss.mx.loading.UnifiedClassLoader3@19b2faf{ url=file:/home/ejort/mc-vdf-work/build/output/jboss-5.0.0.Beta/server/default/deploy/management/console-mgr.sar/ ,addedOrder=0}
                          2006-09-20 13:50:10,770 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@f800db, cl=org.jboss.mx.loading.UnifiedClassLoader3@19b2faf{ url=file:/home/ejort/mc-vdf-work/build/output/jboss-5.0.0.Beta/server/default/deploy/management/console-mgr.sar/ ,addedOrder=0}