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

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

Peter den Haan wrote:

>Colin Sampaleanu wrote:
>
>>eanPostProcessors 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.
>>    
>>
>Ah, but that's the funny thing. This is not entirely true. The actual
>postprocessing plumbing is part and parcel of the DefaultListableBeanFactory
>itself. However, it does not auto-register any postprocessors itself. That
>is done by the application context. Given the important place postprocessing
>has been gaining in the Spring infrastructure, it seems odd that EJBs do get
>a BeanFactory that does in fact have all it takes (you do not need a full
>context) but is still very limited because its postprocessing plumbing isn't
>initialised.
>
>Users new to the product would expect Spring to provide some out-of-the-box
>support for a fully functional bean container in the EJB tier, probably by
>default. As things stand, you won't be getting this without coding (and a
>nontrivial understanding of Spring subtleties).
>  
>
The fact that DefaultListableBeanFactory has some of the support code is 
somewhat irrelevant. The contract is that if something has the 
ApplicationContext interface it supports BeanPostProcessors, and if it 
doesn't (i.e. it is simply a BeanFactory), it doesn't support 
BeanPostProcessors. And this is how the current code behaves. As I said, 
I agree that the distinction between application contexts and bean 
factories needs to be better documented, and it probably makes sense for 
the default BeanFactoryLoader in the base EJB classes to produce an 
ApplicationContext variant instead of just a regular BeanFactory. That 
code actually got into Spring before I got to the project, so I'm not 
sure why it was decided one way vs. another. If there is no opposition, 
I am quite willing to make that change...

Regards,
Colin