Re: [Springframework-developer] Re: Plug'nPlay for AbstractApplicationContext & ListableBeanFactory

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Roger,
=20
I've adopted your idea of an SPI interface for bean factories: I've just =
introduced ConfigurableBeanFactory and ConfigurableListableBeanFactory =
interfaces in a new beans.factory.config package; I've also moved =
BeanFactoryProcessor and BeanFactoryPostProcessor there. The latter's =
postProcessBeanFactory method uses ConfigurableListableBeanFactory now, =
as does AbstractApplicationContext's getBeanFactory template method.
=20
I'm still not entirely sure why you would want to use a different bean =
factory with AbstractApplicationContext to leverage AOP functionality. =
All of Spring's AOP support should work without making the bean factory =
implementation explicitly aware of it. BeanPostProcessors and =
BeanFactoryPostProcessors are automatically detected and applied if =
defined as beans in an application context.
=20
Thanks for the thorough code review, BTW :-)
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von roger holbrook
Gesendet: So 02.11.2003 18:46
An: spr...@li...
Betreff: [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] - [[W3-SPAM]] - =
[[W3-SPAM]] - [Springframework-developer] Re: Plug'nPlay for =
AbstractApplicationContext & ListableBeanFactory - Email found in =
subject - Email found in subject - Email found in subject - Email found =
in subject - Email found in subject

Hi Juergen

Many thanks for the explanation about
AbstractApplicationContext.getBeanFactory.

Just to check I've got it straight - would the following be an accurate
summary:
- ListableBeanFactory & ApplicationContext are client facing interfaces
designed to hide all things related to implementation.
- ListableBeanFactoryImpl & AbstractApplicationContext provide =
consistent
out-of-the-box BeanFactory implementations that are considered of =
essential
importance.
- Currently the linkage between these 2 default implementations happens =
to
be that one acts as a delegate class for the other, ie. the return type =
in
question.

The reworking of JdbcBeanFactory as a subclass of =
ListableBeanFactoryImpl,
obviously solves the wiring problem in this particular case - but it =
does
nothing for the general case of Plug'nPlay.  With the current =
arrangement,
the one thing I cannot do is achieve effective easy reuse of all that =
highly
crafted functionality that is so intricately wired up in =
AbstractBeanFactory
and ListableBeanFactoryImpl - I cannot wrap and delegate !

Aside from the implied name conflict, could you not preserve the =
original
intention of making the linkage between the two an internal interface:

interface ListableBeanFactoryImp extends ListableBeanFactory {

    public void ignoreDependencyType(Class type)

    public void addBeanPostProcessor(BeanPostProcessor =
beanPostProcessor)

    public final void destroySingletons()

}

The example that is actually motivating my thinking, is related to the =
AOP
stuff.  If I want try to add functionality to a BeanFactory so that it =
can
be aware of ProxyFactoryBean's for example, then the most simple =
approach
would be to use an XmlBeanFactory to read the bean definitions, but then =
to
wrap and delegate to this, from within an AOP aware BeanFactory.  The =
latter
could initialise itself via a BeanFactoryPostProcessor, and then provide
useful implementation support within the AOP module, ie it would again =
be
extending a ListableBeanFactoryImp interface, rather than anything =
client
facing.

As you say, all this can obviously be achieved by building BeanFactory's =
&
ApplicationContext's from scratch, but it seems a great shame not to be =
able
to reuse the ListableBeanFactoryImpl class - it has so much to offer ;)

Anyway, I am sure the you get the sense of what I am on about - I just =
hope
I am not missing something fundamental to the whole issue ;)

Roger

"j=FCrgen h=F6ller [werk3AT]" <jue...@we...> wrote in =
message
news:420...@ma......
> First of all, thanks for your kind words, Roger -- I appreciate them! =
:-)
>
> Regarding AbstractApplicationContext.getBeanFactory: I've indeed =
changed
its return value from ListableBeanFactory to ListableBeanFactoryImpl a =
while
ago, reason being that AbstractApplicationContext needs some =
configuration
stuff that AbstractBeanFactory and ListableBeanFactoryImpl offer. The
BeanFactory and ListableBeanFactory interfaces are intended for client
applications that access beans, they do not and should not include any
factory configuration or lifecycle methods.
>
> In detail, AbstractApplicationContext needs to invoke the following =
bean
factory implementation methods:
>
> - ignoreDependencyType: to register ApplicationContext as dependency =
type
to ignore on autowiring (as it is set by the ApplicationContextAware
interface, not by a property value).
>
> - addBeanPostProcessor: to register BeanPostProcessors, both
ApplicationContextAwareProcessor and custom ones, before creating
application beans from the bean definitions.
>
> - destroySingletons: to destroy singleton instances on application =
context
shutdown; particularly important for resource holders like a =
BasicDataSource
or a LocalSessionFactoryBean.
>
> - Furthermore, the postProcessBeanFactory method in the
BeanFactoryPostProcessor interface declares a ListableBeanFactoryImpl
parameter to allow for access to all these bean factory configuration
methods. A ListableBeanFactory interface would be meaningless for this, =
as
you can't do any post-processing of bean definitions without access to =
them
and means to manipulate them.
>
> Let's not forget that is always possible to write an own
ApplicationContext implementation with any kind of bean factory =
underneath,
or a direct implementation of bean factory functionality instead of a
delegate, by not deriving from AbstractApplicationContext. The latter is
specifically intended for ListableBeanFactoryImpl delegates, providing =
rich
configuration functionality on top of them.
>
> Regarding JdbcBeanFactory: This one used a delegate
ListableBeanFactoryImpl underneath to be able to perform on-demand
refreshing. This is somewhat inconsistent with XmlBeanFactory's
implementation style: The latter derives from ListableBeanFactoryImpl =
and
adds various XML-related registerBeanDefinitions methods, leaving =
refresh
functionality to application contexts. IMO, that's a clear separation of
responsibilities: A BeanFactory is a low-level implementation; an
ApplicationContext builds higher-level functionality on top of it.
>
> Thus, I've changed JdbcBeanFactory to extend ListableBeanFactoryImpl =
and
provide a registerBeanDefinitions(sql) method. Of course, it still has =
the
former (dataSource,sql) constructor as a convenience. I don't think that
anyone used JdbcBeanFactory's on-demand refresh anyway (or even loading
beans from a database in the first place), so that change shouldn't =
hurt. So
you can use JdbcBeanFactory with AbstractApplicationContext too, as it =
is a
ListableBeanFactoryImpl now :-)
>
> Rod, do you agree with the rationale? I believe it's straightforward =
and
consistent, particularly now that JdbcBeanFactory has adopted
XmlBeanFactory's implementation style. I hope you don't object to
JdbcBeanFactory being a ListableBeanFactoryImpl; as I've said, I believe =
it
is important to provide consistent out-of-the-box BeanFactory
implementations (i.e. no refresh in bean factories but just in =
application
contexts).
>
> Juergen
>
>
> -----Urspr=FCngliche Nachricht-----
> Von: Rod Johnson [mailto:rod...@in...]
> Gesendet: Sa 01.11.2003 17:32
> An: spr...@li...
> Cc:
> Betreff: Re: [Springframework-developer] Plug'nPlay for
AbstractApplicationContext & ListableBeanFactory
>
>
>
> Roger,
>
> > I've been lurking about for a fair while, being thoroughly impressed =
by
> > Springframework - the conception, the code, this excellent list, =
Rod's
> book,
> > in short the whole shebang - it seems quite a while since I =
encountered
a
> > project that more than anything, just seems to make me smile ;)  =
Many
> > thanks.
>
> Thanks. Made me smile :-)
>
> > First up is the subject line & the method
> > AbstractApplicationContext.getBeanFactory()
> > I am wondering if the signature for this method might have been =
changed
> > inadvertently ?  Prior to the introduction of support for
> > BeanFactoryPostProcessor's, the method was returning the
> ListableBeanFactory
> > interface, but thereafter it has been ListableBeanFactoryImpl.  As =
the
> > latter comes with a final modifier on each of the methods =
implementing
> that
> > interface, the opportunity for Plug'nPlay appears to have gone
missing...
> &
> > if I'm not mistaken, a first casualty would be the loss of a
> JdbcBeanFactory
> > within an AbstractApplicationContext.  Can someone shed some
> > light - am I just missing something ?
>
> I'll leave this one to Juergen, but I did notice it in passing and
> wondered...
>
> >
> > By the way, on my wanderings I noticed the following typo in
> > AbstractBeanDefinition.equals()
>
> Thanks, fixed it. Ah, the beauty of open source. That code isn't =
currently
> used btw, it was intended to allow for dynamic reconfiguration =
eventually.
> There would have been an argument for zapping it for now, actually.
>
> Regards,
> Rod
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> N=18HY??X'u?=16w=1A+m?$> =12 xZ+? =17*.m?k +=0E?^? j?z^?=1Dy! =
DD=10?=11?i ^=0EP)brA?m?q =07?z v

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer