Re: [Springframework-developer] Getting ready for 1.0 final

[<jue...@we...>]

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