Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-03-19 21:44:14
|
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
|
|
From: <jue...@we...> - 2004-03-19 22:39:24
|
A further note: I've also added a notice.txt file, corresponding to the =
Apache License 2.0. Feel free to review that too :-)
=20
BTW, Alef or someone else who deals with the reference docs, could you =
please update the reference PDF in CVS tomorrow, possibly reviewing the =
contents once more?
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Fr 19.03.2004 22:42
An: spr...@li...
Betreff: 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.
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.
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.
Feel free to review these changes tomorrow; we won't release 1.0 final =
before Saturday night.
Juergen
________________________________
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/>
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=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: <jue...@we...> - 2004-03-23 22:12:59
|
Let's return 0, analogous to ResultSet.getInt; I'll fix this for 1.0 = final (which is otherwise ready, including all docs and readmes). =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von tho...@tr... Gesendet: Di 23.03.2004 22:47 An: spr...@li... Betreff: RE: [Springframework-developer] Getting ready for 1.0 final Found on minor quirk in the new JdbcTemlpate convenience methods. = queryForInt returns the following confusing exception when the query returns the = value NULL. org.springframework.dao.InvalidDataAccessApiUsageException: Result = object (db-type=3D"NUMBER" value=3D"null") is of type [java.math.BigDecimal] = and not of required type [java.lang.Number] We could either return 0 (like getInt() on the ResultSet would), or we = could throw an exception with a different message. What do you think? I don't think this is a big deal, so I would not delay the release for = 1.0. Thomas ------------------------------------------------------- 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=3D1470&alloc_id=3D3638&op=3Dcli= ck _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <tho...@tr...> - 2004-03-23 22:28:40
|
I'm comitting these changes now - all tests pass!!! Thomas Quoting "jürgen höller [werk3AT]" <jue...@we...>: > Let's return 0, analogous to ResultSet.getInt; I'll fix this for 1.0 = > final (which is otherwise ready, including all docs and readmes). > =20 > Juergen > =20 > > ________________________________ > > Von: spr...@li... im Auftrag = > von tho...@tr... > Gesendet: Di 23.03.2004 22:47 > An: spr...@li... > Betreff: RE: [Springframework-developer] Getting ready for 1.0 final > > > > Found on minor quirk in the new JdbcTemlpate convenience methods. = > queryForInt > returns the following confusing exception when the query returns the = > value > NULL. > > org.springframework.dao.InvalidDataAccessApiUsageException: Result = > object > (db-type=3D"NUMBER" value=3D"null") is of type [java.math.BigDecimal] = > and not of > required type [java.lang.Number] > > We could either return 0 (like getInt() on the ResultSet would), or we = > could > throw an exception with a different message. > > What do you think? > > I don't think this is a big deal, so I would not delay the release for = > 1.0. > > Thomas > > > > > ------------------------------------------------------- > 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=3D1470&alloc_id=3D3638&op=3Dcli= > ck > _______________________________________________ > 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 > |
|
From: <tho...@tr...> - 2004-03-23 22:33:34
|
Same thing was true for queryForObject - it gave this amusing error org.springframework.dao.InvalidDataAccessApiUsageException: Result object (db-type="VARCHAR2" value="null") is of type [java.lang.String] and not of required type [java.lang.String] After the latest change it now returns a null. Thomas Quoting "jürgen höller [werk3AT]" <jue...@we...>: > Let's return 0, analogous to ResultSet.getInt; I'll fix this for 1.0 = > final (which is otherwise ready, including all docs and readmes). > =20 > Juergen > =20 > > ________________________________ > > Von: spr...@li... im Auftrag = > von tho...@tr... > Gesendet: Di 23.03.2004 22:47 > An: spr...@li... > Betreff: RE: [Springframework-developer] Getting ready for 1.0 final > > > > Found on minor quirk in the new JdbcTemlpate convenience methods. = > queryForInt > returns the following confusing exception when the query returns the = > value > NULL. > > org.springframework.dao.InvalidDataAccessApiUsageException: Result = > object > (db-type=3D"NUMBER" value=3D"null") is of type [java.math.BigDecimal] = > and not of > required type [java.lang.Number] > > We could either return 0 (like getInt() on the ResultSet would), or we = > could > throw an exception with a different message. > > What do you think? > > I don't think this is a big deal, so I would not delay the release for = > 1.0. > > Thomas > > > > > ------------------------------------------------------- > 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=3D1470&alloc_id=3D3638&op=3Dcli= > ck > _______________________________________________ > 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 > |
|
From: Keith D. <kd...@cs...> - 2004-03-19 22:38:22
|
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
|
|
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 > |
|
From: Alef A. <al...@jt...> - 2004-03-22 20:32:20
|
No tulips in the center of Amsterdam anymore nowadays, too bad... By the way, I still have to see the first tulips popping up, it's still freezing here ;-). Alef > 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 > > > > > > > > ------------------------------------------------------- > 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 |
|
From: Keith D. <kd...@cs...> - 2004-03-22 21:16:06
|
If you guys need pictures of palm trees, I can send some ;) It's = already up into the 80's here. However Seth Ladd gets my prize for the sweetest location, hard to beat Hawaii - it's spring year around there :) Keith -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of Alef Arendsen Sent: Monday, March 22, 2004 3:37 PM To: spr...@li... Subject: RE: [Springframework-developer] Getting ready for 1.0 final No tulips in the center of Amsterdam anymore nowadays, too bad... By the way, I still have to see the first tulips popping up, it's still freezing here ;-). Alef > In Amsterdam many years ago. >=20 > Thomas >=20 > Quoting Keith Donald <kd...@cs...>: >=20 > > Hey nice touch with the 'spring is coming' logo on the web-site! :) = > > =3D where was the photo taken? Keith > > > > > > -----Original Message----- > > From: spr...@li... > > [mailto:spr...@li...] On=20 > > Behalf > =3D > > Of > > j=3DFCrgen h=3DF6ller [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=20 > > BeanWrapperImpl's handling of a single Object value for an array=20 > > type, =3D the other regarding PropertyPlaceholderConfigurer which=20 > > didn't parse inner =3D bean > > definitions before. > > =3D20 > > To fix the PropertyPlaceholderConfigurer issue, I've introduced a > > BeanDefinition interface in the beans.factory.config package, =3D > > encapsulating > > the minimal set of bean definition info that's needed for =3D > > 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. > > =3D20 > > 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. > =3D > > As > > we finally have a BeanDefinition interface now, instead of=20 > > AbstractBeanDefinition as the common root, I've also used=20 > > BeanDefinition within AbstractBeanFactory/DefaultListableBeanFactory = > > and in the BeanDefinitionRegistry interface. It sure looks cleaner=20 > > to pass in that interface instead of AbstractBeanDefinition. =3D20 > > Feel free to review these changes tomorrow; we won't release 1.0 = final > > before Saturday night. > > =3D20 > > Juergen > > =3D20 > > > > ________________________________ > > > > Von: spr...@li... im=20 > > Auftrag =3D von j=3DFCrgen h=3DF6ller [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=20 > > init-method =3D issue by looking for a no-arg method via plain=20 > > reflection. Note that we don't > =3D > > need > > BeanWrapper's "invoke" method within the framework anymore then:=20 > > Thus, I suggest to drop it completely rather than rework it to=20 > > support =3D overloaded methods. Its current javadoc already=20 > > discourages people to use it =3D anyway, so > > I don't think that anyone will miss that method much. IMO, = BeanWrapper =3D > > is > > not about invoking arbitrary methods in the first place... > > > > Juergen > > > > > > ________________________________ > > > > Von: j=3DFCrgen h=3DF6ller [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 > =3D > > make > > it work with "shutdown(boolean force)"-style methods (passing in=20 > > true as argument in this case). A side effect of this change is that = > > it looks =3D for a no-arg method first now, then for one with a = single=20 > > boolean parameter. > > > > I guess I'll rewrite the init-method determination with plain=20 > > reflection too, to always look for a no-arg method. I'm not fond of=20 > > the "invoke" =3D method in the BeanWrapper interface anyway; I might = > > suggest to drop it =3D 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=3DFCrgen h=3DF6ller [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=20 > > like > =3D > > I > > may not come around to it in time. I found a limitation in =3D=20 > > BeanWrapperImpl that leads to what is arguably a bug in init-method=20 > > and destroy-method. > > > > BeanWrapperImpl.invoke() looks up the method to invoke by method=20 > > name, =3D not by method signature. In a class with overloaded = methods,=20 > > the behaviour =3D of > > the code (in CachedIntrospectionResults) is essentially undefined. > > > > This has repercussions in a couple of places, among others the =3D=20 > > init-method and destroy-method bean tag attributes. If a user=20 > > specifies destroy-method=3D3D"close", it is clear that the intention = > > is for the =3D 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 =3D=20 > > CachedIntrospectionResults to key its method information on method=20 > > signature rather than just =3D 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, = =3D > > Object[] > > args) would implement logic to find the best matching method given = the > > argument count and types, using the algorithm specified in JLS =3D > > 15.12.2.2. > > > > I can have a stab at implementing this over the weekend, or enter it = > > in > =3D > > 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/>=3D20 > > > > The contents of this email and any attachments are strictly=20 > > confidential > =3D > > and > > intended solely for the attention of the named addressee(s). If you = > > are > =3D > > not > > the addressee(s) you are not authorised to, and must not disclose,=20 > > copy, distribute, or retain this message without prior written=20 > > authority. This footnote also confirms that this message has been=20 > > swept for the presence > =3D > > 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 = =3D > > service > > is powered by MessageLabs. For more information on a proactive =3D > > 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=20 > > of =3D GenToo technologies. Learn everything from fundamentals to=20 > > system=20 > > = administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id638&op=3D3Dick > > _______________________________________________ > > Springframework-developer mailing list=20 > > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springframework-develop > > er > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: IBM Linux Tutorials > > Free Linux tutorial presented by Daniel Robbins, President and CEO=20 > > of =3D GenToo technologies. Learn everything from fundamentals to=20 > > system=20 > > = administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id638&op=3DCCk > > _______________________________________________ > > Springframework-developer mailing list=20 > > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springframework-develop > > er > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: IBM Linux Tutorials > > Free Linux tutorial presented by Daniel Robbins, President and CEO=20 > > of GenToo technologies. Learn everything from fundamentals to system = > > = administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= c > > k > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > = https://lists.sourceforge.net/lists/listinfo/springframework-developer > > >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of=20 > GenToo technologies. Learn everything from fundamentals to system=20 > = administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck > _______________________________________________ > Springframework-developer mailing list=20 > 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=3D1470&alloc_id=3D3638&op=3Dcli= ck _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Seth L. <se...@eh...> - 2004-03-22 21:36:48
|
Keith Donald wrote: > If you guys need pictures of palm trees, I can send some ;) It's already up > into the 80's here. > > However Seth Ladd gets my prize for the sweetest location, hard to beat > Hawaii - it's spring year around there :) hehe except when it's the rainy season, which happens to be right now. Speaking of, if anyone is in Hawaii and wants to talk Spring, or just Java stuff in general, let me know! Also, I was at the San Diego Software Symposium (the nofluffjuststuff one) last week and Spring was definitely the buzz. Looking forward to 1.0! Thanks to everyone for their hard work. Seth |
|
From: <tho...@tr...> - 2004-03-23 21:47:52
|
Found on minor quirk in the new JdbcTemlpate convenience methods. queryForInt returns the following confusing exception when the query returns the value NULL. org.springframework.dao.InvalidDataAccessApiUsageException: Result object (db-type="NUMBER" value="null") is of type [java.math.BigDecimal] and not of required type [java.lang.Number] We could either return 0 (like getInt() on the ResultSet would), or we could throw an exception with a different message. What do you think? I don't think this is a big deal, so I would not delay the release for 1.0. Thomas |
|
From: Rod J. <rod...@in...> - 2004-03-20 06:58:25
|
Yes, I really like it too!
----- Original Message -----
From: "Keith Donald" <kd...@cs...>
To: <spr...@li...>
Sent: Friday, March 19, 2004 10:38 PM
Subject: RE: [Springframework-developer] Getting ready for 1.0 final
Hey nice touch with the 'spring is coming' logo on the web-site! :) wher=
e
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, th=
e
other regarding PropertyPlaceholderConfigurer which didn't parse inner be=
an
definitions before.
To fix the PropertyPlaceholderConfigurer issue, I've introduced a
BeanDefinition interface in the beans.factory.config package, encapsulati=
ng
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.
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. A=
s
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.
Feel free to review these changes tomorrow; we won't release 1.0 final
before Saturday night.
Juergen
________________________________
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 is=
sue
by looking for a no-arg method via plain reflection. Note that we don't n=
eed
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 m=
ake
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" met=
hod
in the BeanWrapper interface anyway; I might suggest to drop it completel=
y.
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 BeanWrapperImp=
l
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, no=
t
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-metho=
d
and destroy-method bean tag attributes. If a user specifies
destroy-method=3D"close", it is clear that the intention is for the no-ar=
g
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 CachedIntrospectionResult=
s
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, Objec=
t[]
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 J=
ira
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/>
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 servic=
e
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 Gen=
Too
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 Gen=
Too
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_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
