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

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

Juergen

Thanks for the clarification - now it all makes perfect sense ;)

Roger

"jürgen höller [werk3AT]" <jue...@we...> wrote in message
news:170...@co......
Roger,

ApplicationListener beans are not normally returned to application code.
They are registered with the application context and get automatically
notified of ApplicationEvents. Why would you want to touch an
ApplicationListener in another application object? I agree that prototype
listeners do not have any benefits, thus listeners will almost always be
singletons. I thus wouldn't mind changing that getBeansOfType call to
(false, false) but I don't see any misbehavior with the current
implementation either.

Juergen

________________________________

Von: spr...@li... im Auftrag von
roger holbrook
Gesendet: Mi 05.11.2003 11:10
An: spr...@li...
Betreff: [[W3-SPAM]] - [Springframework-developer] Re: Plug'nPlay for
AbstractApplicationContext & ListableBeanFactory - Email found in subject

Hi Juergen

At first glance the interfaces in the beans.factory.config interfaces look
great - Plug'nPlay restored !

On the use of getBeansOfType() in AbstractApplicationContext, to refine the
instances returned, there still seems to be something odd to me.  The code
from within AbstractApplicationContext() now looks like this:

private void refreshListeners() {
    logger.info("Refreshing listeners");
    Collection listeners = getBeansOfType(ApplicationListener.class, true,
false).values();
    logger.debug("Found " + listeners.size() + " listeners in bean
factory");
    for (Iterator it = listeners.iterator(); it.hasNext();) {
        ApplicationListener listener = (ApplicationListener) it.next();
        addListener(listener);
        logger.info("Application listener [" + listener + "] added");
    }
}

But I think the behaviour that follows will actually be a bit strange, ie:
- all singletons bean instances that implement ApplicationListener will have
been registered as listeners by the time they are returned from getBean() to
application code
- all prototype bean instances that implement ApplicationListener will NOT
have been registered as listeners by the time they are returned from
getBean() to application code
- a set of prototype bean instances that implement ApplicationListener WILL
have been registered as listeners, by the above code, but these will NOT be
returned from getBean() to any application code

I think I was probably expecting to see the above call looking like:

    Collection listeners = getBeansOfType(ApplicationListener.class, false,
false).values();

and the prototypes dealt with using something like
ApplicationContextAwareProcessor, but having said that, I suppose that could
take care of the singletons as well - tra la.

The bottom line is I actually have no idea at all how these listeners might
be being used - so this may all be completely irrelevant - anyway no
doubt you'll set me straight ;)

Roger

"jürgen höller [werk3AT]" <jue...@we...> wrote in message
news:170...@co......
Roger, everybody,

I've just committed all the stuff that I've been working on, including the
bean factory SPI interfaces, the reworked post-processors, and the
BeanNameAware interface. In the course of this, I've refined quite some API
signatures and even package locations - there is a new beans.factory.config
package now, with the post-processor interfaces moved there. Most
applications shouldn't be affected, but for example custom post-processor
implementations will be. For details, see the changelog and the new CVS
contents...

BTW, I've also adopted your suggestion regarding getBeansOfType and added
"includePrototypes" and "includeFactoryBeans" flags, indicating whether one
wants to perform those more expensive operations too.

Juergen

________________________________

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

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/

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

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

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

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