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

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

I originally kept them separate because I wasn't sure it was even worth 
keeping the old XmlBeanFactoryLoader around. Given that the appcontext 
implementation is the default, and brings in the appcontext related 
classes anyways, I can't think of many compelling reasons why somebody 
using ejbs would override and use a beanfactory instead...

However, as today I was going to check in the beanfactory/context 
loading stuff I mentioned last week, I was thinking that there are some 
similarities between the existing interface and usage scenarios to what 
I was going to check in. I am going to try to see if I can combine the 
classes. In this case, most of the code would move elsewhere, and all 
that would stay in the ejb package would be a small subclass that has a 
specific jndi path.


jürgen höller [werk3AT] wrote:

>Colin,
> 
>It may be a detail, but I'm not too happy with the two virtually identical classes XmlBeanFactoryLoader and XmlApplicationContextBeanFactoryLoader (and the name of the latter).
> 
>I suggest to refactor the latter as a subclass of XmlBeanFactoryLoader: Why not simply offer a "BeanFactory createBeanFactory(String beanFactoryPath)" template method there, defaulting to an XmlBeanFactory? The subclass could then override this for a ClassPathXmlApplicationContext.
> 
>Regarding the name, I suggest to call the subclass "XmlApplicationContextLoader", even if it does not contain the full interface name "BeanFactoryLoader": After all, an ApplicationContext *is* a BeanFactory, so it's better to just use one of the two terms in the class name, IMO.
> 
>As a side note, the transaction manager implementation names do not contain the full interface name "PlatformTransactionManager" either. In general, if the resulting name is expressive enough, I prefer such a simplified name instead of one that contains the full interface name in the first place.
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Colin Sampaleanu
>Gesendet: So 18.01.2004 01:21
>An: spr...@li...; Peter den Haan
>Betreff: Re: [Springframework-developer] PostProcessor infrastructure in DefaultListableBeanFactory and EJB support classes
>
>
>
>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
>>    
>>