springframework-developer — Spring Framework developers list

[Springframework-developer] Where to start with Spring framework?

[Davor C. <dav...@ma...>]

I heard of Spring Framework on the Struts mailing list. So far I know that 
it should be a J2EE application framework which solves many Struts's (and 
some other frameworks') problems.

I've been reading this mailing list for the last two-three weeks and I'm 
interested in joining the development team (I have at least 15hrs/week of 
the 'developers time' for the next 2 months). I fetched the CVS 
sourcetree but I don't understand quite clearly where to start. 
Unfortunatelly, I don't have the book either (Amazon ships it within 3-5 
weeks and my local bookstore sold it out).

So the question is: is there some sample application or quickstart document 
or do I really need to read the book? Since I won't get my copy of the book 
for at least 5 weeks from now, how can I start with Spring? Are there some 
book excerpts available, which cover the framework's basics?

And when I'm already writing this, some remarks regarding recent 
discussions:

- you really need some 0.8 prerelease or something like that, just to help 
the people (like myself) to start. With early release you'll get the 
momentum, lots of bug fixes, suggestions etc (standard open source 
artifacts)
- jalopy is a really good tool, on my last job I forced the development 
team to use it (we used WSAD as well) and it really helped with 
readability. We were most satisfied with the members sorting and long 
statement splitting:

DbConnector.getConnection()
           .fetchResultSet()
           .toXml()
           .save()

I have a quite nice jalopy config file if you're interested in it, I could 
post it somewhere.

Regards,
Davor
-- 
dav...@ma...

RE: [Springframework-developer] purpose of code in Errors.rejectValue()

[Tony F. <ton...@ya...>]

John,

I believe the "code" field refers to an "ErrorCode" that could be used
as a string value of an error msg that is associated with that Error.
(Similar to a mainframe returning an error code when a bad message is
returned to a user, only since it's a string it can actually be a bit
descriptive for the user.)  See the javadocs for the
com.interface21.core.ErrorCoded interface for a detailed description.

I am making some changes to the framework (then will pend review from
Rod) to allowing ResourceBundles to be tied into a few things within the
framework a little better.

Right now, I believe the API to obtaining messages for anything in the
framework is limited in 2 ways:
1)  Does not allow parameters to be passed to it.
2)  Some of the APIs do not allow a Locale to be passed into them (the
Errors.rejectValue(...) is a good example.

My changes should address both these issues.  Also, I am attempting to
add a subclass to the NestedException class (that merely calls a helper
object) that will allow Exceptions themselves to obtain their messages
from a ResourceBundle.  I have this working now for myself, but wish to
make a few changes to it to model the behavior of how log4j allows you
to point various classes to various files (ie: Exceptions in this
package look to this file for their msgs).  I am a few days away from a
code review on this.

As far as answering your question about examples, I'm sorry but I don't
have any examples to give you.


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of John Cavacas
Sent: Monday, March 03, 2003 4:03 PM
To: spr...@li...
Subject: [Springframework-developer] purpose of code in
Errors.rejectValue()

I was wondering if someone, most likelly Rob, could tell me what the 
purpose of the String code parameter is in Errors.rejectValue(String 
field,String code,String message) method.

And like my previous email "Validation usage examples and questions" i 
am looking for further clarification and proposed usage of the 
validation and DataBinding techniques in the framework.

Thanks,
John



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The
debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost
and 
disoriented. TotalView can help you find your way. Available on major
UNIX 
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] purpose of code in Errors.rejectValue()

[John C. <joh...@sa...>]

I was wondering if someone, most likelly Rob, could tell me what the 
purpose of the String code parameter is in Errors.rejectValue(String 
field,String code,String message) method.

And like my previous email "Validation usage examples and questions" i 
am looking for further clarification and proposed usage of the 
validation and DataBinding techniques in the framework.

Thanks,
John

Re: [Springframework-developer] Code format tools Part II

[Rod J. <rod...@in...>]

> I am personally not accustomed to having an external automated tool
> exert so much control over my code.  However, if the group or Rod feels
> that the above requirements need to be enforced programatically for the
> health of the project, I could be convinced.

I'm waiting to see what Tony comes up with, so I can try it before I buy it.

I'm not accustomed to this either, but I think there are some real
advantages, especially wrt CVS.

I think a lot of other projects just have inconsistency, which I don't like.

Rod

Re: [Springframework-developer] Code format tools Part II

[William G. T. Jr. <wg...@rc...>]

First, +1 on not introducing dependencies on a/any IDE.
(eclipse today...back to vi tomorrow ;)  Long Live Ant!

Tony Falabella wrote:
> I see your point now. 
> 
> Actually it is not enough for us to set up the format template to just 
> perform indentation, we will have to have it sort methods/attributes at 
> least by name, and by modifier (according to recommendation in the book). 
> 
> This should then accomplish what we need.

I am personally not accustomed to having an external automated tool 
exert so much control over my code.  However, if the group or Rod feels 
that the above requirements need to be enforced programatically for the 
health of the project, I could be convinced.

> 
> I can't comment on whether or not Eclipse settings would also do the 
> same thing, but I don't think we should require all developers to use 
> Eclipse (and if everyone does not do the same thing consistently there's 
> no point in doing any of this).

The consistency issue is really my main point, and I'm concerned that 
even having an automated tool will not mitigate this risk.  (are other 
open source projects doing this?)

It seems reasonable enough to set some guidelines, enforce them by group 
dynamics, and leave code consistent to the way you found it.

This is simple and ease to implement.

Bill

> 
> If our format template includes sorting, do you concur that it should 
> address our needs?
>   
> 
>  "William G. Thompson, Jr." <wg...@rc... 
> <mailto:wg...@rc...>> wrote:
> 
> Tony Falabella wrote:
>  > Bill,
>  >
>  > I believe the main point of the exercise is to easily see diffs in
>  > changes in the repos. As such, I believe issue #2 has to be ruled out
>  > (please read on).
> 
> The issues with diffs is exactly why #2 is important. In other words,
> unless the the automated mechanism can be garunteed to only munge code
> changed by a developer, diffs will get corrupted. I have not used
> Jalopy, so I can not comment on its consistency.
> 
> The diff problem is easily solved if #2 is our mode of operation. The
> goodliness of the code formating can be solved simply with the correct
> eclipse settings. This does not rule out the one-time reformating of
> the code base.
> 
> Bill
> 
>  > My thoughts are I will check out ALL code the first time, run it through
>  > the formatter with an agreed upon template and check it back in
>  > (comments for checkin will be something like "reformatted to group
>  > standard format").
>  >
>  > After that, the requirement on developers will simply be to make sure
>  > you run the Ant build/tests RIGHT BEFORE checking in your code (a
>  > procedure all should be following anyway). This will ensure it is in
>  > the format that the group agreed upon when you perform your checkin (FYI
>  > - only classes you have as writable will be effected).
>  >
>  > There is no mandate that any developer use the beautifier themselves.
>  > If you so choose to use a beautifier yourself, you can pick any
>  > beautifier you'd like, and create any format you like. Your changes
>  > will not be seen by the group though since the Ant script will reformat
>  > the code to the group's agreed upon format prior t you checking that
>  > code in.
>  >
>  > In case you wish to use Jalopy yourself within an IDE I will tell the
>  > group where the format file is located (and this is specific to
>  > Jalopy). You will then just need to point Jalopy to this file.
>  >
>  >
> 
>  
> 


-- 
William G. Thompson, Jr.
Associate Director of New Technologies
Administrative Computing Services, Rutgers University
voice: 732 445-5428 | fax: 732 445-5493 | wth...@ac...

Re: [Springframework-developer] Code format tools Part II

[Rod J. <rod...@in...>]

Much as I love Eclipse, I think it's important that our build/commit process
is purely handled by Ant. I don't like forcing people to use a particular
IDE (or _any_ IDE, for that matter).

Also, Juergen Hoeller is one active contributor who's not using Eclipse.
(IDEA).

----- Original Message -----
From: "Tony Falabella" <ton...@ya...>
To: "William G. Thompson, Jr." <wg...@rc...>
Cc: <spr...@li...>
Sent: Monday, March 03, 2003 4:33 PM
Subject: Re: [Springframework-developer] Code format tools Part II


>
> I see your point now.  Actually it is not enough for us to set up the
format template to just perform indentation, we will have to have it sort
methods/attributes at least by name, and by modifier (according to
recommendation in the book).
> This should then accomplish what we need.
> I can't comment on whether or not Eclipse settings would also do the same
thing, but I don't think we should require all developers to use Eclipse
(and if everyone does do the same thing consistently there's no point in
doing any of this).
> If our format template includes sorting, do you concur that it should
address our needs?
>
>  "William G. Thompson, Jr." <wg...@rc...> wrote:Tony Falabella
wrote:
> > Bill,
> >
> > I believe the main point of the exercise is to easily see diffs in
> > changes in the repos. As such, I believe issue #2 has to be ruled out
> > (please read on).
>
> The issues with diffs is exactly why #2 is important. In other words,
> unless the the automated mechanism can be garunteed to only munge code
> changed by a developer, diffs will get corrupted. I have not used
> Jalopy, so I can not comment on its consistency.
>
> The diff problem is easily solved if #2 is our mode of operation. The
> goodliness of the code formating can be solved simply with the correct
> eclipse settings. This does not rule out the one-time reformating of
> the code base.
>
> Bill
>
> > My thoughts are I will check out ALL code the first time, run it through
> > the formatter with an agreed upon template and check it back in
> > (comments for checkin will be something like "reformatted to group
> > standard format").
> >
> > After that, the requirement on developers will simply be to make sure
> > you run the Ant build/tests RIGHT BEFORE checking in your code (a
> > procedure all should be following anyway). This will ensure it is in
> > the format that the group agreed upon when you perform your checkin (FYI
> > - only classes you have as writable will be effected).
> >
> > There is no mandate that any developer use the beautifier themselves.
> > If you so choose to use a beautifier yourself, you can pick any
> > beautifier you'd like, and create any format you like. Your changes
> > will not be seen by the group though since the Ant script will reformat
> > the code to the group's agreed upon format prior to you checking that
> > code in.
> >
> > In case you wish to use Jalopy yourself within an IDE I will tell the
> > group where the format file is located (and this is specific to
> > Jalopy). You will then just need to point Jalopy to this file.
> >
> >
> >
> > */"William G. Thompson, Jr." /* wrote:
> >
> > William G. Thompson, Jr. wrote:
> > > Tony Falabella wrote:
> > >
> > >> BTW - I've tried to put hooks into CVS to have it run a program
> > (using
> > >> a filter like *.java) prior to commits to it. While the hook
> > appears
> > >> to be there (and you'll see mention of being able to do this in the
> > >> documentation for CVS), the code within CVS has actually been
> > >> commented out. What will happen is you'll get an error like
> > >> "Unimplemented in this version of CVS, consult the reference guide."
> > >> Apparently they added this functionality to CVS, found it was too
> > >> buggy for some platforms/files/etc. so rather than take it out they
> > >> just now return that msg above. Someone has a workaround for it,
> > but
> > >> it doesn't seem recommended. Thus my ANT suggestion.
> > >>
> > >
> > > Folks,
> > >
> > > some suggestions:
> > > 1 agree on source formating and post the eclipse settings
> > > 2) agree to _not_ reformat other ppls code just for the sake of
> > > reformatting
> > > 3) let social mechanisms or our benefical dictator take care of
> > source
> > > formating issues
> > I really mean let social mechanisms or our beneficial dictator take
> > care
> > of enforcement. (as opposed to some software imposed mechanism that
> > will
> > complicate the process)
> >
> > > 4) keep it simple ;)
> > >
> > > Cheers,
> > > Bill
> > >
> >
>
>

Re: [Springframework-developer] Code format tools Part II

[Tony F. <ton...@ya...>]

I see your point now.  

Actually it is not enough for us to set up the format template to just perform indentation, we will have to have it sort methods/attributes at least by name, and by modifier (according to recommendation in the book).  

This should then accomplish what we need. 

I can't comment on whether or not Eclipse settings would also do the same thing, but I don't think we should require all developers to use Eclipse (and if everyone does not do the same thing consistently there's no point in doing any of this). 

If our format template includes sorting, do you concur that it should address our needs? 

 

 


 "William G. Thompson, Jr." <wg...@rc...> wrote: 

Tony Falabella wrote:
> Bill,
> 
> I believe the main point of the exercise is to easily see diffs in 
> changes in the repos. As such, I believe issue #2 has to be ruled out 
> (please read on). 

The issues with diffs is exactly why #2 is important. In other words, 
unless the the automated mechanism can be garunteed to only munge code 
changed by a developer, diffs will get corrupted. I have not used 
Jalopy, so I can not comment on its consistency.

The diff problem is easily solved if #2 is our mode of operation. The 
goodliness of the code formating can be solved simply with the correct 
eclipse settings. This does not rule out the one-time reformating of 
the code base.

Bill

> My thoughts are I will check out ALL code the first time, run it through 
> the formatter with an agreed upon template and check it back in 
> (comments for checkin will be something like "reformatted to group 
> standard format"). 
> 
> After that, the requirement on developers will simply be to make sure 
> you run the Ant build/tests RIGHT BEFORE checking in your code (a 
> procedure all should be following anyway). This will ensure it is in 
> the format that the group agreed upon when you perform your checkin (FYI 
> - only classes you have as writable will be effected).
> 
> There is no mandate that any developer use the beautifier themselves. 
> If you so choose to use a beautifier yourself, you can pick any 
> beautifier you'd like, and create any format you like. Your changes 
> will not be seen by the group though since the Ant script will reformat 
> the code to the group's agreed upon format prior to you checking that 
> code in.
> 
> In case you wish to use Jalopy yourself within an IDE I will tell the 
> group where the format file is located (and this is specific to 
> Jalopy). You will then just need to point Jalopy to this file.
> 
> 


 

Re: [Springframework-developer] Code format tools Part II

[Tony F. <ton...@ya...>]

I see your point now.  Actually it is not enough for us to set up the format template to just perform indentation, we will have to have it sort methods/attributes at least by name, and by modifier (according to recommendation in the book).  
This should then accomplish what we need.
I can't comment on whether or not Eclipse settings would also do the same thing, but I don't think we should require all developers to use Eclipse (and if everyone does do the same thing consistently there's no point in doing any of this).
If our format template includes sorting, do you concur that it should address our needs?
 
 "William G. Thompson, Jr." <wg...@rc...> wrote:Tony Falabella wrote:
> Bill,
> 
> I believe the main point of the exercise is to easily see diffs in 
> changes in the repos. As such, I believe issue #2 has to be ruled out 
> (please read on). 

The issues with diffs is exactly why #2 is important. In other words, 
unless the the automated mechanism can be garunteed to only munge code 
changed by a developer, diffs will get corrupted. I have not used 
Jalopy, so I can not comment on its consistency.

The diff problem is easily solved if #2 is our mode of operation. The 
goodliness of the code formating can be solved simply with the correct 
eclipse settings. This does not rule out the one-time reformating of 
the code base.

Bill

> My thoughts are I will check out ALL code the first time, run it through 
> the formatter with an agreed upon template and check it back in 
> (comments for checkin will be something like "reformatted to group 
> standard format"). 
> 
> After that, the requirement on developers will simply be to make sure 
> you run the Ant build/tests RIGHT BEFORE checking in your code (a 
> procedure all should be following anyway). This will ensure it is in 
> the format that the group agreed upon when you perform your checkin (FYI 
> - only classes you have as writable will be effected).
> 
> There is no mandate that any developer use the beautifier themselves. 
> If you so choose to use a beautifier yourself, you can pick any 
> beautifier you'd like, and create any format you like. Your changes 
> will not be seen by the group though since the Ant script will reformat 
> the code to the group's agreed upon format prior to you checking that 
> code in.
> 
> In case you wish to use Jalopy yourself within an IDE I will tell the 
> group where the format file is located (and this is specific to 
> Jalopy). You will then just need to point Jalopy to this file.
> 
> 
> 
> */"William G. Thompson, Jr." /* wrote:
> 
> William G. Thompson, Jr. wrote:
> > Tony Falabella wrote:
> >
> >> BTW - I've tried to put hooks into CVS to have it run a program
> (using
> >> a filter like *.java) prior to commits to it. While the hook
> appears
> >> to be there (and you'll see mention of being able to do this in the
> >> documentation for CVS), the code within CVS has actually been
> >> commented out. What will happen is you'll get an error like
> >> "Unimplemented in this version of CVS, consult the reference guide."
> >> Apparently they added this functionality to CVS, found it was too
> >> buggy for some platforms/files/etc. so rather than take it out they
> >> just now return that msg above. Someone has a workaround for it,
> but
> >> it doesn't seem recommended. Thus my ANT suggestion.
> >>
> >
> > Folks,
> >
> > some suggestions:
> > 1 agree on source formating and post the eclipse settings
> > 2) agree to _not_ reformat other ppls code just for the sake of
> > reformatting
> > 3) let social mechanisms or our benefical dictator take care of
> source
> > formating issues
> I really mean let social mechanisms or our beneficial dictator take
> care
> of enforcement. (as opposed to some software imposed mechanism that
> will
> complicate the process)
> 
> > 4) keep it simple ;)
> >
> > Cheers,
> > Bill
> >
> 

Re: [Springframework-developer] Code format tools Part II

[William G. T. Jr. <wg...@rc...>]

Tony Falabella wrote:
> Bill,
> 
> I believe the main point of the exercise is to easily see diffs in 
> changes in the repos.  As such, I believe issue #2 has to be ruled out 
> (please read on). 

The issues with diffs is exactly why #2 is important.  In other words, 
unless the the automated mechanism can be garunteed to only munge code 
changed by a developer, diffs will get corrupted.  I have not used 
Jalopy, so I can not comment on its consistency.

The diff problem is easily solved if #2 is our mode of operation.  The 
goodliness of the code formating can be solved simply with the correct 
eclipse settings.  This does not rule out the one-time reformating of 
the code base.

Bill

> My thoughts are I will check out ALL code the first time, run it through 
> the formatter with an agreed upon template and check it back in 
> (comments for checkin will be something like "reformatted to group 
> standard format"). 
> 
> After that, the requirement on developers will simply be to make sure 
> you run the Ant build/tests RIGHT BEFORE checking in your code (a 
> procedure all should be following anyway).  This will ensure it is in 
> the format that the group agreed upon when you perform your checkin (FYI 
> - only classes you have as writable will be effected).
> 
> There is no mandate that any developer use the beautifier themselves.  
> If you so choose to use a beautifier yourself, you can pick any 
> beautifier you'd like, and create any format you like.  Your changes 
> will not be seen by the group though since the Ant script will reformat 
> the code to the group's agreed upon format prior to you checking that 
> code in.
> 
> In case you wish to use Jalopy yourself within an IDE I will tell the 
> group where the format file is located (and this is specific to 
> Jalopy).  You will then just need to point Jalopy to this file.
> 
>  
> 
> */"William G. Thompson, Jr." <wg...@rc...>/* wrote:
> 
>     William G. Thompson, Jr. wrote:
>      > Tony Falabella wrote:
>      >
>      >> BTW - I've tried to put hooks into CVS to have it run a program
>     (using
>      >> a filter like *.java) prior to commits to it. While the hook
>     appears
>      >> to be there (and you'll see mention of being able to do this in the
>      >> documentation for CVS), the code within CVS has actually been
>      >> commented out. What will happen is you'll get an error like
>      >> "Unimplemented in this version of CVS, consult the reference guide."
>      >> Apparently they added this functionality to CVS, found it was too
>      >> buggy for some platforms/files/etc. so rather than take it out they
>      >> just now return that msg above. Someone has a workaround for it,
>     but
>      >> it doesn't seem recommended. Thus my ANT suggestion.
>      >>
>      >
>      > Folks,
>      >
>      > some suggestions:
>      > 1 agree on source formating and post the eclipse settings
>      > 2) agree to _not_ reformat other ppls code just for the sake of
>      > reformatting
>      > 3) let social mechanisms or our benefical dictator take care of
>     source
>      > formating issues
>     I really mean let social mechanisms or our beneficial dictator take
>     care
>     of enforcement. (as opposed to some software imposed mechanism that
>     will
>     complicate the process)
> 
>      > 4) keep it simple ;)
>      >
>      > Cheers,
>      > Bill
>      >
> 

Re: [Springframework-developer] Code format tools Part II

[Tony F. <ton...@ya...>]

Bill, 
I believe the main point of the exercise is to easily see diffs in changes in the repos.  As such, I believe issue #2 has to be ruled out (please read on).  
My thoughts are I will check out ALL code the first time, run it through the formatter with an agreed upon template and check it back in (comments for checkin will be something like "reformatted to group standard format").  
After that, the requirement on developers will simply be to make sure you run the Ant build/tests RIGHT BEFORE checking in your code (a procedure all should be following anyway).  This will ensure it is in the format that the group agreed upon when you perform your checkin (FYI - only classes you have as writable will be effected).
There is no mandate that any developer use the beautifier themselves.  If you so choose to use a beautifier yourself, you can pick any beautifier you'd like, and create any format you like.  Your changes will not be seen by the group though since the Ant script will reformat the code to the group's agreed upon format prior to you checking that code in.
In case you wish to use Jalopy yourself within an IDE I will tell the group where the format file is located (and this is specific to Jalopy).  You will then just need to point Jalopy to this file.
 
"William G. Thompson, Jr." <wg...@rc...> wrote:William G. Thompson, Jr. wrote:
> Tony Falabella wrote:
> 
>> BTW - I've tried to put hooks into CVS to have it run a program (using 
>> a filter like *.java) prior to commits to it. While the hook appears 
>> to be there (and you'll see mention of being able to do this in the 
>> documentation for CVS), the code within CVS has actually been 
>> commented out. What will happen is you'll get an error like 
>> "Unimplemented in this version of CVS, consult the reference guide."
>> Apparently they added this functionality to CVS, found it was too 
>> buggy for some platforms/files/etc. so rather than take it out they 
>> just now return that msg above. Someone has a workaround for it, but 
>> it doesn't seem recommended. Thus my ANT suggestion.
>>
> 
> Folks,
> 
> some suggestions:
> 1) agree on source formating and post the eclipse settings
> 2) agree to _not_ reformat other ppls code just for the sake of 
> reformatting
> 3) let social mechanisms or our benefical dictator take care of source 
> formating issues
I really mean let social mechanisms or our beneficial dictator take care 
of enforcement. (as opposed to some software imposed mechanism that will 
complicate the process)

> 4) keep it simple ;)
> 
> Cheers,
> Bill
> 

Re: [Springframework-developer] Code format tools Part II

[William G. T. Jr. <wg...@rc...>]

William G. Thompson, Jr. wrote:
> Tony Falabella wrote:
> 
>> BTW - I've tried to put hooks into CVS to have it run a program (using 
>> a filter like *.java) prior to commits to it.  While the hook appears 
>> to be there (and you'll see mention of being able to do this in the 
>> documentation for CVS), the code within CVS has actually been 
>> commented out.  What will happen is you'll get an error like 
>> "Unimplemented in this version of CVS, consult the reference guide."
>> Apparently they added this functionality to CVS, found it was too 
>> buggy for some platforms/files/etc. so rather than take it out they 
>> just now return that msg above.  Someone has a workaround for it, but 
>> it doesn't seem recommended.  Thus my ANT suggestion.
>>
> 
> Folks,
> 
> some suggestions:
> 1) agree on source formating and post the eclipse settings
> 2) agree to _not_ reformat other ppls code just for the sake of 
> reformatting
> 3) let social mechanisms or our benefical dictator take care of source 
> formating issues
I really mean let social mechanisms or our beneficial dictator take care 
of enforcement. (as opposed to some software imposed mechanism that will 
complicate the process)

> 4) keep it simple ;)
> 
> Cheers,
> Bill
> 

Re: [Springframework-developer] Code format tools Part II

[William G. T. Jr. <wg...@rc...>]

Tony Falabella wrote:
> BTW - I've tried to put hooks into CVS to have it run a program (using a 
> filter like *.java) prior to commits to it.  While the hook appears to 
> be there (and you'll see mention of being able to do this in the 
> documentation for CVS), the code within CVS has actually been commented 
> out.  What will happen is you'll get an error like "Unimplemented in 
> this version of CVS, consult the reference guide." 
> 
> Apparently they added this functionality to CVS, found it was too buggy 
> for some platforms/files/etc. so rather than take it out they just now 
> return that msg above.  Someone has a workaround for it, but it doesn't 
> seem recommended.  Thus my ANT suggestion.
> 

Folks,

some suggestions:
1) agree on source formating and post the eclipse settings
2) agree to _not_ reformat other ppls code just for the sake of reformatting
3) let social mechanisms or our benefical dictator take care of source 
formating issues
4) keep it simple ;)

Cheers,
Bill

-- 
William G. Thompson, Jr.
Associate Director of New Technologies
Administrative Computing Services, Rutgers University
voice: 732 445-5428 | fax: 732 445-5493 | wth...@ac...

Re: [Springframework-developer] Code formatting tools

[Tony F. <ton...@ya...>]

Yes, this can also be done with Jalopy, and it use variable substitution in the creation of it.  It also has features to get rid of headers that are currently out there if you know some key word to look for in the old headers.  
Example header from Jalopy is:

//==============================================================================// file :       $fileName$// project:     $project$//// last change: date:       $Date$//              by:         $Author$//              revision:   $Revision$//------------------------------------------------------------------------------// copyright:   BSJT Software License (see class documentation)//==============================================================================

Send over the new header file to the group and I'll incorporate it in the Jalopy format file. 
 Rod Johnson <rod...@in...> wrote:Tony,

Could we use this to put in a new standard header, as the existing one is
out of date?

Yann is producing a new header.

Regards,
Rod

----- Original Message -----
From: "Tony Falabella" 
To: "Rod Johnson" ;

Sent: Friday, February 28, 2003 3:59 PM
Subject: Re: [Springframework-developer] Code formatting tools


>
> I will make a beautify template and change Ant script to incorporate
formatting to our template. Should have this done by early week (hopefully
Monday).
> Rod Johnson wrote:Tony,
>
> Using such a beautifier would definitely be valuable. One of the most
> important benefits would be that diffs are guaranteed to be meaningful, as
> you point out. Also each developer could reformat files they work on in
> their IDE to their preferred conventions before committing in our standard
> way.
>
> All developers should run Ant before doing a CVS check in to ensure that
the
> test suite succeeds, so I think it's fine to have the formatting applied
via
> Ant.
>
> I haven't used Jalopy. However, I did look around online a couple of weeks
> ago for work and it seemed like a good tool.
>
> Would you like to try to produce a Jalopy config file and send it too me
> with a modified build.xml so that I can look at the results?
>
> Yann is producing a coding conventions document, but I imagine
> beautification will only affect things we already all agree on. Basically
I
> would like to keep the canonical version of the source formatted as now.
>
> My preferences:
> - Formatting with { on same line, but a new line for a catch, as presently
> in source code
> - ordering and delimitation as described in chapter 4 and applied in most
> source. //-----------Implementation of X interface might be hard to do,
> though. I assume if the developer had already put that in Jalopy wouldn't
> necessarily completely reorder the file?
> - I prefer tabs but most people prefer spaces, so I guess Jalopy could
> settle on (3?) spaces, as they're allegedly better for CVS diffs
>
> In general I think we should follow ordering conventions as we write code,
> so maybe we don't want Jalopy to change that.
>
> I think CVS triggers are generally agreed not to work.
>
> Regards,
> Rod
>
> > Just wanted to bounce this off of you and the group. What do you think
of
> the developers using a code beautification tool before checking anything
> into the repos?
> >
> > One of the things I'm struggling with is I am very carefree when I code
> with my indentation. Why? I use a code beautifier before I save my code.
> When making modifications to the framework however, it is not a good idea
to
> run classes I'm changing through a code beautifier because it will shuffle
> things around from what they were so much that it will be difficult to see
> the small diffs that might have been made to a file.
> >
> > Here's my suggestion. Integrate Jalopy
> (http://sourceforge.net/projects/jalopy) into the ANT build scripts either
> when a build is done, or when the tests are run. Jalopy is opensource, is
> very configurable, and has pluggins for all the major IDEs and ANT. A very
> nice feature is that you can save the formatting configuration you like
for
> it in an XML file that you would then distribute with the build file.
> Assuming all developers run ANT before checking things into CVS, their
files
> will all conform to the format you like. (It also allows for putting
> separator lines for things like constructors, static vars, instance vars,
> etc - as you seem to advocate in your book).
> >
> > This will make it a lot easier to see minor changes that are made from
> each iteration of code checked in.
> >
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Validation usage examples and questions

[John C. <oo...@ro...>]

Hey everyone,

I have a class called NewUserRegistrationRequest which is a simple
javabean that will transport the data submited by a user from a webpage
(not implemented yet) to my business object. My business object has a
method called registerUser(NewUserRegistrationRequest request) which
handles this use case.

My dilema is how to handle syntatic and semantic validation for this
particular use case which will most likelly dictate how I handle things
in other use cases.

The validations that I need are
1) making sure the Request object is properlly initiallized and that
none of the properties are null
2) making sure that username is unique
3) making sure that email address is unique
4) username and password length rules
5) making sure that an email address looks like an email address
6) making sure that a default user access level is assigned to this new
user
7) * allow for futher rules to be defined without a huge impact in the
application. For example, I may want to have a rule which sends out an
email to the new user in order to validate the registration at a later
date.

The way I see it, 1,4 and 5 are syntatic rules and 2,3, and 6 are
semantic rules (to use the terms in the book)

Some other requirments would be to allow for internatiolization of
messages, and it would be nice to also have javascript generated or
associated with this validation, so that both client side and server
side validation could be done if wanted. With this last requirement,
it's not really something I desire. I personaly do not trust client side
validation, so I usualy do all validation on the server side. So if I
don't get to that, its no big deal.

These validations should hopefully only occour in once place. But what
is that place? The validator interface looks like it's where I should
start but I don't completly understand how it should work overall.
Should I invoke this validator in my business method? My thoughts tell
me yes that that's what I should be doing. But what about sending errors
out from the validator back to calling code without "poluting" my
business interfaces? How would that work?

Any ideas suggestions or comments would be greatly appriciated.

Thanks,
John

Re: [Springframework-developer] Code formatting tools

[Rod J. <rod...@in...>]

Tony,

Could we use this to put in a new standard header, as the existing one is
out of date?

Yann is producing a new header.

Regards,
Rod

----- Original Message -----
From: "Tony Falabella" <ton...@ya...>
To: "Rod Johnson" <rod...@in...>;
<spr...@li...>
Sent: Friday, February 28, 2003 3:59 PM
Subject: Re: [Springframework-developer] Code formatting tools


>
> I will make a beautify template and change Ant script to incorporate
formatting to our template.  Should have this done by early week (hopefully
Monday).
>  Rod Johnson <rod...@in...> wrote:Tony,
>
> Using such a beautifier would definitely be valuable. One of the most
> important benefits would be that diffs are guaranteed to be meaningful, as
> you point out. Also each developer could reformat files they work on in
> their IDE to their preferred conventions before committing in our standard
> way.
>
> All developers should run Ant before doing a CVS check in to ensure that
the
> test suite succeeds, so I think it's fine to have the formatting applied
via
> Ant.
>
> I haven't used Jalopy. However, I did look around online a couple of weeks
> ago for work and it seemed like a good tool.
>
> Would you like to try to produce a Jalopy config file and send it too me
> with a modified build.xml so that I can look at the results?
>
> Yann is producing a coding conventions document, but I imagine
> beautification will only affect things we already all agree on. Basically
I
> would like to keep the canonical version of the source formatted as now.
>
> My preferences:
> - Formatting with { on same line, but a new line for a catch, as presently
> in source code
> - ordering and delimitation as described in chapter 4 and applied in most
> source. //-----------Implementation of X interface might be hard to do,
> though. I assume if the developer had already put that in Jalopy wouldn't
> necessarily completely reorder the file?
> - I prefer tabs but most people prefer spaces, so I guess Jalopy could
> settle on (3?) spaces, as they're allegedly better for CVS diffs
>
> In general I think we should follow ordering conventions as we write code,
> so maybe we don't want Jalopy to change that.
>
> I think CVS triggers are generally agreed not to work.
>
> Regards,
> Rod
>
> > Just wanted to bounce this off of you and the group. What do you think
of
> the developers using a code beautification tool before checking anything
> into the repos?
> >
> > One of the things I'm struggling with is I am very carefree when I code
> with my indentation. Why? I use a code beautifier before I save my code.
> When making modifications to the framework however, it is not a good idea
to
> run classes I'm changing through a code beautifier because it will shuffle
> things around from what they were so much that it will be difficult to see
> the small diffs that might have been made to a file.
> >
> > Here's my suggestion. Integrate Jalopy
> (http://sourceforge.net/projects/jalopy) into the ANT build scripts either
> when a build is done, or when the tests are run. Jalopy is opensource, is
> very configurable, and has pluggins for all the major IDEs and ANT. A very
> nice feature is that you can save the formatting configuration you like
for
> it in an XML file that you would then distribute with the build file.
> Assuming all developers run ANT before checking things into CVS, their
files
> will all conform to the format you like. (It also allows for putting
> separator lines for things like constructors, static vars, instance vars,
> etc - as you seem to advocate in your book).
> >
> > This will make it a lot easier to see minor changes that are made from
> each iteration of code checked in.
> >
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] New stuff in CVS

[<jue...@we...>]

Hi Springies,

I've finally committed some changes and enhancements that I've proposed:

- BeanFactory inheritance instead of ApplicationContext inheritance, =
mainly to allow for bean references to application context beans in =
controller servlet config files;

- reworked validation, now one Errors instance per bind object + empty =
Errors instance even for form view + global errors + multiple errors per =
field + rewritten tags + the new BindUtils class for simple retrieving =
in JSP expressions;

- reworked BaseCommandController + FormController + =
SessionFormController, for easier and more flexible form controller =
implementations;

- defaultParentView property in ResourceBundleViewResolver (+ according =
defaultParentBean property in AbstractBeanFactory) that allows for =
specifying a default parent instead of mentioning "viewname.parent=3D" =
for every view mapping (e.g. the parent can specify a view class that =
gets used for all views that do not override it, in case of one dominant =
view type);

- more flexible startup: refactored ContextLoader + ContextLoaderServlet =
+ ContextLoaderListener, default context class, no message prerequisite;

- LocaleResolver for explicit locale setting, with implementations for =
accept header, session, and cookie;

- JstlView implementation, exposing Spring's message source and user =
locale to JSTL tags;

- modified build script, using individual J2EE interface libraries in =
lib/j2ee instead of a J2EE RI now.

I encourage everyone to download the current version, and try and check =
the new stuff. Feedback is very welcome! :-)

My next steps will be 2 more of my proposals:

- multipart request handling aka file upload: MultipartResolver + =
implementations for Jason Hunter's COS and Jakarta's Commons FileUpload;

- adding a utility class for HTML escaping, and appropriate support =
within Spring's web functionality (e.g. message output, form values, =
form errors).

Regards,
Juergen

[Springframework-developer] HTML escaping

[<jue...@we...>]

Does anyone know about restrictions concerning HTML escaping? AFAIK, any =
text written to JSPs or Velocity templates that produce HTML content =
needs to get escaped. Thus, Spring's JSP tags could escape implicitly =
when returning messages, form values, and form errors - in case of =
content type HTML.

I wonder how we could ease things for JSP expressions and Velocity =
templates, in terms of implicit escaping. The model itself should be =
HTML-agnostic, so we need a solution specific to HTML views. Maybe wrap =
the WebApplicationContext and Errors instances accordingly, in an HTML =
view implementation? Any thoughts?

Juergen

Re: [Springframework-developer] Code formatting tools

[Tony F. <ton...@ya...>]

I will make a beautify template and change Ant script to incorporate formatting to our template.  Should have this done by early week (hopefully Monday).
 Rod Johnson <rod...@in...> wrote:Tony,

Using such a beautifier would definitely be valuable. One of the most
important benefits would be that diffs are guaranteed to be meaningful, as
you point out. Also each developer could reformat files they work on in
their IDE to their preferred conventions before committing in our standard
way.

All developers should run Ant before doing a CVS check in to ensure that the
test suite succeeds, so I think it's fine to have the formatting applied via
Ant.

I haven't used Jalopy. However, I did look around online a couple of weeks
ago for work and it seemed like a good tool.

Would you like to try to produce a Jalopy config file and send it too me
with a modified build.xml so that I can look at the results?

Yann is producing a coding conventions document, but I imagine
beautification will only affect things we already all agree on. Basically I
would like to keep the canonical version of the source formatted as now.

My preferences:
- Formatting with { on same line, but a new line for a catch, as presently
in source code
- ordering and delimitation as described in chapter 4 and applied in most
source. //-----------Implementation of X interface might be hard to do,
though. I assume if the developer had already put that in Jalopy wouldn't
necessarily completely reorder the file?
- I prefer tabs but most people prefer spaces, so I guess Jalopy could
settle on (3?) spaces, as they're allegedly better for CVS diffs

In general I think we should follow ordering conventions as we write code,
so maybe we don't want Jalopy to change that.

I think CVS triggers are generally agreed not to work.

Regards,
Rod

> Just wanted to bounce this off of you and the group. What do you think of
the developers using a code beautification tool before checking anything
into the repos?
>
> One of the things I'm struggling with is I am very carefree when I code
with my indentation. Why? I use a code beautifier before I save my code.
When making modifications to the framework however, it is not a good idea to
run classes I'm changing through a code beautifier because it will shuffle
things around from what they were so much that it will be difficult to see
the small diffs that might have been made to a file.
>
> Here's my suggestion. Integrate Jalopy
(http://sourceforge.net/projects/jalopy) into the ANT build scripts either
when a build is done, or when the tests are run. Jalopy is opensource, is
very configurable, and has pluggins for all the major IDEs and ANT. A very
nice feature is that you can save the formatting configuration you like for
it in an XML file that you would then distribute with the build file.
Assuming all developers run ANT before checking things into CVS, their files
will all conform to the format you like. (It also allows for putting
separator lines for things like constructors, static vars, instance vars,
etc - as you seem to advocate in your book).
>
> This will make it a lot easier to see minor changes that are made from
each iteration of code checked in.
>




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Code formatting tools

[Rod J. <rod...@in...>]

Tony,

Using such a beautifier would definitely be valuable. One of the most
important benefits would be that diffs are guaranteed to be meaningful, as
you point out. Also each developer could reformat files they work on in
their IDE to their preferred conventions before committing in our standard
way.

All developers should run Ant before doing a CVS check in to ensure that the
test suite succeeds, so I think it's fine to have the formatting applied via
Ant.

I haven't used Jalopy. However, I did look around online a couple of weeks
ago for work and it seemed like a good tool.

Would you like to try to produce a Jalopy config file and send it too me
with a modified build.xml so that I can look at the results?

Yann is producing a coding conventions document, but I imagine
beautification will only affect things we already all agree on. Basically I
would like to keep the canonical version of the source formatted as now.

My preferences:
- Formatting with { on same line, but a new line for a catch, as presently
in source code
- ordering and delimitation as described in chapter 4 and applied in most
source. //-----------Implementation of X interface might be hard to do,
though. I assume if the developer had already put that in Jalopy wouldn't
necessarily completely reorder the file?
- I prefer tabs but most people prefer spaces, so I guess Jalopy could
settle on (3?) spaces, as they're allegedly better for CVS diffs

In general I think we should follow ordering conventions as we write code,
so maybe we don't want Jalopy to change that.

I think CVS triggers are generally agreed not to work.

Regards,
Rod

> Just wanted to bounce this off of you and the group.  What do you think of
the developers using a code beautification tool before checking anything
into the repos?
>
>  One of the things I'm struggling with is I am very carefree when I code
with my indentation.  Why?  I use a code beautifier before I save my code.
When making modifications to the framework however, it is not a good idea to
run classes I'm changing through a code beautifier because it will shuffle
things around from what they were so much that it will be difficult to see
the small diffs that might have been made to a file.
>
> Here's my suggestion.  Integrate Jalopy
(http://sourceforge.net/projects/jalopy) into the ANT build scripts either
when a build is done, or when the tests are run.  Jalopy is opensource, is
very configurable, and has pluggins for all the major IDEs and ANT.  A very
nice feature is that you can save the formatting configuration you like for
it in an XML file that you would then distribute with the build file.
Assuming all developers run ANT before checking things into CVS, their files
will all conform to the format you like.  (It also allows for putting
separator lines for things like constructors, static vars, instance vars,
etc - as you seem to advocate in your book).
>
> This will make it a lot easier to see minor changes that are made from
each iteration of code checked in.
>

[Springframework-developer] Code format tools Part II

[Tony F. <ton...@ya...>]

BTW - I've tried to put hooks into CVS to have it run a program (using a filter like *.java) prior to commits to it.  While the hook appears to be there (and you'll see mention of being able to do this in the documentation for CVS), the code within CVS has actually been commented out.  What will happen is you'll get an error like "Unimplemented in this version of CVS, consult the reference guide."  

Apparently they added this functionality to CVS, found it was too buggy for some platforms/files/etc. so rather than take it out they just now return that msg above.  Someone has a workaround for it, but it doesn't seem recommended.  Thus my ANT suggestion.

[Springframework-developer] Code formatting tools

[Tony F. <ton...@ya...>]

Rod,

I am a few days away from checking in the ErrorCoded stuff.  I've made a few changes, and incorporated your feedback into what I have.  My changes will include now allowing Exceptions to be generated either from a "string" (already "resolved"), or from an errorCode +errorArgs+locale.  I will email you all code to review before making any changes in the repos.

Just wanted to bounce this off of you and the group.  What do you think of the developers using a code beautification tool before checking anything into the repos? 

 One of the things I'm struggling with is I am very carefree when I code with my indentation.  Why?  I use a code beautifier before I save my code.  When making modifications to the framework however, it is not a good idea to run classes I'm changing through a code beautifier because it will shuffle things around from what they were so much that it will be difficult to see the small diffs that might have been made to a file.

Here's my suggestion.  Integrate Jalopy (http://sourceforge.net/projects/jalopy) into the ANT build scripts either when a build is done, or when the tests are run.  Jalopy is opensource, is very configurable, and has pluggins for all the major IDEs and ANT.  A very nice feature is that you can save the formatting configuration you like for it in an XML file that you would then distribute with the build file.  Assuming all developers run ANT before checking things into CVS, their files will all conform to the format you like.  (It also allows for putting separator lines for things like constructors, static vars, instance vars, etc - as you seem to advocate in your book).

This will make it a lot easier to see minor changes that are made from each iteration of code checked in.

[Springframework-developer] BeanFactory / ApplicationRegistry / Arrays

[Trevor C. <tc...@in...>]

Is it possible to load a bean which has an object array property?  If so,
are there any examples?  A simple example of the type of thing I'd like to
do (based on the books TestBean example from pg400) is to give Rod kids :).
Create a child-bean with only nam and age properties, and give Rod an array
of them.  Then populate Rod with 3 kids using the bean factory (as shown on
pg403).  I've been playing with this for quite a while, and am hitting a
brick wall.

Thanks for any help,
Trevor D. Cook


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
 

Re: [Springframework-developer] Struts (and Re: ErrorCoded/MessageSource)

[<jue...@we...>]

> I agree, there's lots of stuff there, and things we can learn
> from. However, wrt the dispatch action, our=20
> com.interface21.web.servlet.mvc.multiaction.MultiActionControl
> ler does the same thing but is much more powerful.

I'm perfectly aware, of course :-)

What I meant regarding dispatch actions was that Struts 1.1 allows for =
form handling within dispatch actions, i.e. "someAction(request, =
response, form)"-like method signatures. We currently only support the =
"someAction(request, response)"-style, accompanied by =
"someHandler(request, response, exception)-style exception handlers. The =
drawback of Struts 1.1 is that it actually enforces form handling with =
dispatch actions, just like it generally treats every request as a form.

I rather look at Struts in terms of different approaches. For example, =
we don't really need "modules", as we support multiple =
ControllerServlets anyway, which I consider significantly clearer and =
more flexible. It's just that there might be some special functionality =
in Struts that Spring can't provide currently, even if the basic issue =
is addressed.

On the other hand, no new feature should sacrify Spring's clear =
architecture, just for the sake of convenience. We should try to find a =
balance in that respect.

Juergen

RE: [Springframework-developer] Changes to jdbc.object.StroredPro cedure class

[Trevor C. <tc...@in...>]

I'd prefer the first method ("isFunction") since there is already a
SqlFunction class so StoredFunction could get confusing.  It's good you
caught that (since Postgres is my primary db).  

With the SQLExceptionTranslator, I'm curious what you have planned,
especially with Postgres (since it doesn't use sqlstate / error codes).

I've been working on the jdbc.object test cases.  I can commit them tonight
and then fire off an email.

Trevor D. Cook


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: February 24, 2003 3:32 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Changes to
jdbc.object.StroredProcedure class


Guys,

I'm impressed with what Thomas has been doing, and I think he should be the
lead on the JDBC stuff. However, I know other people have contributions in
this area, so it's important we coordinate.

Yann, can you please drop a quick email to Thomas when you check your JDBC
stuff in? Maybe just forward one of your old emails to the P2P list?

Regards,
Rod

----- Original Message -----
From: "Thomas Risberg" <tri...@tr...>
To: <spr...@li...>
Sent: Monday, February 24, 2003 8:16 PM
Subject: [Springframework-developer] Changes to jdbc.object.StroredProcedure
class


> Hi guys,
>
> I have just joined the group and I'm really looking forward to working
> on this framework.  Great stuff so far.  I have e-mailed Rod with a few
> suggestions for the SQLExceptionTranslater functionality, we should be
> able to add some of the new features to CVS real soon.
>
> While testing the changes to the SQLTranslation logic on different
> databases I ran across a problem with using the StoredProcedure class
> from the jdbc.object package.
>
> It currently only supports the "{call my_proc(?, ?)}" syntax and this
> worked fine for procedures but not for stored functions.  With functions
> you have to use the following call syntax "{? = call my_func(?)}". Since
> all stored procedures in Postgres are declared as functions (CREATE
> FUNCTION ...) it was a problem.
>
> I came up with two solutions, and would like to know which one you would
> prefer.
>
> 1.  Add a boolean instance variable isFunction = false to the
> StoredProcedure.  This could be set to true if the call is to a function
> or left false if it is to a procedure.  Then the StoredProcedure could
> use the correct syntax while it is "compiling" the callString
>
> 2.  Create a StoredFunction class that does the same thing the current
> StoredProcedure does, except for the call syntax.  We could use
> sub-classing to avoid code duplication
>
> The first solution is simpler and less code, but maybe not as clear as
> the second one.
>
> This would be a good feature not only for Postgres, but for any database
> that supports the CREATE FUNCTION feature - Oracle, MS SQL, DB2 ...
>
> Let me know what you think.
>
> Also - is anybody working on any other parts of the jdbc package?  I'd
> be interested to look at other issues, but I don't want to solve/fix
> something that someone else is already looking at.
>
>
>  -- Thomas
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
 

Re: [Springframework-developer] Changes to jdbc.object.StroredProcedure class

[Rod J. <rod...@in...>]

Guys,

I'm impressed with what Thomas has been doing, and I think he should be the
lead on the JDBC stuff. However, I know other people have contributions in
this area, so it's important we coordinate.

Yann, can you please drop a quick email to Thomas when you check your JDBC
stuff in? Maybe just forward one of your old emails to the P2P list?

Regards,
Rod

----- Original Message -----
From: "Thomas Risberg" <tri...@tr...>
To: <spr...@li...>
Sent: Monday, February 24, 2003 8:16 PM
Subject: [Springframework-developer] Changes to jdbc.object.StroredProcedure
class


> Hi guys,
>
> I have just joined the group and I'm really looking forward to working
> on this framework.  Great stuff so far.  I have e-mailed Rod with a few
> suggestions for the SQLExceptionTranslater functionality, we should be
> able to add some of the new features to CVS real soon.
>
> While testing the changes to the SQLTranslation logic on different
> databases I ran across a problem with using the StoredProcedure class
> from the jdbc.object package.
>
> It currently only supports the "{call my_proc(?, ?)}" syntax and this
> worked fine for procedures but not for stored functions.  With functions
> you have to use the following call syntax "{? = call my_func(?)}". Since
> all stored procedures in Postgres are declared as functions (CREATE
> FUNCTION ...) it was a problem.
>
> I came up with two solutions, and would like to know which one you would
> prefer.
>
> 1.  Add a boolean instance variable isFunction = false to the
> StoredProcedure.  This could be set to true if the call is to a function
> or left false if it is to a procedure.  Then the StoredProcedure could
> use the correct syntax while it is "compiling" the callString
>
> 2.  Create a StoredFunction class that does the same thing the current
> StoredProcedure does, except for the call syntax.  We could use
> sub-classing to avoid code duplication
>
> The first solution is simpler and less code, but maybe not as clear as
> the second one.
>
> This would be a good feature not only for Postgres, but for any database
> that supports the CREATE FUNCTION feature - Oracle, MS SQL, DB2 ...
>
> Let me know what you think.
>
> Also - is anybody working on any other parts of the jdbc package?  I'd
> be interested to look at other issues, but I don't want to solve/fix
> something that someone else is already looking at.
>
>
>  -- Thomas
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer