Menu
▾
▴
RE: [Springframework-developer] prototypes and application listeners
|
From: Keith D. <kd...@cs...> - 2004-11-12 15:15:48
|
>You could make an argument that if a prototype implements >ApplicationListener, which is a marker interface, then it should still get >events automatically... I would think this makes the most sense in the default case. In my case it'd be one less post processor the rich client user has to define. Perhaps it should be configurable? Thanks Colin! Keith -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Colin Sampaleanu Sent: Friday, November 12, 2004 9:35 AM To: spr...@li... Subject: Re: [Springframework-developer] prototypes and application listeners Btw, both the way the code was before it was broken, and now, prototypes don't automatically get registered as listeners. This is debatably appropriate as we don't actually manage the entire lifecycle of the bean, but does means beans of these types have to be manually registered if they are to receive events. We need to at least document this, and perhaps discuss if this is actually appropriate. You could make an argument that if a prototype implements ApplicationListener, which is a marker interface, then it should still get events automatically... Colin Sampaleanu wrote: > I've looked briefly through the old getBeansOfType code, but don't > have time now to actually figure out why there was no problem before. > My guess is that getBeansOfType was broken for prototypes or something > of that nature, and Juergen actually fixed that functionality as part > of the changes. I've just changed refreshListeners() to not include > prototypes, as I can't see how this would ever ben correct. This > should resolve the problem. > > > Colin Sampaleanu wrote: > >> The code in AbstractApplicationContext.refreshListeners() definitely >> looks suspect; as you say it does a getBeansOfType(), and includes >> prototypes via a true flag for that param. But looking back, this code >> has been that way since the 1.0.2 days at least. However it looks like >> Juergen changed getBeansOfType() in DefaultListableBeanFactory, a couple >> of times in October. I'm looking into that... >> <br> >> <br> >> <br>Keith Donald wrote: >> <br> >> <br><blockquote type=cite>I am seeing some odd behavior with Spring >> prototypes that are also >> ApplicationListeners in the latest snapshot. >> <br> >> <br> >> <br> >> <br>Specifically, the context seems to be PRE instantiating and >> registering prototype instances that are application listeners (via a >> getBeansOfType call), even if no request for instantiation was >> made. >> Also, later requests for a new prototype result in that prototype not >> being registered as an application listener for the instantiating >> context. >> <br> >> <br> >> <br> >> <br>This is not the behavior I expected! I was under the >> assumption beans >> instantiated by the container that are application listeners would be >> auto-registered with the context after instantiation, as a post >> process activity. Thoughts? Keith >> <br> >> <br></blockquote> >> <br> > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
