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

[roger h. <apo...@sn...>]

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ürgen höller [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üngliche 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
>
>
> NHY??X'u?w+m?$>  xZ+? *.m?k +?^? j?z^?y! DD??i ^P)brA?m?q ?z v