Menu
▾
▴
Re: [Springframework-developer] Final preparations for 1.1 RC1
|
From: <jue...@we...> - 2004-07-19 12:15:36
|
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=FCrgen h=F6ller [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=FCrgen h=F6ller [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 ------------------------------------------------------- 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_idG21&alloc_id=10040&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- 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_idG21&alloc_id=10040&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- 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_idG21&alloc_id=10040&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
