4 Replies Latest reply on Jul 10, 2006 8:49 AM by Bill Burke

    using MC beanfactory for configuration

    Bill Burke Master

      We need to finally think about how we are going to replace standardjboss.xml from the old EJB 2.1 container. One thought that comes to mind is that we define Microcontainer BeanFactories in XML for each container type. We want this standardjboss.xml replacement to be as generic as possible.

      We do already have the notion of an AOP AspectDomain, but this is really not good enough as we will want to inject things into the EJBContainer like the Timerservice that is being used, the MBeanServer, TM, etc... We also need the ability to define default ActivationSpecs and things like that. With the AspectDomain, you *can* overload/define new annotations in XML, but we need the ability to define generically other configuration items.

      There has been some work in MC land with JBoss AOP integration. So I'm thinking that one beanfactory definition in XML would also include the aspect domain definition for the template for that type of EJB Container.

      So, we have to think of how this all wires together. We may need two different beanfactories. One for creating EJBContainers, the other for instantiating EJB instances themselves. The user may want to define their own injections/configuration for EJB instances. For the EJB instances, we may want to extend the jboss.xml schema to allow the extension and definition of a beanfactory for the EJB.

      Hope this makes sense, let's think and discuss more.

        • 1. Re: using MC beanfactory for configuration
          Scott Stark Master

          As described, two bean factories with extension points in a jboss_5 xml schema makes sense. Shouldn't there be a general container framework in the unified aop/mc project that can be used of the basis of any context requiring a container with aspects and instance control?

          • 2. Re: using MC beanfactory for configuration
            Carlo de Wolf Master

            If I see it correctly the micro kernel currently has no knowledge of aspects, it does lean and mean injection. While AOP does the aspects.

            So why not:

            <bean name="StatelessBeanContainer" class="...">
             <propery name="timerService"><factory bean="TimerServiceFactory"/></propery>
             <propery name="aspectDomain>Stateless Bean</property>
            ...
            </bean>
            


            • 3. Re: using MC beanfactory for configuration
              Bill Burke Master

               

              "wolfc" wrote:
              If I see it correctly the micro kernel currently has no knowledge of aspects, it does lean and mean injection. While AOP does the aspects.

              So why not:
              <bean name="StatelessBeanContainer" class="...">
               <propery name="timerService"><factory bean="TimerServiceFactory"/></propery>
               <propery name="aspectDomain>Stateless Bean</property>
              ...
              </bean>
              


              MC does or will (it should now I believe) have knowledge of aspects. You should be able to define an aspect domain embedded within it. Maybe its best to keep the ideas separate and configured separately, maybe not.


              • 4. Re: using MC beanfactory for configuration
                Bill Burke Master

                 

                "scott.stark@jboss.org" wrote:
                As described, two bean factories with extension points in a jboss_5 xml schema makes sense. Shouldn't there be a general container framework in the unified aop/mc project that can be used of the basis of any context requiring a container with aspects and instance control?


                The EJB Container extends an AOP Advisor to gain the ability for annotation overloading, interceptor stack building, etc... Any generic container there is will have to be extensively extended for EJB specific behavior.

                I'm doing a bunch of abstraction to share behavior between Tomcat/EJB for JEE5, but it looks *REALLY* ugly so far.