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

[<jue...@we...>]

Colin,
=20
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).
=20
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.
=20
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.
=20
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.
=20
Juergen
=20

________________________________

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.
>>> =20
>>
>> 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).
>>=20
>>
> 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
>




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer