springframework-developer — Spring Framework developers list

Re: [Springframework-developer] 1.0 M4 ready for release

[Darren D. <da...@da...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

j=FCrgen h=F6ller [werk3AT] wrote:
| Last chance for any last minute feedback... the M4 release is just arou=
nd
| the corner (to be released today).
|
| Has anybody tried deploying the sample apps, particularly JPetStore, an=
d
| had problems? Note that JPetStore can also be built for Commons
| Attributes ("attributes" directory), allows to choose between the Sprin=
g
| and the Struts web tier in web.xml, and has a demo remote client
| ("client" directory).

I've had JPetStore running fine in Tomcat 4.1.24, Tomcat 5.0.14, Resin
2.1.11 and Resin 3.0.4 as part of the automated building/testing.  I'll g=
ive
it a go on WebSphere 5 next week when I'm back in the office if you like.

Jetty4 won't run anything where the TLD is in a jar file.

I have however been getting the following error on Tomcat 5 (only) with
petclinic on all db access:
"java.lang.NoClassDefFoundError: javax/transaction/Synchronization" but
haven't had a chance to look into it yet (only saw it at 3am this morning=
)
so it could be something local..

Regards,

- --

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/9rhWKLMLAN01aw0RAkRhAJ9afYOlyyRmarlPOppMJ6qNa9V95wCfUV8Y
1xgmiTybK8roKQShEEg/Ots=3D
=3D0ZIQ
-----END PGP SIGNATURE-----

Re: [Springframework-developer] 1.0 M4 ready for release

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

Last chance for any last minute feedback... the M4 release is just =
around the corner (to be released today).
=20
Has anybody tried deploying the sample apps, particularly JPetStore, and =
had problems? Note that JPetStore can also be built for Commons =
Attributes ("attributes" directory), allows to choose between the Spring =
and the Struts web tier in web.xml, and has a demo remote client =
("client" directory).
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Fr 02.01.2004 01:22
An: spr...@li...
Betreff: [Springframework-developer] 1.0 M4 ready for release



Hi everybody,

First of all, a happy new year! It's been a great year 2003, =
particularly considering that the Spring Framework project didn't even =
exist 12 months ago (we'll celebrate first birthday in February). Of =
course, the framework version that came with Rod's book was already =
there: But we've seen massive refinement of the framework since, even =
exploring completely new areas like AOP support and transaction =
management, and have attracted a significant number of users (with about =
3000 downloads per release since 1.0 M1). I'd like to thank everybody =
for their contributions, no matter what kind, in what area, and to what =
extent!

I've just finished my preparations of our upcoming release 1.0 M4. In =
good old Spring Framework tradition, a last minute change in the core =
has sneaked in: I've introduced the core.io package with its Resource =
interface and out-of-the-box implementations ClassPathResource, =
FileSystemResource, etc. It's used in the BeanDefinitionRegistry area, =
and also for all former "configLocation" Strings - they are all of type =
Resource now. Thanks to an automatically registered PropertyEditor, =
specifying String paths in bean definitions works just like before, but =
the receiving beans do not have to be ApplicationContextAware anymore to =
be able to resolve resource locations in a generic way.

As most people have already found out, 1.0 M4 introduces our version of =
Clinton Begin's JPetStore, with a Spring-managed middle tier that =
leverages our new iBATIS Database Layer integration, and alternative =
Spring Web MVC and Struts web tiers. A recent addition is remoting =
support: The out-of-the-box JPetStore illustrates remoting via Hessian, =
Burlap, RMI, and our new JAX-RPC support via Axis. Like Clinton's =
original version did with Axis, we export an OrderService. An included =
OrderServiceClient invokes the OrderService to show an order by number, =
via all configured protocols. This should work without hassle via the =
included Ant scripts and the readme.

I'll release 1.0 M4 tomorrow night, sort of a new year's present for the =
Spring community ;-) Everybody who has some time left, please give the =
current CVS contents a try, particularly "playing user": Generate a =
release zip, unzip it, build the samples, deploy the samples. Note that =
as of 1.0 M4, there are two release zips: "spring-framework-1.0-m4" with =
everything but third-party libraries (~8 MB), and =
"spring-framework-1.0-m4-with-dependencies" which includes all libraries =
that are required for building the samples and the framework itself =
(~16.8 MB). Both distributions ship with build scripts and all sources =
and tests.

Regards,
Juergen


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: Final methods in SqlQuery

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

Mark,
=20
I agree that template methods are exactly the most important case where =
final is really appropriate. In particular, final is used to distinguish =
between methods that are intended for overriding (protected non-final) =
and ones that are just intended to be called from subclass methods =
(protected final): That's what we use extensively in the web controller =
hierarchy.
=20
In the case of SqlQuery, I don't see a need to keep the execute and =
findObject methods final. Unlike compileInternal (final) and =
onCompileInternal (non-final) from the superclass SqlOperation, there's =
no chance for confusion here. Noone should override compileInternal but =
rather onCompileInternal instead; the same problem does not exist with =
the execute methods.
=20
BTW, SqlUpdate has never had final execute methods, so it's also =
consistent to not have them final in SqlQuery too. And I don't intend to =
change JdbcDaoSupport: That is just a simple convenience class, so if =
anyone needs some other base class, feel free to create your own. As =
JdbcDaoSupport is a base class for application classes, it's appropriate =
to offer as few methods for overriding as possible in the first place.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Choy Rim
Gesendet: Sa 03.01.2004 03:48
An: spr...@li...
Betreff: RE: [Springframework-developer] Re: Final methods in SqlQuery



Juergen,

Let's not get carried away here. I don't think it's such a good idea to
make these methods non-final. If I'm not mistaken, some of these classes
implement the TEMPLATE METHOD pattern. If that is the case, then it is
recommended to make the template method final. Sticking to this
convention may sound dogmatic but IMHO it will maintain the integrity of
the code. Extension points will remain clear. Invariants will be
maintained. Etc., ...

Adding an extension point or hook like doPreprocess() that is called by
execute() would be more consistent with the TEMPLATE METHOD pattern. If
the number of hooks becomes unwieldy, perhaps introduce the STRATEGY
pattern.

I understand that restrictions ("tie my hands") tend to be unpopular.
But we'd be better off evangelizing the benefits of the pattern, than
introducing cracks in the integrity of the code base.

IMHO one of the strengths of the spring framework is the clarity of its
design. I hope we can find a compromise that provides both 80-20-freedom
and yet continues to maintain the clarity of design.

--mark

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of j?gen h?ler [werk3AT]
Sent: Friday, January 02, 2004 5:45 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: Final methods in SqlQuery

This sounds plausible to me. I'll look into turning appropriate methods
non-final today, if noone objects.

The original rationale behind the final methods is to offer clear
extension points: Subclassers should know which methods are intended for
overriding and which are not, avoiding confusion. But I agree that this
doesn't work for cases that the framework developers didn't expect, so
it's probably better to not use final for methods where there is no
clear general extension hook. I've already applied the same principle in
the bean factory implementation hierarchy.

Juergen


________________________________

Von: spr...@li... im Auftrag
von David Heimann
Gesendet: Fr 02.01.2004 02:24
An: spr...@li...
Betreff: [Springframework-developer] Re: Final methods in SqlQuery



Ken and developers,

I have a business rule in my system that all the data be
stored in upper case in the database.  This sugests the
following design:

1)This is a business rule and so should be in the model
layer rather than the presentation layer

2)The code to upper case the data should be centralized.
Requiring each developer to upper case the data before
calling the execute or update methods duplicates code and
is error prone.  (the PetClinic sample has around 12
execute or update calls, each of which would need to be
prefaced by upper casing code)

3)This suggests a design where I extend SqlUpdate and
SqlQuery and override the SqlUpdate.update and
SqlQuery.execute methods, for example

public abstract SqlQueryUpper extends SqlQuery
{
        public List execute(Object[] parameters, Map context)
throws DataAccessException {
                //upper case string parameters
                for(int i =3D 0;i<parameters.length;i++)
                {
                        Object p =3D parameters[i];
                        if(p instanceof java.lang.String)
                        {
                                parameters[i] =3D p.toUpper();
                        }
                }
                return super.execute(parameters, context);
        }
}

Of course, I could create my own method with a different
name such as
        ...
        public List executeUpper(Object[] parameters, Map context)
throws DataAccessException
        {
                (same as above)
        }

But if I do that, then I
        1)Still have the original SqlQuery.execute method out
there which no one should use.
        2)Do not have all the other signatures available such as
SqlQuery.execute(int), SqlQuery.execute(String) etc because
they all still go through the original execute method.

Finally, my problem is an example of something not included
or anticipated by the developers of the Spring Framework.
There is no built in Spring 'auto-upper' option nor should
there be.  Putting final on methods stops me from adding it
myself, making the framework unextendable in this area.
IMHO final methods should be few and far between in an
extensible framework and I do not think they are called for
here.

Sincerely,

David Heimann

>David,
 >
> I don't  understand why you think it would be nice to
***override*** it.
> The execute method does all the IOC hard stuff for you.
If you override
> it, you have to do this yourself, adding unnecessary
duplication. That's
> why it's final. The same goes for SqlUpdate.update. In
your example, why
> not simply manipulate the parameters to your heart's
content before
> passing them to the execute method ?
>
> Ken
>
> Heimann, David X - San Mateo, CA wrote:
>
> > Developers,
> >
> > Could you change
> >
> > *public** final* List execute(*final* Object[]
parameters, Map context)
> > {
> > ...
> > }
> >
> > in org.springframework.jdbc.object.SqlQuery to not be
final ?  It
> > would be nice to overload it, for example to change all
parameters to
> > upper case before executing.  The similar update method
in SqlUpdate
> > is not final.  Why be final at all ?
> >
> > David Heimann
> >


__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys
admin.
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys
admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Re: RE: Re: Final methods in SqlQuery

[David H. <fog...@ya...>]

Mark and Developers

Certainly it could be done with extension points, changing

	public final List execute(final Object[] parameters, Map
context) throws DataAccessException {
		validateParameters(parameters);
		ResultReader rr = newResultReader(this.rowsExpected,
parameters, context);
	
getJdbcTemplate().query(newPreparedStatementCreator(parameters),
rr);
		return rr.getResults();
	}

to

	public final List execute(Object[] parameters, Map
context) throws DataAccessException {
		//Pre execute extension point
		preExecute(parameters, context);
		validateParameters(parameters);
		ResultReader rr = newResultReader(this.rowsExpected,
parameters, context);
	
getJdbcTemplate().query(newPreparedStatementCreator(parameters),
rr);
		List results = rr.getResults();
		//post execute extension point
		postExecute(parameters, context, results);
		return results;
	}

	protected preExecute(Object[] parameters, Map context)
	{
	}

	protected postExecute(Object[] parameters, Map context,
List results)
	{
	}

But it seems to reduce the clarity of the codebase to add
extension points to a method with 4 lines of code,
especially when the extension points are 'pre everything in
the method' and 'post everything in the method' and the
method accomplishes a complete task.  Extending the class
and calling super.execute(...) seems a resonable way to
create this functionality, and it is a familiar idiom for
doing so.  IMHO the SqlQuery.execute() method here is not
so much providing IOC as it is using IOC provided by a
lower level and so more suited for overriding than
extension points.

Sincerely,

David Heimann





>+1 on that one.
> 
> Regards,
> Dmitriy.
> 
> ----- Original Message -----
> From: Choy Rim <choy@ny...>
> Date: Friday, January 2, 2004 9:48 pm
> Subject: RE: [Springframework-developer] Re: Final
methods in SqlQuery
 
 > Juergen,
 > 
 > Let's not get carried away here. I don't think it's such
a good 
 > idea to
 > make these methods non-final. If I'm not mistaken, some
of these 
 > classesimplement the TEMPLATE METHOD pattern. If that is
the case, 
 > then it is
 > recommended to make the template method final. Sticking
to this
 > convention may sound dogmatic but IMHO it will maintain
the 
 > integrity of
 > the code. Extension points will remain clear. Invariants
will be
 > maintained. Etc., ...
 > 
 > Adding an extension point or hook like doPreprocess()
that is 
 > called by
 > execute() would be more consistent with the TEMPLATE
METHOD 
 > pattern. If
 > the number of hooks becomes unwieldy, perhaps introduce
the STRATEGY
 > pattern.
 > 
 > I understand that restrictions ("tie my hands") tend to
be unpopular.
 > But we'd be better off evangelizing the benefits of the
pattern, than
 > introducing cracks in the integrity of the code base.
 > 
 > IMHO one of the strengths of the spring framework is the
clarity 
 > of its
 > design. I hope we can find a compromise that provides
both 80-20-
 > freedomand yet continues to maintain the clarity of
design.
 > 
 > --mark
 > 
 > -----Original Message-----
 > From: springframework-developer-admin@li...
 > [springframework-developer-admin@li...] On Behalf
 > Of j?gen h?ler [werk3AT]
 > Sent: Friday, January 02, 2004 5:45 AM
 > To: springframework-developer@li...
 > Subject: Re: [Springframework-developer] Re: Final
methods in SqlQuery
 > 
 > This sounds plausible to me. I'll look into turning
appropriate 
 > methodsnon-final today, if noone objects.
 > 
 > The original rationale behind the final methods is to
offer clear
 > extension points: Subclassers should know which methods
are 
 > intended for
 > overriding and which are not, avoiding confusion. But I
agree that 
 > thisdoesn't work for cases that the framework developers
didn't 
 > expect, so
 > it's probably better to not use final for methods where
there is no
 > clear general extension hook. I've already applied the
same 
 > principle in
 > the bean factory implementation hierarchy.
 > 
 > Juergen
 > 
 > 
 > ________________________________
 > 
 > Von: springframework-developer-admin@li... im Auftrag
 > von David Heimann
 > Gesendet: Fr 02.01.2004 02:24
 > An: springframework-developer@li...
 > Betreff: [Springframework-developer] Re: Final methods
in SqlQuery
 > 
 > 
 > 
 > Ken and developers,
 > 
 > I have a business rule in my system that all the data be
 > stored in upper case in the database.  This sugests the
 > following design:
 > 
 > 1)This is a business rule and so should be in the model
 > layer rather than the presentation layer
 > 
 > 2)The code to upper case the data should be centralized.
 > Requiring each developer to upper case the data before
 > calling the execute or update methods duplicates code
and
 > is error prone.  (the PetClinic sample has around 12
 > execute or update calls, each of which would need to be
 > prefaced by upper casing code)
 > 
 > 3)This suggests a design where I extend SqlUpdate and
 > SqlQuery and override the SqlUpdate.update and
 > SqlQuery.execute methods, for example
 > 
 > public abstract SqlQueryUpper extends SqlQuery
 > {
 >        public List execute(Object[] parameters, Map
context)
 > throws DataAccessException {
 >                //upper case string parameters
 >                for(int i = 0;i<parameters.length;i++)
 >                {
 >                        Object p = parameters[i];
 >                        if(p instanceof java.lang.String)
 >                        {
 >                                parameters[i] =
p.toUpper();
 >                        }
 >                }
 >                return super.execute(parameters,
context);
 >        }
 > }
 > 
 > Of course, I could create my own method with a different
 > name such as
 >        ...
 >        public List executeUpper(Object[] parameters, Map
context)
 > throws DataAccessException
 >        {
 >                (same as above)
 >        }
 > 
 > But if I do that, then I
 >        1)Still have the original SqlQuery.execute method
out
 > there which no one should use.
 >        2)Do not have all the other signatures available
such as
 > SqlQuery.execute(int), SqlQuery.execute(String) etc
because
 > they all still go through the original execute method. 
 > 
 > Finally, my problem is an example of something not
included
 > or anticipated by the developers of the Spring
Framework.
 > There is no built in Spring 'auto-upper' option nor
should
 > there be.  Putting final on methods stops me from adding
it
 > myself, making the framework unextendable in this area.
 > IMHO final methods should be few and far between in an
 > extensible framework and I do not think they are called
for
 > here.
 > 
 > Sincerely,
 > 
 > David Heimann
 > 
 > >David,
 > >
 > > I don't  understand why you think it would be nice to
 > ***override*** it.
 > > The execute method does all the IOC hard stuff for
you.
 > If you override
 > > it, you have to do this yourself, adding unnecessary
 > duplication. That's
 > > why it's final. The same goes for SqlUpdate.update. In
 > your example, why
 > > not simply manipulate the parameters to your heart's
 > content before
 > > passing them to the execute method ?
 > >
 > > Ken
 > > 
 > > Heimann, David X - San Mateo, CA wrote:
 > >
 > > > Developers,
 > > >
 > > > Could you change
 > > >
 > > > *public** final* List execute(*final* Object[]
 > parameters, Map context)
 > > > {
 > > > ...
 > > > }
 > > >
 > > > in org.springframework.jdbc.object.SqlQuery to not
be
 > final ?  It
 > > > would be nice to overload it, for example to change
all
 > parameters to
 > > > upper case before executing.  The similar update
method
 > in SqlUpdate
 > > > is not final.  Why be final at all ?
 > > >
 > > > David Heimann
 > > >


__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003

Re: RE: [Springframework-developer] Re: Final methods in SqlQuery

[Dmitriy K. <dko...@ru...>]

+1 on that one.

Regards,
Dmitriy.

----- Original Message -----
From: Choy Rim <ch...@ny...>
Date: Friday, January 2, 2004 9:48 pm
Subject: RE: [Springframework-developer] Re: Final methods in SqlQuery

> Juergen,
> 
> Let's not get carried away here. I don't think it's such a good 
> idea to
> make these methods non-final. If I'm not mistaken, some of these 
> classesimplement the TEMPLATE METHOD pattern. If that is the case, 
> then it is
> recommended to make the template method final. Sticking to this
> convention may sound dogmatic but IMHO it will maintain the 
> integrity of
> the code. Extension points will remain clear. Invariants will be
> maintained. Etc., ...
> 
> Adding an extension point or hook like doPreprocess() that is 
> called by
> execute() would be more consistent with the TEMPLATE METHOD 
> pattern. If
> the number of hooks becomes unwieldy, perhaps introduce the STRATEGY
> pattern.
> 
> I understand that restrictions ("tie my hands") tend to be unpopular.
> But we'd be better off evangelizing the benefits of the pattern, than
> introducing cracks in the integrity of the code base.
> 
> IMHO one of the strengths of the spring framework is the clarity 
> of its
> design. I hope we can find a compromise that provides both 80-20-
> freedomand yet continues to maintain the clarity of design.
> 
> --mark
> 
> -----Original Message-----
> From: spr...@li...
> [spr...@li...] On Behalf
> Of j?gen h?ler [werk3AT]
> Sent: Friday, January 02, 2004 5:45 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Re: Final methods in SqlQuery
> 
> This sounds plausible to me. I'll look into turning appropriate 
> methodsnon-final today, if noone objects.
> 
> The original rationale behind the final methods is to offer clear
> extension points: Subclassers should know which methods are 
> intended for
> overriding and which are not, avoiding confusion. But I agree that 
> thisdoesn't work for cases that the framework developers didn't 
> expect, so
> it's probably better to not use final for methods where there is no
> clear general extension hook. I've already applied the same 
> principle in
> the bean factory implementation hierarchy.
> 
> Juergen
> 
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag
> von David Heimann
> Gesendet: Fr 02.01.2004 02:24
> An: spr...@li...
> Betreff: [Springframework-developer] Re: Final methods in SqlQuery
> 
> 
> 
> Ken and developers,
> 
> I have a business rule in my system that all the data be
> stored in upper case in the database.  This sugests the
> following design:
> 
> 1)This is a business rule and so should be in the model
> layer rather than the presentation layer
> 
> 2)The code to upper case the data should be centralized.
> Requiring each developer to upper case the data before
> calling the execute or update methods duplicates code and
> is error prone.  (the PetClinic sample has around 12
> execute or update calls, each of which would need to be
> prefaced by upper casing code)
> 
> 3)This suggests a design where I extend SqlUpdate and
> SqlQuery and override the SqlUpdate.update and
> SqlQuery.execute methods, for example
> 
> public abstract SqlQueryUpper extends SqlQuery
> {
>        public List execute(Object[] parameters, Map context)
> throws DataAccessException {
>                //upper case string parameters
>                for(int i = 0;i<parameters.length;i++)
>                {
>                        Object p = parameters[i];
>                        if(p instanceof java.lang.String)
>                        {
>                                parameters[i] = p.toUpper();
>                        }
>                }
>                return super.execute(parameters, context);
>        }
> }
> 
> Of course, I could create my own method with a different
> name such as
>        ...
>        public List executeUpper(Object[] parameters, Map context)
> throws DataAccessException
>        {
>                (same as above)
>        }
> 
> But if I do that, then I
>        1)Still have the original SqlQuery.execute method out
> there which no one should use.
>        2)Do not have all the other signatures available such as
> SqlQuery.execute(int), SqlQuery.execute(String) etc because
> they all still go through the original execute method. 
> 
> Finally, my problem is an example of something not included
> or anticipated by the developers of the Spring Framework.
> There is no built in Spring 'auto-upper' option nor should
> there be.  Putting final on methods stops me from adding it
> myself, making the framework unextendable in this area.
> IMHO final methods should be few and far between in an
> extensible framework and I do not think they are called for
> here.
> 
> Sincerely,
> 
> David Heimann
> 
> >David,
> >
> > I don't  understand why you think it would be nice to
> ***override*** it.
> > The execute method does all the IOC hard stuff for you.
> If you override
> > it, you have to do this yourself, adding unnecessary
> duplication. That's
> > why it's final. The same goes for SqlUpdate.update. In
> your example, why
> > not simply manipulate the parameters to your heart's
> content before
> > passing them to the execute method ?
> >
> > Ken
> > 
> > Heimann, David X - San Mateo, CA wrote:
> >
> > > Developers,
> > >
> > > Could you change
> > >
> > > *public** final* List execute(*final* Object[]
> parameters, Map context)
> > > {
> > > ...
> > > }
> > >
> > > in org.springframework.jdbc.object.SqlQuery to not be
> final ?  It
> > > would be nice to overload it, for example to change all
> parameters to
> > > upper case before executing.  The similar update method
> in SqlUpdate
> > > is not final.  Why be final at all ?
> > >
> > > David Heimann
> > >
> 
> 
> __________________________________
> Do you Yahoo!?
> Find out what made the Top Yahoo! Searches of 2003
> http://search.yahoo.com/top2003
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for
> IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys
> admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for
> IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys
> admin.
> Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=ick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up 
> for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys 
> admin.Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

RE: [Springframework-developer] Re: Final methods in SqlQuery

[Choy R. <ch...@ny...>]

Juergen,

Let's not get carried away here. I don't think it's such a good idea to
make these methods non-final. If I'm not mistaken, some of these classes
implement the TEMPLATE METHOD pattern. If that is the case, then it is
recommended to make the template method final. Sticking to this
convention may sound dogmatic but IMHO it will maintain the integrity of
the code. Extension points will remain clear. Invariants will be
maintained. Etc., ...

Adding an extension point or hook like doPreprocess() that is called by
execute() would be more consistent with the TEMPLATE METHOD pattern. If
the number of hooks becomes unwieldy, perhaps introduce the STRATEGY
pattern.

I understand that restrictions ("tie my hands") tend to be unpopular.
But we'd be better off evangelizing the benefits of the pattern, than
introducing cracks in the integrity of the code base.

IMHO one of the strengths of the spring framework is the clarity of its
design. I hope we can find a compromise that provides both 80-20-freedom
and yet continues to maintain the clarity of design.

--mark

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of j?gen h?ler [werk3AT]
Sent: Friday, January 02, 2004 5:45 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: Final methods in SqlQuery

This sounds plausible to me. I'll look into turning appropriate methods
non-final today, if noone objects.
=20
The original rationale behind the final methods is to offer clear
extension points: Subclassers should know which methods are intended for
overriding and which are not, avoiding confusion. But I agree that this
doesn't work for cases that the framework developers didn't expect, so
it's probably better to not use final for methods where there is no
clear general extension hook. I've already applied the same principle in
the bean factory implementation hierarchy.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag
von David Heimann
Gesendet: Fr 02.01.2004 02:24
An: spr...@li...
Betreff: [Springframework-developer] Re: Final methods in SqlQuery



Ken and developers,

I have a business rule in my system that all the data be
stored in upper case in the database.  This sugests the
following design:

1)This is a business rule and so should be in the model
layer rather than the presentation layer

2)The code to upper case the data should be centralized.
Requiring each developer to upper case the data before
calling the execute or update methods duplicates code and
is error prone.  (the PetClinic sample has around 12
execute or update calls, each of which would need to be
prefaced by upper casing code)

3)This suggests a design where I extend SqlUpdate and
SqlQuery and override the SqlUpdate.update and
SqlQuery.execute methods, for example

public abstract SqlQueryUpper extends SqlQuery
{
        public List execute(Object[] parameters, Map context)
throws DataAccessException {
                //upper case string parameters
                for(int i =3D 0;i<parameters.length;i++)
                {
                        Object p =3D parameters[i];
                        if(p instanceof java.lang.String)
                        {
                                parameters[i] =3D p.toUpper();
                        }
                }
                return super.execute(parameters, context);
        }
}

Of course, I could create my own method with a different
name such as
        ...
        public List executeUpper(Object[] parameters, Map context)
throws DataAccessException
        {
                (same as above)
        }

But if I do that, then I
        1)Still have the original SqlQuery.execute method out
there which no one should use.
        2)Do not have all the other signatures available such as
SqlQuery.execute(int), SqlQuery.execute(String) etc because
they all still go through the original execute method.=20

Finally, my problem is an example of something not included
or anticipated by the developers of the Spring Framework.
There is no built in Spring 'auto-upper' option nor should
there be.  Putting final on methods stops me from adding it
myself, making the framework unextendable in this area.
IMHO final methods should be few and far between in an
extensible framework and I do not think they are called for
here.

Sincerely,

David Heimann

>David,
 >
> I don't  understand why you think it would be nice to
***override*** it.
> The execute method does all the IOC hard stuff for you.
If you override
> it, you have to do this yourself, adding unnecessary
duplication. That's
> why it's final. The same goes for SqlUpdate.update. In
your example, why
> not simply manipulate the parameters to your heart's
content before
> passing them to the execute method ?
>
> Ken
>=20
> Heimann, David X - San Mateo, CA wrote:
>
> > Developers,
> >
> > Could you change
> >
> > *public** final* List execute(*final* Object[]
parameters, Map context)
> > {
> > ...
> > }
> >
> > in org.springframework.jdbc.object.SqlQuery to not be
final ?  It
> > would be nice to overload it, for example to change all
parameters to
> > upper case before executing.  The similar update method
in SqlUpdate
> > is not final.  Why be final at all ?
> >
> > David Heimann
> >


__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys
admin.
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys
admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: Final methods in SqlQuery

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

I don't object to making more methods non-final, as people do ask for thi=
s.

However, in general I think there are better extension mechanisms than
overriding methods in Spring in many cases. I don't particularly like
overriding concrete methods as a means of extensibility.

Why would you want to subclass JdbcTemplate?

Why would you override JdbcDaoSupport's methods?

I'm not being sarcastic, I'm just curious...

Regards,
Rod

----- Original Message -----=20
From: "Michael Young" <sp...@on...>
To: <spr...@li...>
Sent: Friday, January 02, 2004 5:42 PM
Subject: Re: [Springframework-developer] Re: Final methods in SqlQuery


Juergen,

Can you do the same for other classes as well?  Classes such as
JdbcTemplate and JdbcDaoSupport.  Someone also mentioned the
abstract wizard form controller as well.  See messages previously
posted either here or in users.

Thanks!  /Michael.

On Friday, Jan-02-2004 02:45 AM (PST) jue...@we... (j=FCrg=
en
h=F6ller [werk3AT]) wrote:

> This sounds plausible to me. I'll look into turning appropriate methods
non-final today, if noone objects.
>
> The original rationale behind the final methods is to offer clear
extension points: Subclassers should know which methods are intended for
overriding and which are not, avoiding confusion. But I agree that this
doesn't work for cases that the framework developers didn't expect, so it=
's
probably better to not use final for methods where there is no clear gene=
ral
extension hook. I've already applied the same principle in the bean facto=
ry
implementation hierarchy.
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag v=
on
David Heimann
> Gesendet: Fr 02.01.2004 02:24
> An: spr...@li...
> Betreff: [Springframework-developer] Re: Final methods in SqlQuery
>
>
>
> Ken and developers,
>
> I have a business rule in my system that all the data be
> stored in upper case in the database.  This sugests the
> following design:
>
> 1)This is a business rule and so should be in the model
> layer rather than the presentation layer
>
> 2)The code to upper case the data should be centralized.
> Requiring each developer to upper case the data before
> calling the execute or update methods duplicates code and
> is error prone.  (the PetClinic sample has around 12
> execute or update calls, each of which would need to be
> prefaced by upper casing code)
>
> 3)This suggests a design where I extend SqlUpdate and
> SqlQuery and override the SqlUpdate.update and
> SqlQuery.execute methods, for example
>
> public abstract SqlQueryUpper extends SqlQuery
> {
>         public List execute(Object[] parameters, Map context)
> throws DataAccessException {
>                 //upper case string parameters
>                 for(int i =3D 0;i<parameters.length;i++)
>                 {
>                         Object p =3D parameters[i];
>                         if(p instanceof java.lang.String)
>                         {
>                                 parameters[i] =3D p.toUpper();
>                         }
>                 }
>                 return super.execute(parameters, context);
>         }
> }
>
> Of course, I could create my own method with a different
> name such as
>         ...
>         public List executeUpper(Object[] parameters, Map context)
> throws DataAccessException
>         {
>                 (same as above)
>         }
>
> But if I do that, then I
>         1)Still have the original SqlQuery.execute method out
> there which no one should use.
>         2)Do not have all the other signatures available such as
> SqlQuery.execute(int), SqlQuery.execute(String) etc because
> they all still go through the original execute method.
>
> Finally, my problem is an example of something not included
> or anticipated by the developers of the Spring Framework.
> There is no built in Spring 'auto-upper' option nor should
> there be.  Putting final on methods stops me from adding it
> myself, making the framework unextendable in this area.
> IMHO final methods should be few and far between in an
> extensible framework and I do not think they are called for
> here.
>
> Sincerely,
>
> David Heimann
>
> >David,
>  >
> > I don't  understand why you think it would be nice to
> ***override*** it.
> > The execute method does all the IOC hard stuff for you.
> If you override
> > it, you have to do this yourself, adding unnecessary
> duplication. That's
> > why it's final. The same goes for SqlUpdate.update. In
> your example, why
> > not simply manipulate the parameters to your heart's
> content before
> > passing them to the execute method ?
> >
> > Ken
> >
> > Heimann, David X - San Mateo, CA wrote:
> >
> > > Developers,
> > >
> > > Could you change
> > >
> > > *public** final* List execute(*final* Object[]
> parameters, Map context)
> > > {
> > > ...
> > > }
> > >
> > > in org.springframework.jdbc.object.SqlQuery to not be
> final ?  It
> > > would be nice to overload it, for example to change all
> parameters to
> > > upper case before executing.  The similar update method
> in SqlUpdate
> > > is not final.  Why be final at all ?
> > >
> > > David Heimann
> > >
>
>
> __________________________________
> Do you Yahoo!?
> Find out what made the Top Yahoo! Searches of 2003
> http://search.yahoo.com/top2003
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM=
's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admi=
n.
> Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM=
's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admi=
n.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: Final methods in SqlQuery

[Michael Y. <sp...@on...>]

Juergen,

Can you do the same for other classes as well?  Classes such as
JdbcTemplate and JdbcDaoSupport.  Someone also mentioned the
abstract wizard form controller as well.  See messages previously
posted either here or in users.

Thanks!  /Michael.

On Friday, Jan-02-2004 02:45 AM (PST) jue...@we... (j=FCrgen=
 h=F6ller [werk3AT]) wrote:

> This sounds plausible to me. I'll look into turning appropriate methods n=
on-final today, if noone objects.
> =20
> The original rationale behind the final methods is to offer clear extensi=
on points: Subclassers should know which methods are intended for overridin=
g and which are not, avoiding confusion. But I agree that this doesn't work=
 for cases that the framework developers didn't expect, so it's probably be=
tter to not use final for methods where there is no clear general extension=
 hook. I've already applied the same principle in the bean factory implemen=
tation hierarchy.
> =20
> Juergen
> =20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag von=
 David Heimann
> Gesendet: Fr 02.01.2004 02:24
> An: spr...@li...
> Betreff: [Springframework-developer] Re: Final methods in SqlQuery
>=20
>=20
>=20
> Ken and developers,
>=20
> I have a business rule in my system that all the data be
> stored in upper case in the database.  This sugests the
> following design:
>=20
> 1)This is a business rule and so should be in the model
> layer rather than the presentation layer
>=20
> 2)The code to upper case the data should be centralized.
> Requiring each developer to upper case the data before
> calling the execute or update methods duplicates code and
> is error prone.  (the PetClinic sample has around 12
> execute or update calls, each of which would need to be
> prefaced by upper casing code)
>=20
> 3)This suggests a design where I extend SqlUpdate and
> SqlQuery and override the SqlUpdate.update and
> SqlQuery.execute methods, for example
>=20
> public abstract SqlQueryUpper extends SqlQuery
> {
>         public List execute(Object[] parameters, Map context)
> throws DataAccessException {
>                 //upper case string parameters
>                 for(int i =3D 0;i<parameters.length;i++)
>                 {
>                         Object p =3D parameters[i];
>                         if(p instanceof java.lang.String)
>                         {
>                                 parameters[i] =3D p.toUpper();
>                         }
>                 }
>                 return super.execute(parameters, context);
>         }
> }
>=20
> Of course, I could create my own method with a different
> name such as
>         ...
>         public List executeUpper(Object[] parameters, Map context)
> throws DataAccessException
>         {
>                 (same as above)
>         }
>=20
> But if I do that, then I
>         1)Still have the original SqlQuery.execute method out
> there which no one should use.
>         2)Do not have all the other signatures available such as
> SqlQuery.execute(int), SqlQuery.execute(String) etc because
> they all still go through the original execute method.=20
>=20
> Finally, my problem is an example of something not included
> or anticipated by the developers of the Spring Framework.
> There is no built in Spring 'auto-upper' option nor should
> there be.  Putting final on methods stops me from adding it
> myself, making the framework unextendable in this area.
> IMHO final methods should be few and far between in an
> extensible framework and I do not think they are called for
> here.
>=20
> Sincerely,
>=20
> David Heimann
>=20
> >David,
>  >
> > I don't  understand why you think it would be nice to
> ***override*** it.
> > The execute method does all the IOC hard stuff for you.
> If you override
> > it, you have to do this yourself, adding unnecessary
> duplication. That's
> > why it's final. The same goes for SqlUpdate.update. In
> your example, why
> > not simply manipulate the parameters to your heart's
> content before
> > passing them to the execute method ?
> >
> > Ken
> >=20
> > Heimann, David X - San Mateo, CA wrote:
> >
> > > Developers,
> > >
> > > Could you change
> > >
> > > *public** final* List execute(*final* Object[]
> parameters, Map context)
> > > {
> > > ...
> > > }
> > >
> > > in org.springframework.jdbc.object.SqlQuery to not be
> final ?  It
> > > would be nice to overload it, for example to change all
> parameters to
> > > upper case before executing.  The similar update method
> in SqlUpdate
> > > is not final.  Why be final at all ?
> > >
> > > David Heimann
> > >
>=20
>=20
> __________________________________
> Do you Yahoo!?
> Find out what made the Top Yahoo! Searches of 2003
> http://search.yahoo.com/top2003
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: Final methods in SqlQuery

[Michael Y. <sp...@on...>]

I totally agree with you David.

I have similar sentiments regarding methods being final in Spring
Framework.  I am very happy with pretty much everything in Spring
Framework except this issue, and I hope the Spring Framework 
developers can consider this issue seriously.  

Simply put, I don't want my favorite framework to tie my hands,
and prevent me from convincing others to adopt it.

/Michael.

On Thursday, Jan-01-2004 17:24 PM (PST) fog...@ya... (David Heimann) wrote:

> Ken and developers,
> 
> I have a business rule in my system that all the data be
> stored in upper case in the database.  This sugests the
> following design:
> 
> 1)This is a business rule and so should be in the model
> layer rather than the presentation layer
> 
> 2)The code to upper case the data should be centralized. 
> Requiring each developer to upper case the data before
> calling the execute or update methods duplicates code and
> is error prone.  (the PetClinic sample has around 12
> execute or update calls, each of which would need to be
> prefaced by upper casing code)
> 
> 3)This suggests a design where I extend SqlUpdate and
> SqlQuery and override the SqlUpdate.update and
> SqlQuery.execute methods, for example
> 
> public abstract SqlQueryUpper extends SqlQuery
> {
> 	public List execute(Object[] parameters, Map context)
> throws DataAccessException {
>                 //upper case string parameters
> 		for(int i = 0;i<parameters.length;i++)
> 		{
> 			Object p = parameters[i];
> 			if(p instanceof java.lang.String)
> 			{
> 				parameters[i] = p.toUpper();
> 			}
> 		}
> 		return super.execute(parameters, context);
> 	}
> }
> 
> Of course, I could create my own method with a different
> name such as 
> 	...
> 	public List executeUpper(Object[] parameters, Map context)
> throws DataAccessException
> 	{
> 		(same as above)
> 	}
> 
> But if I do that, then I
> 	1)Still have the original SqlQuery.execute method out
> there which no one should use.
> 	2)Do not have all the other signatures available such as
> SqlQuery.execute(int), SqlQuery.execute(String) etc because
> they all still go through the original execute method.  
> 
> Finally, my problem is an example of something not included
> or anticipated by the developers of the Spring Framework. 
> There is no built in Spring 'auto-upper' option nor should
> there be.  Putting final on methods stops me from adding it
> myself, making the framework unextendable in this area.
> IMHO final methods should be few and far between in an
> extensible framework and I do not think they are called for
> here.
> 
> Sincerely,
> 
> David Heimann
> 
> >David,
>  >
> > I don't  understand why you think it would be nice to
> ***override*** it. 
> > The execute method does all the IOC hard stuff for you.
> If you override 
> > it, you have to do this yourself, adding unnecessary
> duplication. That's 
> > why it's final. The same goes for SqlUpdate.update. In
> your example, why 
> > not simply manipulate the parameters to your heart's
> content before 
> > passing them to the execute method ?
> > 
> > Ken
> >  
> > Heimann, David X - San Mateo, CA wrote:
> > 
> > > Developers,
> > >
> > > Could you change
> > >
> > > *public** final* List execute(*final* Object[]
> parameters, Map context)
> > > {
> > > ...
> > > }
> > >
> > > in org.springframework.jdbc.object.SqlQuery to not be
> final ?  It 
> > > would be nice to overload it, for example to change all
> parameters to 
> > > upper case before executing.  The similar update method
> in SqlUpdate 
> > > is not final.  Why be final at all ?
> > >
> > > David Heimann
> > >
> 
> 
> __________________________________
> Do you Yahoo!?
> Find out what made the Top Yahoo! Searches of 2003
> http://search.yahoo.com/top2003
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] 1.0 M4 ready for release

[Steven S. <ste...@ip...>]

On Friday 02 January 2004 18:00, Rod Johnson wrote:
> > Is Spring now shipping with iBATIS rather than it's own jdbc layer?
>
> No. iBATIS is supported out of the box as another data access choice, along
> with Spring JDBC, Hibernate and JDO. Remember that one of Spring's goals is
> to enable DAO interfaces to be independent of data access technology, using
> Spring's technology-independent exception hierarchy. Thus it makes sense to
> support iBATIS as a mature and popular data access technology.
>
> Spring JDBC is still a core part of Spring, and there are significant
> enhancements to it in M4. Unlike iBATIS it requires no XML configuration.
> It gives total power over SQL, unique stored procedure capabilities etc.
>
> iBATIS is also a good SQL-oriented data access layer, but it has different
> strengths and weaknesses.

That's nice, Rod. Thanks for clearing it up.

Re: [Springframework-developer] Re: Final methods in SqlQuery

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

This sounds plausible to me. I'll look into turning appropriate methods =
non-final today, if noone objects.
=20
The original rationale behind the final methods is to offer clear =
extension points: Subclassers should know which methods are intended for =
overriding and which are not, avoiding confusion. But I agree that this =
doesn't work for cases that the framework developers didn't expect, so =
it's probably better to not use final for methods where there is no =
clear general extension hook. I've already applied the same principle in =
the bean factory implementation hierarchy.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von David Heimann
Gesendet: Fr 02.01.2004 02:24
An: spr...@li...
Betreff: [Springframework-developer] Re: Final methods in SqlQuery



Ken and developers,

I have a business rule in my system that all the data be
stored in upper case in the database.  This sugests the
following design:

1)This is a business rule and so should be in the model
layer rather than the presentation layer

2)The code to upper case the data should be centralized.
Requiring each developer to upper case the data before
calling the execute or update methods duplicates code and
is error prone.  (the PetClinic sample has around 12
execute or update calls, each of which would need to be
prefaced by upper casing code)

3)This suggests a design where I extend SqlUpdate and
SqlQuery and override the SqlUpdate.update and
SqlQuery.execute methods, for example

public abstract SqlQueryUpper extends SqlQuery
{
        public List execute(Object[] parameters, Map context)
throws DataAccessException {
                //upper case string parameters
                for(int i =3D 0;i<parameters.length;i++)
                {
                        Object p =3D parameters[i];
                        if(p instanceof java.lang.String)
                        {
                                parameters[i] =3D p.toUpper();
                        }
                }
                return super.execute(parameters, context);
        }
}

Of course, I could create my own method with a different
name such as
        ...
        public List executeUpper(Object[] parameters, Map context)
throws DataAccessException
        {
                (same as above)
        }

But if I do that, then I
        1)Still have the original SqlQuery.execute method out
there which no one should use.
        2)Do not have all the other signatures available such as
SqlQuery.execute(int), SqlQuery.execute(String) etc because
they all still go through the original execute method.=20

Finally, my problem is an example of something not included
or anticipated by the developers of the Spring Framework.
There is no built in Spring 'auto-upper' option nor should
there be.  Putting final on methods stops me from adding it
myself, making the framework unextendable in this area.
IMHO final methods should be few and far between in an
extensible framework and I do not think they are called for
here.

Sincerely,

David Heimann

>David,
 >
> I don't  understand why you think it would be nice to
***override*** it.
> The execute method does all the IOC hard stuff for you.
If you override
> it, you have to do this yourself, adding unnecessary
duplication. That's
> why it's final. The same goes for SqlUpdate.update. In
your example, why
> not simply manipulate the parameters to your heart's
content before
> passing them to the execute method ?
>
> Ken
>=20
> Heimann, David X - San Mateo, CA wrote:
>
> > Developers,
> >
> > Could you change
> >
> > *public** final* List execute(*final* Object[]
parameters, Map context)
> > {
> > ...
> > }
> >
> > in org.springframework.jdbc.object.SqlQuery to not be
final ?  It
> > would be nice to overload it, for example to change all
parameters to
> > upper case before executing.  The similar update method
in SqlUpdate
> > is not final.  Why be final at all ?
> >
> > David Heimann
> >


__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] 1.0 M4 ready for release

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

> Is Spring now shipping with iBATIS rather than it's own jdbc layer?

No. iBATIS is supported out of the box as another data access choice, along
with Spring JDBC, Hibernate and JDO. Remember that one of Spring's goals is
to enable DAO interfaces to be independent of data access technology, using
Spring's technology-independent exception hierarchy. Thus it makes sense to
support iBATIS as a mature and popular data access technology.

Spring JDBC is still a core part of Spring, and there are significant
enhancements to it in M4. Unlike iBATIS it requires no XML configuration. It
gives total power over SQL, unique stored procedure capabilities etc.

iBATIS is also a good SQL-oriented data access layer, but it has different
strengths and weaknesses.

Regards,
Rod

[Springframework-developer] Re: Final methods in SqlQuery

[David H. <fog...@ya...>]

Ken and developers,

I have a business rule in my system that all the data be
stored in upper case in the database.  This sugests the
following design:

1)This is a business rule and so should be in the model
layer rather than the presentation layer

2)The code to upper case the data should be centralized. 
Requiring each developer to upper case the data before
calling the execute or update methods duplicates code and
is error prone.  (the PetClinic sample has around 12
execute or update calls, each of which would need to be
prefaced by upper casing code)

3)This suggests a design where I extend SqlUpdate and
SqlQuery and override the SqlUpdate.update and
SqlQuery.execute methods, for example

public abstract SqlQueryUpper extends SqlQuery
{
	public List execute(Object[] parameters, Map context)
throws DataAccessException {
                //upper case string parameters
		for(int i = 0;i<parameters.length;i++)
		{
			Object p = parameters[i];
			if(p instanceof java.lang.String)
			{
				parameters[i] = p.toUpper();
			}
		}
		return super.execute(parameters, context);
	}
}

Of course, I could create my own method with a different
name such as 
	...
	public List executeUpper(Object[] parameters, Map context)
throws DataAccessException
	{
		(same as above)
	}

But if I do that, then I
	1)Still have the original SqlQuery.execute method out
there which no one should use.
	2)Do not have all the other signatures available such as
SqlQuery.execute(int), SqlQuery.execute(String) etc because
they all still go through the original execute method.  

Finally, my problem is an example of something not included
or anticipated by the developers of the Spring Framework. 
There is no built in Spring 'auto-upper' option nor should
there be.  Putting final on methods stops me from adding it
myself, making the framework unextendable in this area.
IMHO final methods should be few and far between in an
extensible framework and I do not think they are called for
here.

Sincerely,

David Heimann

>David,
 >
> I don't  understand why you think it would be nice to
***override*** it. 
> The execute method does all the IOC hard stuff for you.
If you override 
> it, you have to do this yourself, adding unnecessary
duplication. That's 
> why it's final. The same goes for SqlUpdate.update. In
your example, why 
> not simply manipulate the parameters to your heart's
content before 
> passing them to the execute method ?
> 
> Ken
>  
> Heimann, David X - San Mateo, CA wrote:
> 
> > Developers,
> >
> > Could you change
> >
> > *public** final* List execute(*final* Object[]
parameters, Map context)
> > {
> > ...
> > }
> >
> > in org.springframework.jdbc.object.SqlQuery to not be
final ?  It 
> > would be nice to overload it, for example to change all
parameters to 
> > upper case before executing.  The similar update method
in SqlUpdate 
> > is not final.  Why be final at all ?
> >
> > David Heimann
> >


__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003

Re: [Springframework-developer] 1.0 M4 ready for release

[Steven S. <ste...@ip...>]

Is Spring now shipping with iBATIS rather than it's own jdbc layer?

[Springframework-developer] 1.0 M4 ready for release

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

Hi everybody,
=20
First of all, a happy new year! It's been a great year 2003, =
particularly considering that the Spring Framework project didn't even =
exist 12 months ago (we'll celebrate first birthday in February). Of =
course, the framework version that came with Rod's book was already =
there: But we've seen massive refinement of the framework since, even =
exploring completely new areas like AOP support and transaction =
management, and have attracted a significant number of users (with about =
3000 downloads per release since 1.0 M1). I'd like to thank everybody =
for their contributions, no matter what kind, in what area, and to what =
extent!
=20
I've just finished my preparations of our upcoming release 1.0 M4. In =
good old Spring Framework tradition, a last minute change in the core =
has sneaked in: I've introduced the core.io package with its Resource =
interface and out-of-the-box implementations ClassPathResource, =
FileSystemResource, etc. It's used in the BeanDefinitionRegistry area, =
and also for all former "configLocation" Strings - they are all of type =
Resource now. Thanks to an automatically registered PropertyEditor, =
specifying String paths in bean definitions works just like before, but =
the receiving beans do not have to be ApplicationContextAware anymore to =
be able to resolve resource locations in a generic way.
=20
As most people have already found out, 1.0 M4 introduces our version of =
Clinton Begin's JPetStore, with a Spring-managed middle tier that =
leverages our new iBATIS Database Layer integration, and alternative =
Spring Web MVC and Struts web tiers. A recent addition is remoting =
support: The out-of-the-box JPetStore illustrates remoting via Hessian, =
Burlap, RMI, and our new JAX-RPC support via Axis. Like Clinton's =
original version did with Axis, we export an OrderService. An included =
OrderServiceClient invokes the OrderService to show an order by number, =
via all configured protocols. This should work without hassle via the =
included Ant scripts and the readme.
=20
I'll release 1.0 M4 tomorrow night, sort of a new year's present for the =
Spring community ;-) Everybody who has some time left, please give the =
current CVS contents a try, particularly "playing user": Generate a =
release zip, unzip it, build the samples, deploy the samples. Note that =
as of 1.0 M4, there are two release zips: "spring-framework-1.0-m4" with =
everything but third-party libraries (~8 MB), and =
"spring-framework-1.0-m4-with-dependencies" which includes all libraries =
that are required for building the samples and the framework itself =
(~16.8 MB). Both distributions ship with build scripts and all sources =
and tests.
=20
Regards,
Juergen

Re: [Springframework-developer] Final methods in SqlQuery

[Ken K. <kk...@kk...>]

David,

I don't  understand why you think it would be nice to ***override*** it. 
The execute method does all the IOC hard stuff for you. If you override 
it, you have to do this yourself, adding unnecessary duplication. That's 
why it's final. The same goes for SqlUpdate.update. In your example, why 
not simply manipulate the parameters to your heart's content before 
passing them to the execute method ?

Ken
 
Heimann, David X - San Mateo, CA wrote:

> Developers,
>
> Could you change
>
> *public** final* List execute(*final* Object[] parameters, Map context)
> {
> ...
> }
>
> in org.springframework.jdbc.object.SqlQuery to not be final ?  It 
> would be nice to overload it, for example to change all parameters to 
> upper case before executing.  The similar update method in SqlUpdate 
> is not final.  Why be final at all ?
>
> David Heimann
>

[Springframework-developer] Final methods in SqlQuery

[Heimann, D. X - S. M. C. <dav...@us...>]

Developers,

Could you change

public final List execute(final Object[] parameters, Map context)
{
...
}

in org.springframework.jdbc.object.SqlQuery to not be final ?  It would
be nice to overload it, for example to change all parameters to upper
case before executing.  The similar update method in SqlUpdate is not
final.  Why be final at all ?

David Heimann

Re: [Springframework-developer] New feature

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

I've renamed the package org.springframework.web.servlet.handler.metadata
for consistency with other attribute usage, and because "commonsattributes"
was an inelegant package name.

----- Original Message ----- 
From: "Rod Johnson" <rod...@in...>
To: <spr...@li...>
Sent: Wednesday, December 24, 2003 5:30 PM
Subject: [Springframework-developer] New feature


> All,
>
> I've added a feature that should be useful in simple web applications.
>
> Instead of defining all controller beans in the servlet XML file, I've
added
> a HandlerMapping implementation that automatically adds to the servlet's
> bean factory all controllers having a PathMap attribute (see below for an
> example of the source syntax). The PathMapHandlerMapping automatically
> instantiates a singleton instance of the class, autowiring it via bean
> properties (if there's a no-arg constructor) or constructor args. The
> example shows dependency on a business object, defined in the servlet XML
> file.
>
> All you need to do is add the new PathMapHandlerMapping to your servlet
XML
> file. There's no need to define a bean or mapping for each controller.
>
> Note that multiple attributes per controller class are supported, as shown
> below. It's possible to combine this with the explicit mapping approach,
so
> it scales nicely to more complex requirements.
>
> The attributes implementation is Commons Attributes, as presently used for
> attribute-driven transaction management, another new feature. (See the
> org.springframework.aop.framework.autoproxy.metadata tests, and the
> /attributes directory of the PetStore sample app, for examples of this.)
>
> See the comments in the
> org.springframework.web.servlet.handler.commonsattributes package for
> further details.
>
> If there's enough interest, I'll add an example, including a build script.
>
> Using Commons Attributes really doesn't add much complexity to the build
> script (look at the PetStore /attributes/build.xml file), and the
> precompilation step is very fast. I think source-level attributes are
> potentially very useful in a number of areas.
>
> To support this, I added a registerBeanOfClass() method to
> AutowireCapableBeanFactory, which may be useful to those of you wanted to
> plug in an instance of a new class, benefiting from autowiring.
>
> Regards,
> Rod
>
>
> /**
>  *
>  * Normal comments here. The attribute below will automatically create
>  * a mapping from this path to an instance of this controller (shared for
> all paths).
>  * Must use Commons Attributes compiler.
>  *
>  *
>
@@org.springframework.web.servlet.handler.commonsattributes.PathMap("/foo.cg
> i")
>  *
>
@@org.springframework.web.servlet.handler.commonsattributes.PathMap("/baz.cg
> i")
>  */
> public class FooController extends AbstractController {
>
>  private Cruncher cruncher;
>
>  public FooController(Cruncher cruncher) {
>   this.cruncher = cruncher;
>  }
>
>
>  protected ModelAndView handleRequestInternal(HttpServletRequest arg0,
> HttpServletResponse arg1) throws Exception {
>  // Use cruncher
>   return new ModelAndView("test");
>  }
>
> }
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

[Springframework-developer] Just noticed something

[Patrick B. <spr...@pa...>]

It says on the front of the spring website that M3 will be the last 
milestone release before RC1 and even says there are no more plans for 
any more milestones. But if I remember correctly, it was discussed and 
decided here to have another milestone release (M4). Maybe the text 
should be updated with the lastest plan?

Thanks,
Patrick

Re: [Springframework-developer] Design question on AbstractWizardFormController

[Michael Y. <sp...@on...>]

I've also seen quite many methods being final in Spring,
which I think is unnecessarily restrictive.  One can never
anticipate how things will be used by end users.  The
disadvantages far out-weigh the advantages.

So, please, don't tie users hands too eagerly.

Thanks!  /Michael.

On Wednesday, Dec-24-2003 08:38 AM (PST) sg...@ya... (Steve Gulics) wrote:

> I posted this in the user group but I think its more
> relevant for the developer group. My colleague is
> having a problem with the
> AbstractWizardFormController. He posted the message to
> to the forum only, so I figured I'd also post it here:
> 
> ---------------------------------------------
> IMHO, WizardFormController has some limitations with
> the way it handles pages. For example, In a 5 step
> process, user steps into page 4, and then hit back
> button on his browser, to page 2 and resubmit form.
> the backing-form is still in session, so it will try
> to bind and validate. It get current page which will
> be 4. validation specific to page 2 was not called but
> validation of page 4 was invoked. 
> I would like to rewrite WizardFormController to
> overload getCurrentPage() method, but it was declared
> final. Neither could I use an interceptor to setup the
> pages because getPageSessionAttributeName() is
> specific to the class name. Currently, I have to
> change currentPage variable inside onBindandValidate()
> method to use some param passed in from request. Or I
> could rewrite AbstractWizardFormController to remove
> those final methods. 
> 
> Any suggestions?
> 
> Best Regards, 
> 
> -Leo 
> ---------------------------------------------
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Happy holidays!

[Rajeev K. <Ra...@cu...>]

Happy holidays!+1.

Merry Christmas & Happy Holidays!
  ----- Original Message -----=20
  From: Kopylenko, Dmitry=20
  To: 'spr...@li...'=20
  Sent: Wednesday, December 24, 2003 6:56 AM
  Subject: [Springframework-developer] Happy holidays!


  Everyone,=20

  I would like to take this opportunity to wish everyone a very happy =
and safe holidays. It's been a great year for evolution of Spring =
Framework. I really am proud to be a part of this great team of such =
talented people. I have a feeling the new year would be very positive =
for Spring Framework and continuing trend towards lightweight =
architectures.

  Merry Christmas and Happy New Year!!!=20

  Cheers,=20
  Dmitriy.=20

Re: [Springframework-developer] Happy holidays!

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

Happy Christmas all,

As I'm working on the new book and Spring, I won't be taking much time off.
Christmas Day and Boxing Day if I'm feeling particularly relaxed.

It's been a good first year for Spring!  Over the last 11 months it's gone
from some promising code needing a home to a thriving and popular project.
We've had 10,000 downloads in the last 6 months.

Thanks to all the Spring developers for making this happen. A special thanks
to Juergen, who has made an amazing contribution. We couldn't have done it
without him.

Thanks also to the Spring users: you're also very important, and I hope that
Spring gives you a reliable infrastructure that means you can focus on what
you need to focus on. And that you help us to focus on what's important as
we enhance Spring.

I wish all a happy Christmas and happy and prosperous 2004.

Regards,
Rod

----- Original Message ----- 
From: "Alef Arendsen" <al...@jt...>
To: <spr...@li...>
Sent: Wednesday, December 24, 2003 3:11 PM
Subject: RE: [Springframework-developer] Happy holidays!


> Right on time Dmitriy, I was just heading home, doing my last commits
> and finishing up. However, unfortunately no days off here, just
> Christmas :(...
>
> From a way too rainy Amsterdam, everybody have a merry Christmas and a
> happy New Year...
>
> Alef
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Kopylenko, Dmitry
> Sent: Wednesday, December 24, 2003 3:56 PM
> To: 'spr...@li...'
> Subject: [Springframework-developer] Happy holidays!
>
>
>
> Everyone,
>
> I would like to take this opportunity to wish everyone a very happy and
> safe holidays. It's been a great year for evolution of Spring Framework.
> I really am proud to be a part of this great team of such talented
> people. I have a feeling the new year would be very positive for Spring
> Framework and continuing trend towards lightweight architectures.
>
> Merry Christmas and Happy New Year!!!
>
> Cheers,
> Dmitriy.
>
>

[Springframework-developer] New feature

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

All,

I've added a feature that should be useful in simple web applications.

Instead of defining all controller beans in the servlet XML file, I've added
a HandlerMapping implementation that automatically adds to the servlet's
bean factory all controllers having a PathMap attribute (see below for an
example of the source syntax). The PathMapHandlerMapping automatically
instantiates a singleton instance of the class, autowiring it via bean
properties (if there's a no-arg constructor) or constructor args. The
example shows dependency on a business object, defined in the servlet XML
file.

All you need to do is add the new PathMapHandlerMapping to your servlet XML
file. There's no need to define a bean or mapping for each controller.

Note that multiple attributes per controller class are supported, as shown
below. It's possible to combine this with the explicit mapping approach, so
it scales nicely to more complex requirements.

The attributes implementation is Commons Attributes, as presently used for
attribute-driven transaction management, another new feature. (See the
org.springframework.aop.framework.autoproxy.metadata tests, and the
/attributes directory of the PetStore sample app, for examples of this.)

See the comments in the
org.springframework.web.servlet.handler.commonsattributes package for
further details.

If there's enough interest, I'll add an example, including a build script.

Using Commons Attributes really doesn't add much complexity to the build
script (look at the PetStore /attributes/build.xml file), and the
precompilation step is very fast. I think source-level attributes are
potentially very useful in a number of areas.

To support this, I added a registerBeanOfClass() method to
AutowireCapableBeanFactory, which may be useful to those of you wanted to
plug in an instance of a new class, benefiting from autowiring.

Regards,
Rod


/**
 *
 * Normal comments here. The attribute below will automatically create
 * a mapping from this path to an instance of this controller (shared for
all paths).
 * Must use Commons Attributes compiler.
 *
 *
@@org.springframework.web.servlet.handler.commonsattributes.PathMap("/foo.cg
i")
 *
@@org.springframework.web.servlet.handler.commonsattributes.PathMap("/baz.cg
i")
 */
public class FooController extends AbstractController {

 private Cruncher cruncher;

 public FooController(Cruncher cruncher) {
  this.cruncher = cruncher;
 }


 protected ModelAndView handleRequestInternal(HttpServletRequest arg0,
HttpServletResponse arg1) throws Exception {
 // Use cruncher
  return new ModelAndView("test");
 }

}

[Springframework-developer] Design question on AbstractWizardFormController

[Steve G. <sg...@ya...>]

I posted this in the user group but I think its more
relevant for the developer group. My colleague is
having a problem with the
AbstractWizardFormController. He posted the message to
to the forum only, so I figured I'd also post it here:

---------------------------------------------
IMHO, WizardFormController has some limitations with
the way it handles pages. For example, In a 5 step
process, user steps into page 4, and then hit back
button on his browser, to page 2 and resubmit form.
the backing-form is still in session, so it will try
to bind and validate. It get current page which will
be 4. validation specific to page 2 was not called but
validation of page 4 was invoked. 
I would like to rewrite WizardFormController to
overload getCurrentPage() method, but it was declared
final. Neither could I use an interceptor to setup the
pages because getPageSessionAttributeName() is
specific to the class name. Currently, I have to
change currentPage variable inside onBindandValidate()
method to use some param passed in from request. Or I
could rewrite AbstractWizardFormController to remove
those final methods. 

Any suggestions?

Best Regards, 

-Leo 
---------------------------------------------

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

RE: [Springframework-developer] Happy holidays!

[Alef A. <al...@jt...>]

Right on time Dmitriy, I was just heading home, doing my last commits
and finishing up. However, unfortunately no days off here, just
Christmas :(...
 
From a way too rainy Amsterdam, everybody have a merry Christmas and a
happy New Year...
 
Alef

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Kopylenko, Dmitry
Sent: Wednesday, December 24, 2003 3:56 PM
To: 'spr...@li...'
Subject: [Springframework-developer] Happy holidays!



Everyone, 

I would like to take this opportunity to wish everyone a very happy and
safe holidays. It's been a great year for evolution of Spring Framework.
I really am proud to be a part of this great team of such talented
people. I have a feeling the new year would be very positive for Spring
Framework and continuing trend towards lightweight architectures.

Merry Christmas and Happy New Year!!! 

Cheers, 
Dmitriy.