2 Replies Latest reply on Mar 31, 2008 10:16 AM by Adrian Brock

    Contract ejb3-interceptors and bean-factory

    Carlo de Wolf Master

      I'm having a serious regression issue in ejb3-interceptors where interceptor instances are no longer bound to an EJB lifecycle, but to the container instead.

      Basically there is no way to store the interceptors per bean instance. So to preserve the StatelessObjectFactory API I build ejb3-attachments, which allows for attaching interceptor instances to a bean.

      (Note: that the problem does not occur in 'basic' (AOP) operation of ejb3-interceptors, because then the 'PER_INSTANCE' advice is correctly picked up by AOP. So in effect the 'PER_INSTANCE' advice isn't handled correctly by the interceptor BeanContainer (or ManagedAdvisor). If we want to move more AOP then the real fix is to have a proper instance advisor.)

      The main problem with attachments is that passivation needs to be aware. Which is precisely what I not want.

      Beyond scope for this discussion: pool (which is a consumer of the bean factory) and injection (which is a facilitator within the bean factory). The injection of interceptors I want to handle in a separate thread.

      Maybe we need an InstanceContext / BeanContext from the StatelessObjectFactory:

      Factory<T> {
       BeanContext<T> create();
      };
      
      BeanContext<T> {
       T getInstance();
      
       <A> A getAttachment(Object key, Class<A> attachmentType);
      }


      Does MC have such a thing?

      (Note 2: the current ejb3-interceptors also calls PostConstruct on the bean, which I think is wrong (it's JSR-250 functionality, not EJB 3 ch 8), however the ejb3-interceptors component needs a visitor hook in bean-factory to allow for attachment / interceptors construction (via the same bean-factory?)).

        • 1. Re: Contract ejb3-interceptors and bean-factory
          Ales Justin Master

           

          "wolfc" wrote:
          Maybe we need an InstanceContext / BeanContext from the StatelessObjectFactory:
          Factory<T> {
           BeanContext<T> create();
          };
          
          BeanContext<T> {
           T getInstance();
          
           <A> A getAttachment(Object key, Class<A> attachmentType);
          }


          Does MC have such a thing?

          What exactly are you looking for?

          You can now change the underlying BeanFactory class.
          Previous versions always used GenericBeanFactory.
          Now you can set factoryClass attribute.
          What your factory impl does is your thing. ;-)
          e.g. CarlosBF::createBean() would always return BeanContext

          • 2. Re: Contract ejb3-interceptors and bean-factory
            Adrian Brock Master

             

            "wolfc" wrote:
            If we want to move more AOP then the real fix is to have a proper instance advisor.)


            Sounds to me like you know where the real problem lies?


            Maybe we need an InstanceContext / BeanContext from the StatelessObjectFactory:
            Factory<T> {
             BeanContext<T> create();
            };
            
            BeanContext<T> {
             T getInstance();
            
             <A> A getAttachment(Object key, Class<A> attachmentType);
            }


            Does MC have such a thing?


            I don't know what you mean? Why would the MC know anything about
            the BeanContext instances? The only thing it manages is the factory.

            It's like saying if you deploy the TransactionManager using the MC
            does it know anything about the transactions? :-)