Menu
▾
▴
RE: [Springframework-developer] Getting ready for 1.0 final
|
From: <tho...@tr...> - 2004-03-19 23:01:56
|
In Amsterdam many years ago. Thomas Quoting Keith Donald <kd...@cs...>: > Hey nice touch with the 'spring is coming' logo on the web-site! :) = > where > was the photo taken? Keith > > > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On Behalf = > Of > j=FCrgen h=F6ller [werk3AT] > Sent: Friday, March 19, 2004 4:42 PM > To: spr...@li... > Subject: Re: [Springframework-developer] Getting ready for 1.0 final > > > FYI, I've addressed two recently reported bugs today, one regarding > BeanWrapperImpl's handling of a single Object value for an array type, = > the > other regarding PropertyPlaceholderConfigurer which didn't parse inner = > bean > definitions before. > =20 > To fix the PropertyPlaceholderConfigurer issue, I've introduced a > BeanDefinition interface in the beans.factory.config package, = > encapsulating > the minimal set of bean definition info that's needed for = > post-processing > them. This replaces the former "getPropertyValues" and > "getConstructorArgumentValues" methods on ConfigurableBeanFactory. > RootBeanDefinition and ChildBeanDefinition implement the BeanDefinition > interface, therefore inner bean definitions can be parsed through the > interface, without making PropertyPlaceholderConfigurer aware of > implementation stuff in the beans.factory.support pacakge. > =20 > Of course, this is incompatible in terms of the ConfigurableBeanFactory > interface, but this just affects custom BeanFactoryPostProcessor > implementations and custom integration code, and it's trivial to adapt. = > As > we finally have a BeanDefinition interface now, instead of > AbstractBeanDefinition as the common root, I've also used BeanDefinition > within AbstractBeanFactory/DefaultListableBeanFactory and in the > BeanDefinitionRegistry interface. It sure looks cleaner to pass in that > interface instead of AbstractBeanDefinition. > =20 > Feel free to review these changes tomorrow; we won't release 1.0 final > before Saturday night. > =20 > Juergen > =20 > > ________________________________ > > Von: spr...@li... im Auftrag = > von > j=FCrgen h=F6ller [werk3AT] > Gesendet: Do 18.03.2004 19:07 > An: spr...@li... > Betreff: [Springframework-developer] Fw: Getting ready for 1.0 final > > > > Peter has a point here. Obviously it's easy to address the init-method = > issue > by looking for a no-arg method via plain reflection. Note that we don't = > need > BeanWrapper's "invoke" method within the framework anymore then: Thus, I > suggest to drop it completely rather than rework it to support = > overloaded > methods. Its current javadoc already discourages people to use it = > anyway, so > I don't think that anyone will miss that method much. IMO, BeanWrapper = > is > not about invoking arbitrary methods in the first place... > > Juergen > > > ________________________________ > > Von: j=FCrgen h=F6ller [werk3AT] > Gesendet: Do 18.03.2004 19:02 > An: Peter den Haan > Betreff: Re: Getting ready for 1.0 final > > > Peter, > > I've actually changed the determination of the destroy method today, to = > make > it work with "shutdown(boolean force)"-style methods (passing in true as > argument in this case). A side effect of this change is that it looks = > for a > no-arg method first now, then for one with a single boolean parameter. > > I guess I'll rewrite the init-method determination with plain reflection > too, to always look for a no-arg method. I'm not fond of the "invoke" = > method > in the BeanWrapper interface anyway; I might suggest to drop it = > completely. > I'll move this to the list. > > Juergen > > > ________________________________ > > Von: Peter den Haan [mailto:pde...@ob...] > Gesendet: Do 18.03.2004 18:13 > An: j=FCrgen h=F6ller [werk3AT] > Betreff: Re: Getting ready for 1.0 final > > > Juergen, > > I was intending to write a test case and fix for this, but it looks like = > I > may not come around to it in time. I found a limitation in = > BeanWrapperImpl > that leads to what is arguably a bug in init-method and destroy-method. > > BeanWrapperImpl.invoke() looks up the method to invoke by method name, = > not > by method signature. In a class with overloaded methods, the behaviour = > of > the code (in CachedIntrospectionResults) is essentially undefined. > > This has repercussions in a couple of places, among others the = > init-method > and destroy-method bean tag attributes. If a user specifies > destroy-method=3D"close", it is clear that the intention is for the = > no-arg > form of this method to be called even if there are other, overloaded > versions. This doesn't work at present. > > The solution I wanted to implement is to modify = > CachedIntrospectionResults > to key its method information on method signature rather than just = > method > name (the current getMethodDescriptor(String methodName) can remain > supported for backwards compatibility, although I would want to better > define its semantics). A new getMethodDescriptor(String methodName, = > Object[] > args) would implement logic to find the best matching method given the > argument count and types, using the algorithm specified in JLS = > 15.12.2.2. > > I can have a stab at implementing this over the weekend, or enter it in = > Jira > as a bug (or enhancement). Please let me know what you prefer. > > Regards, > > Peter den Haan > Principal Systems Engineer > OBJECTIVITY > Tel: 024 7642 0000 > Fax: 024 7642 0001 > Email: pde...@ob... > www.objectivity.co.uk <http://www.objectivity.co.uk/>=20 > > The contents of this email and any attachments are strictly confidential = > and > intended solely for the attention of the named addressee(s). If you are = > not > the addressee(s) you are not authorised to, and must not disclose, copy, > distribute, or retain this message without prior written authority. This > footnote also confirms that this message has been swept for the presence = > of > computer viruses but this does not guarantee that it is virus free. > > > > ________________________________________________________________________ > This e-mail has been scanned for all viruses by Star Internet. The = > service > is powered by MessageLabs. For more information on a proactive = > anti-virus > service working around the clock, around the globe, visit: > http://www.star.net.uk > ________________________________________________________________________ > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of = > GenToo > technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of = > GenToo > technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
