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

[Rod J. <rod...@in...>]

Yes, a feature freeze is nearly upon us.

I have to commit some AOP changes I made yesterday (fairly minor). Haven'=
t
tried CVS yet...

Also I want to upgrade to latest Commons Attributes today.

Then I'm done.

Regards,
Rod

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Thursday, January 22, 2004 2:59 PM
Subject: RE: [Springframework-developer] PostProcessor infrastructure in
DefaultListableBeanFactory and EJB support classes


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 b=
e
able to test and review for a couple of days and hopefully release RC1 la=
te
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
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=FCrgen h=F6ller [werk3AT] wrote:

>Colin,
>
>It may be a detail, but I'm not too happy with the two virtually identic=
al
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 coul=
d
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 cont=
ain
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 vo=
n
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 (suc=
h
>>>>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
>>
>>




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


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