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

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

Thanks Colin

when Juergen actually commits the code, I'll give a try ;)



"Colin Sampaleanu" <col...@ex...> wrote in message
news:3FA...@ex......
> Roger,
>
> Try hitting the 'alternate' CVS server at sf.net described here:
>
>
http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1#firewal
l
>
> It does allow anon access, and last time I verified this (about a month
> ago), it was completely up to date, as opposed to 24 hours behind like
> the main anon server.
>
>
>
> roger holbrook wrote:
>
> >Hi Juergen
> >
> >The changes you describe sound great - & as soon as anonymous CVS catches
> >up, I'll check them out.  Unfortunately, all I can see so far is an empty
> >beans.factory.config directory :(
> >
> >Many thanks
> >
> >Roger
> >
> >
> >"jürgen höller [werk3AT]" <jue...@we...> wrote in message
> >news:170...@co......
> >Roger,
> >
> >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.
> >
> >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.
> >
> >Thanks for the thorough code review, BTW :-)
> >
> >Juergen
> >
> >
> >________________________________
> >
> >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ü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
> >>
> >>
>
>
>
>
> -------------------------------------------------------
> 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/