2 Replies Latest reply on Apr 5, 2006 4:58 PM by Scott Stark

    Bootstrapping the Microcontainer/JBoss

    Adrian Brock Master

      I've been thinking about the bootstrap of the Microcontainer
      and how it would relate to different usecases.

      I can't really decide what is the best way to do it, so I want
      some other thoughts on the subject. Apologies in advance
      for the length of this post.

      What we have now
      Currently there is a KernelConfig interface that has methods like

      KernelConfigurator createKernelConfigurator() throws Throwable;

      This allows different implementations to decide how to construct these objects,
      the default being to use system properties
      KernelConfig config = new PropertyKernelConfig(System.getProperties())

      This works pretty well in that you can change just about anything about the implementation. Which is important for both people wanting to use their
      own implementations and providing alternate implementations for bug fixes.

      It also means you can decide not to use System properties and use something else as the source of implementation configuration.

      Where it doesn't work well is wanting to add new features in a unified way.
      e.g. AOP, MBeanServer, MetaDataRepository, Profile Service, etc.

      I see three options, the last one is what I prefer, but it does introduce
      some extra complications.

      1) Leave it as it is and just add extra methods to the Config object
      2) Make a more generic config object like
      Object createPlugin(String name) throws Throwable;

      3) Keep the bootstrap config to a minimum and instead have a
      jboss-bootstrap.xml file that defines what services you want to bootstrap.
      <bean name="AspectManager" .../>
      <bean name="MBeanServer" .../>

      There are a number of disadvantages (or complications) to this approach
      but I don't think they are unsolvable.

      a) A hardwired name for the jboss-bootstrap.xml file will
      likely leak into other scopes that want to initiate their own kernel.

      b) The late construction of some objects means we will need to
      retrofit earlier objects as dependencies are satisifed.

      e.g. When the MBeanServer uses AOP advices it will need the aspect
      manager in place to define the advice stack, but then we need
      to retrofit the AspectManager to expose it via JMX once we have
      the MBeanServer.

      e.g.2. The more subtle but essentially the same problem of applying
      SecurityDomain protection to the SecurityManager service.

      c) With the profile service in place what we really want is to
      bootstrap the profile service only and then let it define these
      services in the profile. e.g. This profile has AOP and JMX

      d) The use of a bootstrap xml file is not very good for being able to
      do something like:
      ./run.sh --features=aop,jmx
      which is effectively also something we want to be able to do
      when bootstrapping the Microcontainer in tests

      So maybe rather having a single jboss-bootstrap.xml
      there would be a pattern that loads jboss-bootstrap-aop.xml
      when the feature is enabled.

      However, with the features separated and standalone
      the issue then becomes making the retrofitting work
      in the case when other features are/aren't enabled.
      e.g. Don't try expose the AspectManager via JMX when there is no
      MBeanServer, but do expose it when the MBeanServer appears later.

        • 1. Re: Bootstrapping the Microcontainer/JBoss
          Adrian Brock Master

          I forget one.

          In some circumstances we want use native features
          rather than starting our own.

          e.g. Inside Tomcat we would use their MBeanServer.

          Problems like this can solved by defining JMX via a sort
          of "Discovery Factory" that decides how to provide the service
          from what is available.

          • 2. Re: Bootstrapping the Microcontainer/JBoss
            Scott Stark Master

            I need to prototype the profile service usecase so I'll explore this. The retrofitting discussion seems to all relate to the relation of beans via aspects and is undefined in terms of when a bean is "finalized". Don't we need a notion of bootstrapping to a point of knowing whether an aop facility exists, and if it does, ordering deployments based on aop dependencies?

            In the case of the profile service driven the bean definitions that affect the server core should be known when the profile is loaded. A hotdeployment service may be defined such that there is still a dynamic component of the profile, but such deployment should not be able to introduce aspects into core server components.