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

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

Roger,
=20
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.
=20
Juergen
=20

________________________________

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 =3D getBeansOfType(ApplicationListener.class, =
true,
false).values();
    logger.debug("Found " + listeners.size() + " listeners in bean
factory");
    for (Iterator it =3D listeners.iterator(); it.hasNext();) {
        ApplicationListener listener =3D (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 =3D 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=FCrgen h=F6ller [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=3D14033&group_id=3D1#=
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=FCrgen h=F6ller [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=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/

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