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

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

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