8 Replies Latest reply on Jan 21, 2010 4:27 PM by alrubinger

    RELOADED-10: Consuming fine-grained bootstrap definitions

    alrubinger

      https://jira.jboss.org/jira/browse/RELOADED-10

       

      Here we bring up VDF by very simply starting jboss-bootstrap and pointing it to a set of bootstrap XML files which together compose the necessary components. The end-user view is just another configuration of the Bootstrap API:

       

      MCServer server = MCServerFactory.createServer();
      URL home; // Points to a bootstrap home containing the proper XML for VDF only
      server.getConfiguration().bootstrapHome(home);
      server.start();
      MainDeployer deployer = server.getKernel().getControlelr().getInstalledContext("MainDeployer");
      
      

       

      What we're aiming to do is deliver a component which easily provides the profile definition only.  From there a consuming project may pick and choose the set of bootstrap XMLs it'd like to define the server.

       

      The current API allows you to point to one entry "bootstrapUrl" which in turn references other relative URLs (which, in the MC case, are "urn:jboss:bean-deployer:2.0" descriptors).  Let's take the case of Embedded EJB3:

       

      * I want to reuse the same lifecycle APIs available elsewhere (currently jboss-bootstrap)

      * I want to define my own bootstrap profile

      * In that profile, I want to reuse finer-grained bootstrap elements so I'm not re-inventing the wheel

       

      So I'm considering some changes to jboss-bootstrap.

       

      We should no longer accept "bootstrapHome" and "bootstrapUrl" parameters, but instead allow the user to pass in a Set of bootstraps either to come from:

       

      1) A URL

      2) Raw Bytes / String

      3) File

      4) ClassLoader Resource

       

      Giving the user control over the Set allows him/her to switch order and add fine-grained stuff (coming from components like the prototype in RELOADED-10) easily.

       

      From here these simply get passed along to the BasicXMLDeployer/KernelDeployer.

       

      To keep things backwards-compatible (and hidden) from AS, we can move the existing "jboss-bootstrap-api" mechanism of defining bootstraps into the "jboss-bootstrap-api-as" layer, and switch out the impl such that the user won't know anything's changed.

       

      S,

      ALR

        • 1. Re: RELOADED-10: Consuming fine-grained bootstrap definitions
          jaikiran

          ALRubinger wrote:

           


          The current API allows you to point to one entry "bootstrapUrl" which in turn references other relative URLs (which, in the MC case, are "urn:jboss:bean-deployer:2.0" descriptors).

          ....

           

          We should no longer accept "bootstrapHome" and "bootstrapUrl" parameters, but instead allow the user to pass in a Set of bootstraps

          If i  understand this right, instead of passing the URL/home of the file containing the relative URLs, the API would now expect a Set of URLs which point to the individual xmls which form the bootstrap? For example a set of URLs pointing to classloader.xml (which sets up classloading), vdf.xml (which sets up deployer framework).

          • 2. Re: RELOADED-10: Consuming fine-grained bootstrap definitions
            alrubinger

            jaikiran wrote:

            If i  understand this right, instead of passing the URL/home of the file containing the relative URLs, the API would now expect a Set of URLs which point to the individual xmls which form the bootstrap? For example a set of URLs pointing to classloader.xml (which sets up classloading), vdf.xml (which sets up deployer framework).

            More like a Set of Bootstrap types, which can come in from a File, URL, ClassLoader resource, String, anything etc.  At the end of the chain this just goes into a KernelDeployer, so anything that can be represented as a bunch of bytes with a name works.

             

            S,

            ALR

            • 3. Re: RELOADED-10: Consuming fine-grained bootstrap definitions
              brian.stansberry
              You mention ordering being important (which it is) so should this be a List not a Set?
              • 4. Re: RELOADED-10: Consuming fine-grained bootstrap definitions
                alrubinger

                bstansberry@jboss.com wrote:

                 

                You mention ordering being important (which it is) so should this be a List not a Set?

                Yes, Carlo called me on it earlier.  java.util.List.

                 

                I mention "Set" only in the context of "don't deploy the same component twice".  The API won't support notion of equality for components defined in a bootstrap though, so that responsibility lies with the caller.

                 

                S,

                ALR

                • 5. Re: RELOADED-10: Consuming fine-grained bootstrap definitions
                  alrubinger

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

                   

                  Do we want AS upgraded in time for M2?  I don't see any pressing reason why this would be required now.

                   

                  S,

                  ALR

                  • 6. Re: RELOADED-10: Consuming fine-grained bootstrap definitions
                    alrubinger

                    I have Reloaded now packaging fine-grained "Bootstrap Descriptor" XML bits, and exposing the contracted names via an interface "VdfBootstrapDescriptorNames".  Consuming projects can assemble the runtime like:

                     

                     

                    // Create a server
                    final MCServer mcServer = MCServerFactory.createServer();
                    
                    // Add the required bootstrap descriptors
                    final List<BootstrapDescriptor> descriptors = mcServer.getConfiguration().getBootstrapDescriptors();
                    descriptors.add(new ClassLoaderResourceBootstrapDescriptor(VdfBootstrapDescriptorNames.RESOURCE_NAME_VDF));
                    descriptors
                              .add(new ClassLoaderResourceBootstrapDescriptor(VdfBootstrapDescriptorNames.RESOURCE_NAME_CLASSLOADING));
                    
                    mcServer.start();  // VDF / MainDeployer will now be available
                    

                     

                    S,

                    ALR

                    • 7. Re: RELOADED-10: Consuming fine-grained bootstrap definitions
                      brian.stansberry

                      ALRubinger wrote:

                       

                      Do we want AS upgraded in time for M2?  I don't see any pressing reason why this would be required now.

                       

                      No, unless 1) someone can provide a really really strong reason for it and 2) it can be done this week including fixing the bizarro testsuite regressions that pop up whenever anything gets changed.

                      • 8. Re: RELOADED-10: Consuming fine-grained bootstrap definitions
                        alrubinger

                        Just a note that I've made things a bit more friendly:

                         

                        final List<BootstrapDescriptor> descriptors = mcServer.getConfiguration().getBootstrapDescriptors();
                        descriptors.add(ReloadedDescriptors.getClassLoadingDescriptor());
                        descriptors.add(ReloadedDescriptors.getVdfDescriptor());

                         

                        S,

                        ALR