Sounds plausible. I'd even like to see those warning messages on =
initialization in Spring 1.1, to highlight the deprecation - noone will =
notice deprecated bean properties else. And we need to be consistent: =
Let's find all "interceptor" naming and replace them with "advice" =
naming.
=20
BTW, TransactionProxyFactoryBean's "preInterceptors" and =
"postInterceptors" also accept Advisors, so "preAdvices" and =
"postAdvices" wouldn't be entirely correct either and would still have =
to accept an Object array. Is there a common term that covers both =
direct advices and advisors with conditional advices?
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: So 18.07.2004 14:10
An: spr...@li...
Betreff: Re: [Springframework-developer] "advice" vs "interceptor" =
properties
I'd rather have the use of the word advice if it takes advice. If it
says interceptor, people are going to think it takes just an =
interceptor.
Maybe we could handle the deprecation in two stages though. For 1.1 the
old methods are deprecated. For 1.2 the old methods are deprecated, and
also log a warning in the setter. Hopefully people look in their logs...
For 1.3 they actually go away.
Colin
j=FCrgen h=F6ller [werk3AT] wrote:
>In our current 1.1 codebase, we have an inconsistency regarding the use =
of "advice" and "interceptor" in bean property names: AdvisedSupport has =
a deprecated "addInterceptor" method now (without hinting at the =
preferred method in javadoc, BTW), because of the preferred "addAdvice" =
method.
>
>While Advice is more general (being a super interface of Interceptor), =
a number of other properties use "interceptor" in the name while =
accepting Object, for example TransactionProxyFactoryBean's =
"preInterceptors" and "postInterceptors", and also ProxyFactoryBean's =
"interceptorNames".
>
>We need to make this consistent. We could either keep the "interceptor" =
property names, allowing all kinds of Advices there: This would mean =
that AdvisedSupport's "addInterceptor" should not be deprecated. Or we =
could use "advice" in all those names: That would mean renaming =
(respectively deprecating) quite popular properties.
>
>When renaming bean properties, we need to consider that driving those =
properties via XML bean definitions will not show any deprecation =
warnings, just programmatic usage will. Consequently, many people will =
not notice such deprecations, first discovering them when we remove the =
deprecated bean properties...
>
>Thoughts? Suggestions?
>
>Juergen
>=20
>
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
