Menu
▾
▴
Re: [Springframework-developer] Final preparations for 1.1 RC1
|
From: Rod J. <rod...@in...> - 2004-07-19 12:30:16
|
I forgot to say, as I said to Juergen in our chat, that I want to reserve "aspect" for a high-level construct if necessary: possibly multiple Advis= ors working together to address a single aspect. I vote to keep addInterceptor deprecated on Advised/dvisedSupport. I thin= k this gives an education and migration path. Moving it down might break code--e.g. people cast to Advised and addInterceptor() doesn't work any more. That would have broken some of my test code. Rgds Rod ----- Original Message ----- From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Monday, July 19, 2004 1:17 PM Subject: Re: [Springframework-developer] Final preparations for 1.1 RC1 As we just discussed on IM, I tend to agree :-) There is no convincing te= rm 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 convenienc= e, rather than deprecating it in AdvisedSupport. Essentially, we need to fin= d 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 woul= d 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 c= an add ThrowsAdvice as well as interceptors--but it doesn't support adding Advisors. The "interceptorNames" style properties support Advices (includ= ing 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 t= he term "aspect" if also covering advisors: in ProxyFactory, ProxyFactoryBea= n, 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 thi= nk would be worth it. Thoughts? Finally, regarding form simplification macros, i.e. Struts-style HTML inp= ut 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 ------------------------------------------------------- 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 |
