springframework-developer

[Springframework-developer] Some code remarks

[Pieter C. <pie...@on...>]

Hi,

I browsed a bit through the Spring source code and have some remarks 
about possible code improvements.

1) JavaScriptUtils can be replaced with 
StringEscapeUtils.escapeJavaScript(), which is in commons-lang 2.0 
(apparently the current commons-lang version is an old one where this 
class isn't included)

2) HtmlUtils can be replaced with StringEscapeUtils.escapeHtml()

3) The class javadoc of org.springframework.core.Constants mentions 
asInt(), which doesn't exist

4) RegexpMethodPointcutAdvisor uses perl5=true by default.  Isn't it 
possible to use
private boolean perl5 = JdkVersion.getMajorJavaVersion()<JdkVersion.JAVA_14;
This doesn't require the perl5=false property in all advisors if you're 
running jdk 1.4

Greetings,

Pieter

[Springframework-developer] Re: Some code remarks

[Yannick M. <yan...@fa...>]

Pieter Coucke <pieter.coucke <at> onthoo.com> writes:
> I browsed a bit through the Spring source code and have some remarks 
> about possible code improvements.
> 
> 1) JavaScriptUtils can be replaced with 
> StringEscapeUtils.escapeJavaScript(), which is in commons-lang 2.0 
> (apparently the current commons-lang version is an old one where this 
> class isn't included)
> 
> 2) HtmlUtils can be replaced with StringEscapeUtils.escapeHtml()

Please read the following: http://tinyurl.com/66lny

Right now, Spring is not dependent on commons-lang, and I certainly hope it will
stay that way.

*Dependencies are EVIL*

I don't think any spring user has any desire to have to include 10mb of
commons-this, commons-that just to run their hello world spring application (
see cocoon for one of the scariest examples )

Re: [Springframework-developer] Re: Some code remarks

[Pieter C. <pie...@on...>]

Commons-lang is already inside the Spring distribution, so I don't see th=
e
problem there.

I agree that the commons-whatever packaging is not ideal however, most
projects that decide to use commons, need almost all of the common (pun
intended) jars.  One commons.jar may be a solution, but is probably not
possible since every component has a different release schedule/version.

Anyway, a tool like maven downloads new releases automatically, and
building wars or ears also is usually done in scripts, so it's only a
matter of configuring dependencies once.

If you don't need the JavaScriptUtils class, you can also remove the
dependency on commons-lang to save that extra bit of disk space, it reall=
y
think it will make a difference on current 250 GB disks.

Following your blog, we should write everything ourselves (for
componentless support) AND write code that uses a component.  Seems more
work than simply maintaining a dependency to me... Especially something
like HTML escaping (did you have a look at the Spring implementation) is
very likely to contain errors or omissions and shouldn't (in my opinion o=
f
course) be rewritten if a well-maintained solution is already available.

just my two eurocents (a bit more worth than dollarcents now, hehe)

Pieter



Yannick Menager said:
> Pieter Coucke <pieter.coucke <at> onthoo.com> writes:
>> I browsed a bit through the Spring source code and have some remarks
>> about possible code improvements.
>>
>> 1) JavaScriptUtils can be replaced with
>> StringEscapeUtils.escapeJavaScript(), which is in commons-lang 2.0
>> (apparently the current commons-lang version is an old one where this
>> class isn't included)
>>
>> 2) HtmlUtils can be replaced with StringEscapeUtils.escapeHtml()
>
> Please read the following: http://tinyurl.com/66lny
>
> Right now, Spring is not dependent on commons-lang, and I certainly hop=
e
> it will
> stay that way.
>
> *Dependencies are EVIL*
>
> I don't think any spring user has any desire to have to include 10mb of
> commons-this, commons-that just to run their hello world spring
> application (
> see cocoon for one of the scariest examples )
>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Re: Some code remarks

[Juergen H. <ju...@in...>]

Pierre,

I agree with Yannick that it is not desirable to depend on Commons Lang.
Spring's core currently has a minimal set of dependencies and just relies on
third-party libraries for full-blown optional features (like proxying full
target via CGLIB). I prefer to keep it that way, at the expense of having
some helper classes in Spring that duplicate Commons Lang functionality.

It is true that Commons Lang is already included in the Spring distribution,
but the only reason for this is to run JPetStore's Struts web tier (as
stated in the lib/readme.txt file in the distribution). Commons Lang is just
a Struts dependency here, not a Spring dependency.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Pieter Coucke
Sent: Tuesday, January 18, 2005 12:39 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: Some code remarks


Commons-lang is already inside the Spring distribution, so I don't see the
problem there.

I agree that the commons-whatever packaging is not ideal however, most
projects that decide to use commons, need almost all of the common (pun
intended) jars.  One commons.jar may be a solution, but is probably not
possible since every component has a different release schedule/version.

Anyway, a tool like maven downloads new releases automatically, and
building wars or ears also is usually done in scripts, so it's only a
matter of configuring dependencies once.

If you don't need the JavaScriptUtils class, you can also remove the
dependency on commons-lang to save that extra bit of disk space, it really
think it will make a difference on current 250 GB disks.

Following your blog, we should write everything ourselves (for
componentless support) AND write code that uses a component.  Seems more
work than simply maintaining a dependency to me... Especially something
like HTML escaping (did you have a look at the Spring implementation) is
very likely to contain errors or omissions and shouldn't (in my opinion of
course) be rewritten if a well-maintained solution is already available.

just my two eurocents (a bit more worth than dollarcents now, hehe)

Pieter



Yannick Menager said:
> Pieter Coucke <pieter.coucke <at> onthoo.com> writes:
>> I browsed a bit through the Spring source code and have some remarks
>> about possible code improvements.
>>
>> 1) JavaScriptUtils can be replaced with
>> StringEscapeUtils.escapeJavaScript(), which is in commons-lang 2.0
>> (apparently the current commons-lang version is an old one where this
>> class isn't included)
>>
>> 2) HtmlUtils can be replaced with StringEscapeUtils.escapeHtml()
>
> Please read the following: http://tinyurl.com/66lny
>
> Right now, Spring is not dependent on commons-lang, and I certainly hope
> it will
> stay that way.
>
> *Dependencies are EVIL*
>
> I don't think any spring user has any desire to have to include 10mb of
> commons-this, commons-that just to run their hello world spring
> application (
> see cocoon for one of the scariest examples )
>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: Some code remarks

[Matt R. <li...@ra...>]

Just FYI... commons-lang is no longer a Struts dependency (I believe as 
of 1.2.4) - so if you upgrade, you could get rid of it altogether!

Matt

On Jan 19, 2005, at 10:28 AM, Juergen Hoeller wrote:

> Pierre,
>
> I agree with Yannick that it is not desirable to depend on Commons 
> Lang.
> Spring's core currently has a minimal set of dependencies and just 
> relies on
> third-party libraries for full-blown optional features (like proxying 
> full
> target via CGLIB). I prefer to keep it that way, at the expense of 
> having
> some helper classes in Spring that duplicate Commons Lang 
> functionality.
>
> It is true that Commons Lang is already included in the Spring 
> distribution,
> but the only reason for this is to run JPetStore's Struts web tier (as
> stated in the lib/readme.txt file in the distribution). Commons Lang 
> is just
> a Struts dependency here, not a Spring dependency.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Pieter Coucke
> Sent: Tuesday, January 18, 2005 12:39 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Re: Some code remarks
>
>
> Commons-lang is already inside the Spring distribution, so I don't see 
> the
> problem there.
>
> I agree that the commons-whatever packaging is not ideal however, most
> projects that decide to use commons, need almost all of the common (pun
> intended) jars.  One commons.jar may be a solution, but is probably not
> possible since every component has a different release 
> schedule/version.
>
> Anyway, a tool like maven downloads new releases automatically, and
> building wars or ears also is usually done in scripts, so it's only a
> matter of configuring dependencies once.
>
> If you don't need the JavaScriptUtils class, you can also remove the
> dependency on commons-lang to save that extra bit of disk space, it 
> really
> think it will make a difference on current 250 GB disks.
>
> Following your blog, we should write everything ourselves (for
> componentless support) AND write code that uses a component.  Seems 
> more
> work than simply maintaining a dependency to me... Especially something
> like HTML escaping (did you have a look at the Spring implementation) 
> is
> very likely to contain errors or omissions and shouldn't (in my 
> opinion of
> course) be rewritten if a well-maintained solution is already 
> available.
>
> just my two eurocents (a bit more worth than dollarcents now, hehe)
>
> Pieter
>
>
>
> Yannick Menager said:
>> Pieter Coucke <pieter.coucke <at> onthoo.com> writes:
>>> I browsed a bit through the Spring source code and have some remarks
>>> about possible code improvements.
>>>
>>> 1) JavaScriptUtils can be replaced with
>>> StringEscapeUtils.escapeJavaScript(), which is in commons-lang 2.0
>>> (apparently the current commons-lang version is an old one where this
>>> class isn't included)
>>>
>>> 2) HtmlUtils can be replaced with StringEscapeUtils.escapeHtml()
>>
>> Please read the following: http://tinyurl.com/66lny
>>
>> Right now, Spring is not dependent on commons-lang, and I certainly 
>> hope
>> it will
>> stay that way.
>>
>> *Dependencies are EVIL*
>>
>> I don't think any spring user has any desire to have to include 10mb 
>> of
>> commons-this, commons-that just to run their hello world spring
>> application (
>> see cocoon for one of the scariest examples )
>>
>>
>>
>>
>> -------------------------------------------------------
>> The SF.Net email is sponsored by: Beat the post-holiday blues
>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: Some code remarks

[Juergen H. <ju...@in...>]

Thanks for pointing that out - I wasn't aware of that! Actually, I've
already upgraded the Struts version that we ship to 1.2.4... which means I
should be able to remove commons-lang completely.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Matt Raible
Sent: Wednesday, January 19, 2005 8:44 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: Some code remarks


Just FYI... commons-lang is no longer a Struts dependency (I believe as
of 1.2.4) - so if you upgrade, you could get rid of it altogether!

Matt

On Jan 19, 2005, at 10:28 AM, Juergen Hoeller wrote:

> Pierre,
>
> I agree with Yannick that it is not desirable to depend on Commons
> Lang.
> Spring's core currently has a minimal set of dependencies and just
> relies on
> third-party libraries for full-blown optional features (like proxying
> full
> target via CGLIB). I prefer to keep it that way, at the expense of
> having
> some helper classes in Spring that duplicate Commons Lang
> functionality.
>
> It is true that Commons Lang is already included in the Spring
> distribution,
> but the only reason for this is to run JPetStore's Struts web tier (as
> stated in the lib/readme.txt file in the distribution). Commons Lang
> is just
> a Struts dependency here, not a Spring dependency.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Pieter Coucke
> Sent: Tuesday, January 18, 2005 12:39 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Re: Some code remarks
>
>
> Commons-lang is already inside the Spring distribution, so I don't see
> the
> problem there.
>
> I agree that the commons-whatever packaging is not ideal however, most
> projects that decide to use commons, need almost all of the common (pun
> intended) jars.  One commons.jar may be a solution, but is probably not
> possible since every component has a different release
> schedule/version.
>
> Anyway, a tool like maven downloads new releases automatically, and
> building wars or ears also is usually done in scripts, so it's only a
> matter of configuring dependencies once.
>
> If you don't need the JavaScriptUtils class, you can also remove the
> dependency on commons-lang to save that extra bit of disk space, it
> really
> think it will make a difference on current 250 GB disks.
>
> Following your blog, we should write everything ourselves (for
> componentless support) AND write code that uses a component.  Seems
> more
> work than simply maintaining a dependency to me... Especially something
> like HTML escaping (did you have a look at the Spring implementation)
> is
> very likely to contain errors or omissions and shouldn't (in my
> opinion of
> course) be rewritten if a well-maintained solution is already
> available.
>
> just my two eurocents (a bit more worth than dollarcents now, hehe)
>
> Pieter
>
>
>
> Yannick Menager said:
>> Pieter Coucke <pieter.coucke <at> onthoo.com> writes:
>>> I browsed a bit through the Spring source code and have some remarks
>>> about possible code improvements.
>>>
>>> 1) JavaScriptUtils can be replaced with
>>> StringEscapeUtils.escapeJavaScript(), which is in commons-lang 2.0
>>> (apparently the current commons-lang version is an old one where this
>>> class isn't included)
>>>
>>> 2) HtmlUtils can be replaced with StringEscapeUtils.escapeHtml()
>>
>> Please read the following: http://tinyurl.com/66lny
>>
>> Right now, Spring is not dependent on commons-lang, and I certainly
>> hope
>> it will
>> stay that way.
>>
>> *Dependencies are EVIL*
>>
>> I don't think any spring user has any desire to have to include 10mb
>> of
>> commons-this, commons-that just to run their hello world spring
>> application (
>> see cocoon for one of the scariest examples )
>>
>>
>>
>>
>> -------------------------------------------------------
>> The SF.Net email is sponsored by: Beat the post-holiday blues
>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Velocity / Freemarker request & response objects

[Rob B. <cro...@ya...>]

Hello all,

Is there any particular reason that the request and
response objects are not exposed in the velocity &
freemarker views?  It makes things like
request.isUserInRole() and response.setContentType()
more difficult to use in the templates than they
should be.

Would it be possible to add a methods like

setExposeRequestAs(String in)
and
setExposeResponseAs(String in)

to AbstractTemplateView?   

If the above methods are not called, the
request/response would not be exposed in the
templates.  If they were called, then the objects
would be exposed in the templates using the passed in
names.  In this way, if someone wanted to expose the
request to the templates with a non-default name (i.e.
something other than request) that would be possible. 

Later
Rob


	
		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail

[Springframework-developer] common super-interface in mail functionality

[David B. <viv...@gm...>]

I'm using the mail components to write a small framework (apology for
the way overused word) that can send either text or html e-mails.  To
simplify this, it would be nice if there were a common super-interface
for org.springframework.mail.SimpleMailMessage and
org.springframework.mail.javamail.MimeMessageHelper.  They both share
getters and setters for properties like cc, to, from, text, etc.  It
would be nice to be able to have common initialization code regardless
of whether I'm working with a text or html message.