Menu
▾
▴
Re: [Springframework-developer] Plug'nPlay for AbstractApplicationContext & ListableBeanFactory
|
From: <jue...@we...> - 2003-11-04 23:32:26
|
Roger, everybody, =20 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... =20 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. =20 Juergen =20 ________________________________ 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 |
