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ürgen höller [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
>
>
|
