Re: [Springframework-developer] PostProcessor infrastructure in DefaultListableBeanFactory and EJB support classes

[Colin S. <col...@ex...>]

Hi Peter,

BeanPostProcessors are a function of ApplicationContexts, so it is 
normal that BeanFactories which are not also ApplicationContexts (such 
as that produced by XMLBeanFactoryLoader) do no post-processing.

However, I do agree that the differences betweeen plain BeanFactories 
and ApplicationContexts should probably be better documented, and the 
XMLBeanFactoryLoader should state that it produces a BeanFactory, not an 
ApplicationContext. Alternately, it could possibly produce an 
ApplicationContext.

fyi, I currently override the default BeanFactoryLoader in my ejbs, as 
follows:

    setBeanFactoryLoader(new BeanFactoryLoader() {
      public BeanFactory loadBeanFactory() throws BootstrapException {
        ContextLocator cf = ContextLocatorFactory.getInstance();
        ApplicationContext appContext =
          cf.useContext(ServicesConstants.CONTEXT_GROUP_KEY, 
ServicesConstants.PRIMARY_CONTEXT_ID);
        return appContext;
      }
      public void unloadBeanFactory(BeanFactory bf) throws 
FatalBeanException {
      }
    });

This relies on my own ContextLocator interface/impl, to actually load in 
on-demand, a hierarchy of ApplicationContexts.

Regards,
Colin


Peter den Haan wrote:

> One thing that recently confused the heck out of me was that my AOP 
> interceptors wouldn't work in an EJB context (1.0M4). Advice simply 
> wasn't being applied to my beans even though precisely the same 
> configuration worked fine in the web tier. Given that 
> DefaultListableBeanFactory does contain the full BeanPostProcessor 
> infrastructure, I didn't see how that could be.
>  
> Upon closer examination, it turned out that the bean factory does not 
> initialise its own BeanPostProcessors. Instead, 
> AbstractApplicationContext does this by pulling all beans implementing 
> BeanPostProcessor out of the factory and registering them in order 
> before any of the other beans get instantiated. The 
> XmlBeanFactoryLoader used by the EJB support classes, on the other 
> hand, does no such thing. (Something similar can be said about 
> BeanFactoryPostProcessors. Unless I'm missing something, this 
> interface receives support only in an application context and has no 
> bean hierarchy support at all.)
>  
> Given that more and more of Spring's infrastructure relies on 
> postprocessing, the BeanFactory support in AbstractEnterpriseBean 
> seems crippled unless you roll your own XmlBeanFactoryLoader along the 
> lines of attached class. We could do any of a number of things with this.
>
>     * BeanPostProcessor registration could be made a responsibility of
>       DefaultListableBeanFactory, although this might break existing
>       software. I assume there's a good reason why this is an context
>       rather than a factory responsibility.
>     * A new loader along the lines of attached file could be added to
>       the framework, and should probably used by default in
>       AbstractEnterpriseBean. Wholesale cutting and pasting from
>       AbstractApplicationContext can be avoided by migrating
>       BeanFactoryPostProcessor and BeanPostProcessor registration to
>       either a utility class or to utility methods in
>       DefaultListableBeanFactory (these would not be part of the
>       normal factory refresh, but would have to be invoked explicitly).
>     * Instead of creating a new loader, BeanPostProcessor registration
>       could simply be incorporated into XmlBeanFactoryLoader itself.
>     * Everything could be left as is. In that case I feel the
>       restrictions of bean support in a plain factory (as in EJBs)
>       should be very clearly documented, otherwise this is going to
>       confuse and discourage quite a few people.
>
> Thanks for reading as far as this :) Let me know what you think. I 
> would be more than happy to supply patches for the above against the 
> current CVS head.
>  
>  - Peter
>  
>