2 Replies Latest reply on Mar 10, 2005 6:28 PM by Les Hazlewood

    KernelControllerContext vs. KernelRegistryEntry

    Les Hazlewood Newbie

      Hi Adrian,

      I've checked in all my initial BeanContainer interfaces/implementations and unit tests in to jboss-pojo (system). I've also modified the Kernel stuff to remove the KernelManager and related dependencies.

      I have a question though.

      I have an interface called MutableBeanContainer, which allows one to programatically add a pojo to the kernel.

      Currently, I'm just wrapping the pojo up in a KernelRegistryEntry and putting that entry into the KernelRegistry.

      Is this the correct way to put a user-instantiated bean into the Kernel?

      Or am I supposed to use the KernelController and create a KernelControllerContext to wrap the pojo? If so, do I need to construct a BeanMetaData instance from the user-supplied pojo to use during the construction of a KernelControllerContext?

      Thanks,

      Les

        • 1. Re: KernelControllerContext vs. KernelRegistryEntry
          Adrian Brock Master

          I don't think I like the idea of a bean going directly into the registry.
          Although it is certainly possible to implement it that way with the new
          container, you lose some features.

          (This is one of the problems with the current JMX micro kernel where MBeans
          that do not go through the ServiceController cannot take part in the service lifecyle/dependencies).

          With the new container, the beans can take part in dependency injection
          on other objects, but there is nothing to say that that bean's dependencies
          can be satisifed in a hot deployment environment.

          In general it bypasses the controller's ability to control lifecycle.

          Such a feature is more of a user requirement. Where they don't care about
          dependency ordering and are happy to get runtime exceptions (NullPointerException?)
          when dependencies are not satisfied, instead of deploying beans and
          the controller stopping them even getting exposed/run if there is problem.

          A better approach is to use something like the GenericBeanFactory I just committed.
          i.e. you inject a factory that can control object instantiation rules.

          Generically, it is much better for users to do (a purer IOC?):

          public void setFactory(MyFactory f)
          {
           X x = f.create();
          }
          
          <bean class="MyClass">
          <property name="factory"><depends name="MyFactory"/></property>
          etc.
          <bean class="GenericBeanFactory" name="MyFactory">
          <factory and bean config goes here/>
          etc.
          

          than a locator style pattern, especially if the beans are
          going straight into the registry instead of AppConfig being
          constructed through dependency injection for each of its parts
          public void setAppConfig(AppConfig appConfig)
          {
           X x = (X) appConfig.getBean("SomeNameForX");
          }
          


          • 2. Re: KernelControllerContext vs. KernelRegistryEntry
            Les Hazlewood Newbie

            I agree with you that it is better to define beans in xml or use annotations so IoC/lifecycle management can occur. I'm just providing a basic feature that is often pretty useful.

            For example, maybe an object can only be created programmatically after the container starts up (e.g. because the object is constructed w/ user input). But other components may need that actual instance after its been created.

            So instead of using static memory, its better to put it in the bean container so that other container aware objects can retrieve it when they need it (or if they implement event callbacks, they can be notified when the object gets put in the container and acquire it at that moment - even better).

            Even though this won't be used often, it is a really convenient feature to have in your back pocket :)

            Les