Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-07-19 10:35:29
|
I forgot: =20 - We need to get "advice" vs "interceptor" naming right, possibly using = the term "aspect" if also covering advisors: in ProxyFactory, = ProxyFactoryBean, TransactionProxyFactoryBean. =20 Juergen =20 ________________________________ 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 |
|
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 |
|
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 |
|
From: Colin S. <col...@ex...> - 2004-07-19 14:04:47
|
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 > > |
|
From: <jue...@we...> - 2004-07-19 12:20:35
|
> I meant to raise this when I generalised the behaviour of them but it > slipped my mind. They should be moved to a non-tag specific package = now. OK, I'll move them to "servlet.support" tonight, alongside = RequestContext. I'll also check whether Tomcat and Resin recompile JSPs = if a TLD has changed; else, the working directory needs to be scratched = to force a recompile. > VelocityConfigurer (and respective FreeMarkerConfigurer) ensure a > SpringResourceLoader is available for use, possibly in addition to any > other resource loading strategy in the case of FreeMarker. Does this = not > cover requirements? I'm a little unclear on what's missing here.. I've gone through the code Tuesday night last week; I need to recheck = what I actually noticed there. I'll do so when I'm back at home. (I'm = currently at the werk3 office.) > I'd intended contacting Seth again to catch up on this and ensure a > consistent approach for the three technologies. My feeling is that it > should be fairly quick to add given the basic framework code is OK for > resource loading, but I've not really looked closely at it yet. No problem - let's add those for 1.1 final or even 1.1.1, whenever they = are ready. Do you in principle envisage copying Velocity/FreeMarker = macros to the user's resource loader path, to allow for easy = customization? Juergne |
|
From: Darren D. <da...@da...> - 2004-07-19 14:29:33
|
> No problem - let's add those for 1.1 final or even 1.1.1, whenever they
> are ready. Do you in principle envisage copying Velocity/FreeMarker mac=
ros
> to the user's resource loader path, to allow for easy customization?
it hadn't been my original intention, but then again I havn't really spen=
t
time thinking about it either :) Originally I'd expected to make all the
macros standard but parameterisable, building on the binding ability just
added. The html output would work without modification and a parameter
could be passed to the macro to customize the html. Something like;
#macro (springTextInput $htmlAttributes)
## assume bind already performed
<input
type=3D"text"
name=3D"${status.expression}"
value=3D"$!status.value"
$htmlAttributes
#if ($xhtmlCompliant) "/>" #else ">" #end
#end
The following VTL;
#springTextInput('style=3D"border: 1px solid silver" maxlength=3D"30"')
would output (if binding to a 'name' field);
<input
type=3D"text"
name=3D"name"
value=3D"Darren Davison"
style=3D"border: 1px solid silver" maxlength=3D"30"
>
Further conveniences like allowing default htmlAttributes (defined by the
user, not Spring) would clearly be simple to implement too.
The Struts guys have gone to the trouble of duplicating almost all of the
HTML 4.0.1 attribute set in their custom tags, which sounds to me like an
awful lot of copy/paste just to get a nice IDE integration!
If the convenience macros fail to meet some unusual requirement in the
html form, the user can always fall back to using the springBind macro an=
d
completely handcoding individual fields - or the entire html form - as
required (like you would have to do now with what's in CVS).
I'm a bit unsure how copying macro definitions to app resource locations
works in practice: presumably we can only do this once to avoid
overwriting customizations made by the user? How would we manage updates
made to the macros inside spring.jar in future releases? It just sounds =
a
bit kludgy to me, but I'm probably missing an obvious benefit.
In my experience, the standard macros briefly outlined would be more
useful - I guess if a user really wanted to completely customize the
macro set, s/he could manually take a copy from the Spring source and do
so, but I'm definitely open to opinions here.
Regards,
--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm
|
|
From: Seth L. <set...@gm...> - 2004-07-19 18:28:30
|
> I'm a bit unsure how copying macro definitions to app resource locations > works in practice: presumably we can only do this once to avoid > overwriting customizations made by the user? How would we manage updates > made to the macros inside spring.jar in future releases? It just sounds a > bit kludgy to me, but I'm probably missing an obvious benefit. > > In my experience, the standard macros briefly outlined would be more > useful - I guess if a user really wanted to completely customize the > macro set, s/he could manually take a copy from the Spring source and do > so, but I'm definitely open to opinions here. Some guidance here would be helpful. I'm also unsure how this is supposed to work. I agree with Darren that if the user needs something unconventional, it should be easy to generate their own tags. These convenience tags are so simple and so straight forward that they should work for most people (especially if they allow XHTML or HTML rendering). Now that the nestedPath tag exists, I can submit our JSP 2.0 tagfiles for the form elements. I will also try to submit tag classes, for those not using JSP 2.0. Again, since the BindTag still exists, we're not forcing people to use these tags just to get at variables. Seth |
|
From: <jue...@we...> - 2004-07-19 14:57:22
|
I've just checked that too: Actually, the JMS source files use 0D 0D 0A = - i.e. double carriage return. I've just converted them to 0D 0A, just = like our other files have. I'll commit them in a second. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Darren Davison Sent: Monday, July 19, 2004 4:46 PM To: spr...@li... Subject: RE: [Springframework-developer] Final preparations for 1.1 RC1 > Hi, > >> - 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'm not seeing this, if you show me how you are detecting this I can = clean > it up. The JMS files are using windows EOL markers (0A 0D) the other files use the Unix convention (0A). You can verify by opening the files with any binary viewer (TextPad on Windows will do it, any Hex viewer on = Unix/Linux will show it too). I thought the CVS server should automatically = convert to the Unix format..? I downloaded AbstractJmsTemplate.java and checked it with both TextPad = on 'doze and the nano editor (pico clone) on Linux; they formatted OK on = both for me. Emacs would probably show the JMS source as having ^M at the = end of each line. --=20 Darren Davison Public Key: http://www.davison.uk.net/pages/key.htm ------------------------------------------------------- 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 |
|
From: Darren D. <da...@da...> - 2004-07-19 15:18:26
|
> I've just checked that too: Actually, the JMS source files use 0D 0D 0A=
-
> i.e. double carriage return. I've just converted them to 0D 0A, just li=
ke
> our other files have. I'll commit them in a second.
hmm. That's odd - here's the first binary word from the
AbstractJmsTemplate file as I see it here (windows line-feed sequence
underlined):
2F 2A 0D 0A 20 2A 20 43 6F 70 79 72 69 67 68 74
^^^^^
which equates to the fragment:
/*
* Copyright
Which editor are you using as it sounds like the problem may be there? I=
s
it perhaps assuming a Unix file format without actually checking it? If
so, it would automatically add 0D before each 0A it encountered - that
would certainly explain your 0D 0D 0A sequence!
--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm
|
|
From: <tho...@tr...> - 2004-07-19 15:32:27
|
We had the same problem way back when we moved the codebase from com.interface12 to org.springframework. That time it was because I moved Rod's Windows files to a Linux box and did create the new project with these files without stripping the '0D' character. The CVS client built into Eclipse seemed to mask this problem but anybody using a regular CVS client did notice it. Thomas Quoting "jürgen höller [werk3AT]" <jue...@we...>: > I've just checked that too: Actually, the JMS source files use 0D 0D 0A = > - i.e. double carriage return. I've just converted them to 0D 0A, just = > like our other files have. I'll commit them in a second. > > Juergen > > > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...]On Behalf > Of Darren Davison > Sent: Monday, July 19, 2004 4:46 PM > To: spr...@li... > Subject: RE: [Springframework-developer] Final preparations for 1.1 RC1 > > > > > Hi, > > > >> - 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'm not seeing this, if you show me how you are detecting this I can = > clean > > it up. > > The JMS files are using windows EOL markers (0A 0D) the other files use > the Unix convention (0A). You can verify by opening the files with any > binary viewer (TextPad on Windows will do it, any Hex viewer on = > Unix/Linux > will show it too). I thought the CVS server should automatically = > convert > to the Unix format..? > > I downloaded AbstractJmsTemplate.java and checked it with both TextPad = > on > 'doze and the nano editor (pico clone) on Linux; they formatted OK on = > both > for me. Emacs would probably show the JMS source as having ^M at the = > end > of each line. > > > --=20 > Darren Davison > Public Key: http://www.davison.uk.net/pages/key.htm > > > > > ------------------------------------------------------- > 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_id=4721&alloc_id=10040&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: <jue...@we...> - 2004-07-19 15:36:15
|
IntelliJ IDEA shows those extra lines. I checked the actual file =
contents with UltraEdit's hex editor: This clearly indicates 0D 0D 0A. =
I've told UltraEdit to convert to DOS format to get rid of those.
I've also applied my IDEA code style template for Spring and polished =
some javadocs, so I guess I'll simply commit the files as they are now. =
Let's check whether everyone sees appropriate line feeds then.
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Darren Davison
Sent: Monday, July 19, 2004 5:18 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Final preparations for 1.1 RC1
> I've just checked that too: Actually, the JMS source files use 0D 0D =
0A -
> i.e. double carriage return. I've just converted them to 0D 0A, just =
like
> our other files have. I'll commit them in a second.
hmm. That's odd - here's the first binary word from the
AbstractJmsTemplate file as I see it here (windows line-feed sequence
underlined):
2F 2A 0D 0A 20 2A 20 43 6F 70 79 72 69 67 68 74
^^^^^
which equates to the fragment:
/*
* Copyright
Which editor are you using as it sounds like the problem may be there? =
Is
it perhaps assuming a Unix file format without actually checking it? If
so, it would automatically add 0D before each 0A it encountered - that
would certainly explain your 0D 0D 0A sequence!
--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm
-------------------------------------------------------
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
|
|
From: Alef A. <al...@jt...> - 2004-07-20 00:33:25
|
Our test coverage is about 70% right now (we used to be close to 80% = just before the 1.0 release) and although some classes are pretty hard = to test (probably only using integration tests) there is still room for = improvement IMHO. I just spent an hour on a couple of tests and = increased coverage with about 0.9%. It's tedious, I know, but definitely = worth it. =20 I'll try to address some more areas where coverage is low, but if = anybody has some spare time, it would be great if you could have a look = as well... =20 I'll also try to get coverage reports up-and-running with the = integration tests included if I have time. =20 Alef ________________________________ From: spr...@li... on behalf of = j=FCrgen h=F6ller [werk3AT] Sent: Mon 7/19/2004 11:45 AM To: spr...@li... Subject: [Springframework-developer] Final preparations for 1.1 RC1 Everybody,=20 =20 Seems like we're finally ready for 1.1 RC1, already with full 1.1 scope: = =20 - Mark has provided a refined version of the JMS support=20 - Thomas has already added support for JDBC-generated keys=20 - Darren has committed bind support for Velocity and FreeMarker=20 - Seth has contributed some tag refinements for JSP views.=20 =20 The remaining tasks that I see are:=20 =20 - 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=20 =20 -------------------------------------------------------=20 This SF.Net email is sponsored by BEA Weblogic Workshop=20 FREE Java Enterprise J2EE developer tools!=20 Get your free copy of BEA WebLogic Workshop 8.1 today.=20 http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick=20 _______________________________________________=20 Springframework-developer mailing list=20 Spr...@li...=20 https://lists.sourceforge.net/lists/listinfo/springframework-developer=20 |
|
From: Rod J. <rod...@in...> - 2004-07-20 07:56:50
|
Alef Thanks for that. It's hard work, but it is important. I would like to see us back up around 80%, but of course the integration tests make things hard. Clover reports are already produced by Luke's Maven script on monkeymachi= ne, so I just use those. A couple of techniques we could consider to raise coverage: - there are now mock libraries that use CGLIB to mock classes, not just interfaces. Should make it easier to work with some of those nasty APIs - I did consider trying to use AspectJ at one point, although that would complicate the build I vote that we try an additional mocking strategy and see where that make= s things easier. Rgds Rod ----- Original Message ----- From: "Alef Arendsen" <al...@jt...> To: <spr...@li...> Sent: Tuesday, July 20, 2004 1:33 AM Subject: RE: [Springframework-developer] Final preparations for 1.1 RC1 Our test coverage is about 70% right now (we used to be close to 80% just before the 1.0 release) and although some classes are pretty hard to test (probably only using integration tests) there is still room for improveme= nt IMHO. I just spent an hour on a couple of tests and increased coverage wi= th about 0.9%. It's tedious, I know, but definitely worth it. I'll try to address some more areas where coverage is low, but if anybody has some spare time, it would be great if you could have a look as well... I'll also try to get coverage reports up-and-running with the integration tests included if I have time. Alef ________________________________ From: spr...@li... on behalf of j=FCrgen h=F6ller [werk3AT] Sent: Mon 7/19/2004 11:45 AM To: spr...@li... Subject: [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 |
|
From: Darren D. <da...@da...> - 2004-07-20 08:12:56
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 20 July 2004 08:56, Rod Johnson wrote: > Alef > > Thanks for that. It's hard work, but it is important. > > I would like to see us back up around 80%, but of course the integration > tests make things hard. > > Clover reports are already produced by Luke's Maven script on > monkeymachine, so I just use those. > > A couple of techniques we could consider to raise coverage: > - there are now mock libraries that use CGLIB to mock classes, not just > interfaces. Should make it easier to work with some of those nasty APIs > - I did consider trying to use AspectJ at one point, although that would > complicate the build > > I vote that we try an additional mocking strategy and see where that > makes things easier. what about Groovy for testing. There was a post a few months ago pointing= =20 to a presentation someone did showing this. It would be a lot quicker to write some (not all) of the future tests in=20 Groovy I think, but I don't know how we'd measure it.. does Clover work=20 with Groovy classes? =2D --=20 Darren Davison Public Key: http://www.davison.uk.net/pages/key.htm =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/NQDKLMLAN01aw0RAsPaAJ9zhG+StCCS4Q0pNrLPZsb6AKAwsQCghaWz K6456ang1K3N9z3qy2dDBAc=3D =3D1KAH =2D----END PGP SIGNATURE----- |
|
From: Rod J. <rod...@in...> - 2004-07-20 08:26:45
|
Alef, Darren Do either of you have time to experiment with the Groovy option? I think this is a very good idea. I would have thought Clover would work just fine in this scenario, as it instruments the source, not the tests... R ----- Original Message ----- From: "Darren Davison" <da...@da...> To: <spr...@li...> Sent: Tuesday, July 20, 2004 9:12 AM Subject: Re: [Springframework-developer] Final preparations for 1.1 RC1 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 20 July 2004 08:56, Rod Johnson wrote: > Alef > > Thanks for that. It's hard work, but it is important. > > I would like to see us back up around 80%, but of course the integration > tests make things hard. > > Clover reports are already produced by Luke's Maven script on > monkeymachine, so I just use those. > > A couple of techniques we could consider to raise coverage: > - there are now mock libraries that use CGLIB to mock classes, not just > interfaces. Should make it easier to work with some of those nasty APIs > - I did consider trying to use AspectJ at one point, although that would > complicate the build > > I vote that we try an additional mocking strategy and see where that > makes things easier. what about Groovy for testing. There was a post a few months ago pointing to a presentation someone did showing this. It would be a lot quicker to write some (not all) of the future tests in Groovy I think, but I don't know how we'd measure it.. does Clover work with Groovy classes? - -- Darren Davison Public Key: http://www.davison.uk.net/pages/key.htm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/NQDKLMLAN01aw0RAsPaAJ9zhG+StCCS4Q0pNrLPZsb6AKAwsQCghaWz K6456ang1K3N9z3qy2dDBAc= =1KAH -----END PGP SIGNATURE----- ------------------------------------------------------- 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_id040&op=ick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Darren D. <da...@da...> - 2004-07-20 09:29:21
|
Rod Johnson wrote: > Alef, Darren > > Do either of you have time to experiment with the Groovy option? > > I think this is a very good idea. I should be able to have a go at getting the Groovy support working today - I've a little time available. I'll see if I can knock up or convert one or two simple tests as an example. > I would have thought Clover would work just fine in this scenario, as it > instruments the source, not the tests... tut, silly me :) -- Darren Davison Public Key: http://www.davison.uk.net/pages/key.htm |
|
From: Dmitriy K. <dko...@ru...> - 2004-07-20 12:49:38
|
Rod Johnson wrote: >A couple of techniques we could consider to raise coverage: >- there are now mock libraries that use CGLIB to mock classes, not just >interfaces. Should make it easier to work with some of those nasty APIs > > EasyMock 1.1 now has an extension for mocking up classes (via CGLIB): http://www.easymock.org/Downloads.html Dmitriy. |
|
From: Colin S. <col...@ex...> - 2004-07-20 13:14:16
|
Dmitriy Kopylenko wrote: > Rod Johnson wrote: > >> A couple of techniques we could consider to raise coverage: >> - there are now mock libraries that use CGLIB to mock classes, not just >> interfaces. Should make it easier to work with some of those nasty APIs >> >> > EasyMock 1.1 now has an extension for mocking up classes (via CGLIB): > http://www.easymock.org/Downloads.html > > Dmitriy. yes, I checked this in a couple of months ago... Colin |
|
From: <jue...@we...> - 2004-07-20 10:21:33
|
OK, let's keep "addInterceptor" deprecated, adding a proper javadoc = comment there. Let's also keep the "interceptorNames" / = "preInterceptors" / "postInterceptors" terminology then, allowing for = both Advices and Advisors. Which essentially just means adding javadoc to AdvisedSupport's = "addInterceptor" method, and maybe refining the javadoc of the = "interceptor" properties :-) Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Rod Johnson Sent: Monday, July 19, 2004 2:30 PM To: spr...@li... Subject: Re: [Springframework-developer] Final preparations for 1.1 RC1 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 = Advisors working together to address a single aspect. I vote to keep addInterceptor deprecated on Advised/dvisedSupport. I = think 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 = 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 ------------------------------------------------------- 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 |
|
From: Alef A. <al...@jt...> - 2004-07-20 13:25:58
|
Yes, it's already in the Eclipse project, so if you feel like writing tests, you can use it ;-). Alef =20 > -----Original Message----- > From: spr...@li...=20 > [mailto:spr...@li...] > On Behalf Of Dmitriy Kopylenko > Sent: Tuesday, July 20, 2004 3:01 PM > To: spr...@li... > Subject: Re: [Springframework-developer] Final preparations=20 > for 1.1 RC1 >=20 > Rod Johnson wrote: >=20 > >A couple of techniques we could consider to raise coverage: > >- there are now mock libraries that use CGLIB to mock=20 > classes, not just=20 > >interfaces. Should make it easier to work with some of those=20 > nasty APIs > > =20 > > > EasyMock 1.1 now has an extension for mocking up classes (via CGLIB):=20 > http://www.easymock.org/Downloads.html >=20 > Dmitriy. >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop FREE=20 > 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 >=20 >=20 >=20 >=20 |
|
From: Dmitriy K. <dko...@ru...> - 2004-07-20 13:54:17
|
Sure thing ;-) It's a dirty job, but somebody has got to do it ;-) D. Alef Arendsen wrote: >Yes, it's already in the Eclipse project, so if you feel like writing >tests, you can use it ;-). > >Alef > > > > >>-----Original Message----- >>From: spr...@li... >>[mailto:spr...@li...] >> On Behalf Of Dmitriy Kopylenko >>Sent: Tuesday, July 20, 2004 3:01 PM >>To: spr...@li... >>Subject: Re: [Springframework-developer] Final preparations >>for 1.1 RC1 >> >>Rod Johnson wrote: >> >> >> >>>A couple of techniques we could consider to raise coverage: >>>- there are now mock libraries that use CGLIB to mock >>> >>> >>classes, not just >> >> >>>interfaces. Should make it easier to work with some of those >>> >>> >>nasty APIs >> >> >>> >>> >>> >>> >>EasyMock 1.1 now has an extension for mocking up classes (via CGLIB): >>http://www.easymock.org/Downloads.html >> >>Dmitriy. >> >> >>------------------------------------------------------- >>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=4721&alloc_id=10040&op=click >>_______________________________________________ >>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_id040&op=click >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: <jue...@we...> - 2004-07-22 15:42:34
|
Darren, =20 I've just moved BindStatus and reworked the configuration part a bit. = I've also removed BindStatusHelper and moved its createBindStatus = methods to the RequestContext class itself. VelocityFormView and = FreeMarkerFormView simply expose a RequestContext instance under the = name "bindStatusRequestContext" now, accessed by the macros in spring.vm = respectively spring.ftl. =20 Regarding template loading, I've refined this a bit too: =20 * FreeMarkerConfigurer always registers an additional = ClassTemplateLoader now, being able to load macros from the = web.servlet.view.freemarker package. This means that a FreeMarker = template can simply import "spring.ftl" now, rather than the lengthy = "org/springframework/web/servlet/view/freemarker/spring.ftl". =20 * VelocityConfigurer always registers an additional = ClasspathResourceLoader with the name "springFormMacro", plus the = library "spring.vm" in the web.servlet.view.velocity package. = Previously, the SpringResourceLoader was in potential conflict with a = SpringResourceLoader from VelocityEngineFactory of the same name. Now, = this should work with any kind and any number of primary resource = loaders, as long as none is called "springFormMacro". =20 What I'm still wondering is whether we need the subclasses = VelocityFormView and FreeMarkerFormView at all: They just expose a = RequestContext instance under a special name now. We could easily move = that logic into VelocityView respectively FreeMarkerView itself, driven = by a "enableBindMacros" flag. =20 If the "enableBindMacros" flag existed on VelocityViewResolver and = FreeMarkerViewResolver (to be created) too, it could be easily driven = for all views. And there wouldn't be a need to override the viewClass = property in that case. I'd prefer this over using view subclasses, as = far as I can see. =20 What do you think? =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Darren Davison Gesendet: Mo 19.07.2004 12:33 An: spr...@li... Betreff: Re: [Springframework-developer] Final preparations for 1.1 RC1 > - 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 meant to raise this when I generalised the behaviour of them but it slipped my mind. They should be moved to a non-tag specific package = now. > - 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. VelocityConfigurer (and respective FreeMarkerConfigurer) ensure a SpringResourceLoader is available for use, possibly in addition to any other resource loading strategy in the case of FreeMarker. Does this = not cover requirements? I'm a little unclear on what's missing here.. > 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? not from my side - personal events have overtaken me a little recently. I'd intended contacting Seth again to catch up on this and ensure a consistent approach for the three technologies. My feeling is that it should be fairly quick to add given the basic framework code is OK for resource loading, but I've not really looked closely at it yet. Regards, -- Darren Davison Public Key: http://www.davison.uk.net/pages/key.htm ------------------------------------------------------- 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 |
|
From: Matt R. <li...@ra...> - 2004-07-24 00:13:49
|
> > * FreeMarkerConfigurer always registers an additional > ClassTemplateLoader now, being able to load macros from the > web.servlet.view.freemarker package. This means that a > FreeMarker template can simply import "spring.ftl" now, > rather than the lengthy > "org/springframework/web/servlet/view/freemarker/spring.ftl". FYI... This doesn't work: <#import "spring.ftl" as spring /> But this does: <#import "/spring.ftl" as spring /> Just thought it should be documented. Matt |
|
From: Darren D. <da...@da...> - 2004-07-24 08:10:58
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 24 July 2004 01:13, Matt Raible wrote: > FYI... > > This doesn't work: > > <#import "spring.ftl" as spring /> hmm.. it works ok for me. > But this does: > > <#import "/spring.ftl" as spring /> > > Just thought it should be documented. =2D --=20 Darren Davison Public Key: http://www.davison.uk.net/pages/key.htm =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBAhmMKLMLAN01aw0RAuNlAKCJkf8+pnwIP4Bt31VwninHric7jgCeIA7v w/4rPbU0TC06WZLKkIzVczw=3D =3DWfZk =2D----END PGP SIGNATURE----- |
|
From: <jue...@we...> - 2004-07-22 15:47:23
|
> I'm a bit unsure how copying macro definitions to app resource = locations > works in practice: presumably we can only do this once to avoid > overwriting customizations made by the user? How would we manage = updates > made to the macros inside spring.jar in future releases? It just = sounds a > bit kludgy to me, but I'm probably missing an obvious benefit. > In my experience, the standard macros briefly outlined would be more > useful - I guess if a user really wanted to completely customize the > macro set, s/he could manually take a copy from the Spring source and = do > so, but I'm definitely open to opinions here. On reflection, I tend to agree: Let's provide such default macros in = spring.vm/ftl, even if containing HTML code. An application developer = can always override through own macro libraries, potentially copying and = modifying from the spring.vm/ftl files.=20 =20 I've added spring.vm/ftl to the build script, to copy them into the dist = directory, alongside spring.tld and spring-beans.dtd. All of those are = documented quite nicely in the source files, so should be easily = available for review, even if contained in spring.jar anyway. =20 Juergen |
