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

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

As per the thread below from about a week ago, I have defaulted 
AbstractEnterpriseBean and its subclasses to use a new 
XmlApplicationContextBeanFactoryLoader, which will load and create an 
ApplicationContext from the classpath. For a lighter weight solution 
when ApplicationContexts are not needed, people may still switch in the 
old XmlBeanFactoryLoader.

One comment though, is that if you look at a common usage scenario, 
which is to call out from Session ejbs to service POJOs using 
Hibernate-based DAO/Mapper objects, this solution is still not good 
enough, in that every EJB ends up creating an application context, which 
ends up creating a new session factory for every EJB. For this reason, I 
still drop in a custom BeanFactoryLoader which loads/accesses a shared 
ApplicationContext via the KeyedSingletonContextLocator I posted here a 
while ago.

Regards,
Colin


Colin Sampaleanu wrote:

> 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
>