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

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

That sounds good - looking forward to seeing your new loader stuff! BTW, =
I'm about to finish the extended transaction propagation support =
today... I guess it would be good to do a definite feature freeze this =
weekend, to be able to test and review for a couple of days and =
hopefully release RC1 late next week.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Thursday, January 22, 2004 3:41 PM
To: spr...@li...
Subject: Re: [Springframework-developer] PostProcessor infrastructure in
DefaultListableBeanFactory and EJB support classes


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

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


j=FCrgen h=F6ller [werk3AT] wrote:

>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:
>
> =20
>
>>Peter den Haan wrote:
>>
>>   =20
>>
>>>Colin Sampaleanu wrote:
>>>
>>>     =20
>>>
>>>>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
>>>>       =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
>>   =20
>>




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