Re: [Springframework-developer] Final preparations for 1.1 RC1

[Colin S. <col...@ex...>]

I personally don't like using the name interceptor for something that 
can be more than an interceptor. It can confuse people, and/or make them 
think it can't do something it can. On the other hand, given the legacy 
issues and lack of any clear solution, I agree that it's probably best 
to leave it as-is, maybe with more emphasis in the JavaDocs and regular 
documentation...

jürgen höller [werk3AT] wrote:

>As we just discussed on IM, I tend to agree :-) There is no convincing term for bean properties - "aspect" is not really perfect either -, so it's probably best to keep "interceptor".
>
>The remaining question is: Do we need to deprecate "addInterceptor" on AdvisedSupport? Quite a lot of people might just have a superficial grip on AOP at the MethodInterceptor level: For those, "addInterceptor" might be more natural, as they're not aware of the term "advice" or the superinterface Advice in the first place.
>
>We could also move "addInterceptor" down to ProxyFactory, as a convenience, rather than deprecating it in AdvisedSupport. Essentially, we need to find a good compromise, making stuff as easy to comprehend as possible from the user's perspective. Allowing users to just think about "interceptors" for working with MethodInterceptors might be part of that.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Rod Johnson
>Sent: Monday, July 19, 2004 1:40 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Final preparations for 1.1 RC1
>
>
>I'm not convinced that it's worth changing, especially as the change would
>obviously have quite an impact in the long term. The present use of
>"interceptor" in properties--e.g. "interceptorNames", is a bit misleading,
>as Interceptors, other Advices or Advisors can be used. However, such
>methods are *not* parallel to the addInterceptor/addAdvice methods on
>AdvisedSupport. addAdvice is more general than addInterceptor--e.g. you can
>add ThrowsAdvice as well as interceptors--but it doesn't support adding
>Advisors. The "interceptorNames" style properties support Advices (including
>Interceptors) and Advisors.
>
>It's hard to find a convincing name for the latter combination. It's
>essentially Object-typed. Thus the "interceptor" concept, while an
>implementation feature rather than AOP essential, seems as good as any.
>
>Rgds
>Rod
>
>----- Original Message -----
>From: "jürgen höller [werk3AT]" <jue...@we...>
>To: <spr...@li...>
>Sent: Monday, July 19, 2004 11:36 AM
>Subject: Re: [Springframework-developer] Final preparations for 1.1 RC1
>
>
>I forgot:
>
>- We need to get "advice" vs "interceptor" naming right, possibly using the
>term "aspect" if also covering advisors: in ProxyFactory, ProxyFactoryBean,
>TransactionProxyFactoryBean.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag von
>jürgen höller [werk3AT]
>Gesendet: Mo 19.07.2004 11:29
>An: spr...@li...
>Betreff: [Springframework-developer] Final preparations for 1.1 RC1
>
>
>
>Everybody,
>
>Seems like we're finally ready for 1.1 RC1, already with full 1.1 scope:
>
>- Mark has provided a refined version of the JMS support
>- Thomas has already added support for JDBC-generated keys
>- Darren has committed bind support for Velocity and FreeMarker
>- Seth has contributed some tag refinements for JSP views.
>
>The remaining tasks that I see are:
>
>- We need to adapt the source code formatting of the JMS support: I still
>see nasty empty lines after each code line on Windows: maybe Unix/Windows
>line feed differences?
>
>- I'd like to review the source code of the final version of JMS support.
>Just about polishing and javadoc, as always before a release :-)
>
>- Thomas is already working on using a single API approach for
>JDBC-generated keys, including moving the classes to a different package.
>
>- I'd like to move BindStatus and the new BindStatusHelper class from
>servlet.tags to servlet.support. JSPs using the BindTag should still work,
>provided that they get freshly compiled. Any objections to this?
>
>- I'd like to refine resource loading in VelocityFormView and
>FreeMarkerFormView: This is not entirely clean when combined with custom
>resource paths yet, from a superficial glance.
>
>- We need to add Seth's NestedPathTag and include his BindTag refinements.
>I'll do this myself during the course of the week.
>
>All things considered, this means a release by the end of the week: Any
>earlier date would require dropping one of those tasks, which I don't think
>would be worth it. Thoughts?
>
>Finally, regarding form simplification macros, i.e. Struts-style HTML input
>tag wrappers: Do we already have something here, for either JSP 2.0,
>Velocity or FreeMarker?
>
>Juergen
>  
>