springframework-developer — Spring Framework developers list

Re: [Springframework-developer] MVC Exception Handling

[Rob B. <rob...@ve...>]

> > By having the exceptions handled at the DispatcherServlet all exceptions
> are
> > handled the same no matter which controller (i.e. place in the web
> workflow)
> > threw the exceptions.  This is great, if I always want ExceptionXYZ to
> show
> > the same view.  If you add a similar capability to
> > org.springframework.web.servlet.mvc.AbstractController then the view /
> > exception mapping could be customized for each.
>
> True, but it definitely makes sense for there to be _one_ default.

I agree.

> It is possible to use an AOP proxy around an individual controller so that
> an exception could be caught and replaced by a ModelAndView object also.
> Although this mechanism is harder to configure and requires knowledge of
> AOP, at least it is possible. (A BeanPostProcessor could make such AOP
> configuration easier.)

You shouldn't need AOP to do this.

> However, there may be a case for extending the ExceptionResolver behaviour
> to individual controllers. How would a controller-specific mapping work?
> Couldn't just be known implementations of ExceptionResolver?
>
> If there is an individual mapping, I wouldn't handle it in
> AbstractController, but in DispatcherServlet, which knows which Controller
> it just used. Then it's not tied to a particular AbstractController.

This is fine.  Mostly I am looking for behavior / feature.  How it is
implemented is secondary.
I thought of the possibility of doing it that way after sending the e-mail.

> > When an exception occurs, the mapping in the AbstractController (or sub
> > class) would be checked first, if no match was found then the mapping in
> the
> > DispatherServlet would be checked.  This would allow for "general" view
/
> > exception mappings to be done in the Dispatcher, while also allowing the
> > AbstractController the opportunity to over-ride the more general view /
> > exception mappings.
> >
> > Alternately, you could move the implementation of the Exception mapping
to
> > the AbstractController, and not have it in the DispatherServlet.  Then
any
> > exception mappings that are specific to that controller would be added
to
> > it, and you could have a separate place to declare any that are
"global".
> > The "global" ones would be added to the end of the ones declared for
that
> > particular AbstractController.  In this way you would still have the
> > "general" view / exception mappings, but the code would only have to be
in
> > the AbstractController.
> But this ties the behavior to AbstractController, thus degrading the
> Controller interface and privileging concrete inheritance.
>
> > Also, I hope the ExceptionResolver you implemented will work for both
> > checked and unchecked exceptions.  In general, an unchecked exception
> would
> > just mean "something really bad and uncontrollable happened" to the
user,
> > but it could be useful to display different error messages to the user
> > depending upon what the exception is.  I.E. if my app throws a runtime
> > exception because a remote system is down (one that is generally flaky
> let's
> > say, and you have no control over it - you know, the kind of stuff you
run
> > into all the time with legacy systems) you may want to tell the user to
> come
> > back and try again in a few minutes.  But if your database server is
down
> > and causing you to bubble up unchecked DB exceptions, you may want to
tell
> > them to come back tomorrow.
> Good point.

Thanks :)

> > Also, it would be great if your ExceptionResolver could not check for
> exact
> > matches to exceptions, but could check instanceof, or isassignable.  In
> that
> > way if I have a whole bunch of exceptions that are subclassed from some
> > common one, and I want all of them to show the same view, I can simply
add
> > the base one to the ExceptionResolver, instead of each one subclassed
from
> > it.  Also, since your ExceptionResolver checks in "order" if I had one
to
> > two of those subclassed exceptions I wanted handled differently, I could
> > register them before the base one.  This would again, allow those to be
> > handled specially, and all the others would follow on to the base one.
> Good points.
>
Thanks again :)

It sounds like Jurgen may have added the functionality I described above:

> A SimpleMappingExceptionResolver allows to map fully qualified exception
> class names (including base classes) to view names, restricting its
mappings
> to a certain list of handlers to be set as bean references to the
"mappedHandlers"
> property. Multiple resolver instances can thus define distinct mappings
for different
> handlers. A generic one without mapped handlers can be the last in the
ordered
> chain, providing fallback resolution.

So does "..including base classes.." mean that it will handle the subclassed
execeptions (instance of or isassignable) as I suggest above?

It sounds as if the capability to have a "default" and "over-ridding"
exception / view mappings has already been added.  : )

I think it would be great if some examples of how to set this up could be
created as well.  You guys are doing an awesome job of adding features /
functionality but I think the documentation is having a more difficult time
of keeping up.

Later
Rob

Re: [Springframework-developer] Classloading issue to resolve before M3 release!

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

Colin,
=20
I've been messing around with that myself for a while, and have also =
modified that ClassLoaderUtils method. I didn't realize that =
ClassLoader.getResourceAsStream does not accept leading slashes! - I =
thought they would work as absolute paths with both =
Class.getResourceAsStream and ClassLoader.getResourceAsStream.
=20
As for the context class loader, you're right that we should be able to =
rely on it in any case anyway. ClassLoaderUtils.getResourceAsStream was =
intended as framework-internal class anyway: Nowhere within the =
framework does loading relative to a framework class make any sense.
=20
It may make sense though to accept leading slashes in paths, as many =
callers don't want to worry about whether the path gets interpreted by =
Class or ClassLoader. For example, Hibernate's Configuration object =
needs the slash, as it loads via =
Environment.class.getResourceAsStream...
=20
To stick to the principle of least surprise, I strongly vote for =
treating "/a/b/myresource" the same as "a/b/myresource". This way, =
callers don't need to worry about the actual loading strategy. They can =
stick to the latter pattern, which is correct for ClassLoader usage, but =
also the former, for example if used to it from Hibernate.
=20
I've just committed that fix. Does that work for you too?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: So 23.11.2003 21:37
An: spr...@li...
Betreff: [Springframework-developer] Classloading issue to resolve =
before M3 release!



I just figured out that we have an issue with the existing code in
ClassloaderUtils.getResourceAsStream, which is used in a number of =
places.

Whoever wrote the original method:

    public static InputStream getResourceAsStream(Class clazz, String
name) {
        ClassLoader ccl =3D =
Thread.currentThread().getContextClassLoader();
        InputStream in =3D null;
        if (ccl !=3D null) {
            in =3D ccl.getResourceAsStream(name);
        }
        if (in =3D=3D null) {
            in =3D clazz.getResourceAsStream(name);
        }
        return in;
    }

did not realize that ClassLoader.getResourceAsStream and
Class.getResourceAsStream do _not_ behave the same way w/regards to the
path this is supplied to them.

Class.getResource, expects to be given a path which is either relative
or absolute to that class, as indicated by a leading /. If there is a
leading slash, it strips off that slash, then passes on the request to
its classloader (ie it calls ClassLoader.getResource). If there is no
slash, it prepends the class package (without a leading slash) to the
specified path, then calls getResource on its classloader.
ClassLoader.getResource, on the other hand, expects that it is given
only absolute paths, _without_ a leading slash. And it will fail if
there is a leading slash.

As such, if the code above is called with a path that is correct for the
call to the context classloader (ie no leading slash), it will be
incorrect for the call to class.getResource (as it will be considered
relative). If it is called with code that is fully qualified/absolute
and correct for the class.getResurce (ie it has a leading slash), it
will always fail for the context classloader getResource call.

Not good... Now this code is used in a number of places, usually with
'/' prepended on the actual path. That is, the code assumes the resource
lookup behaves in a similar fashion to Class.getResource, not
ClassLoader.getResource.  In that respect, the solution of 'least
surpirse' is to treat the context classloader case the same. Even though
it doesn't actually use the class package, if the path doesn't start
with '/', it should be assumed to be relative and added to the specified
resource path. Then this should be documented more explicitly (ie that
it behaves like Class.getResource, not ClassLoader.getResource).

Then, this could be deprecated, and we could make a prefered variation
of getResource which doesn't take a class argument, just a resource
path, and it would simply behave as the existing
ClassLoader.getResource. From what I know, except in Java 1.1, the
context classloader is always safe to use. (do we need Java 1.1
compatibility here?)

Then there is the question of classPackageAsResourcePath, which I
originally wrote, but actually is only really correct when then used to
call the current ClassLoaderUtils.getResourceAsStream or
Class.getResourceAsStream. At a minimum, it should be documented, but I
think it would be cleaner to not have it prepend a leading slash at all,
so it could be fed to the regular ClassLoader.getResource.

Finally, I think it possibly breaks the principal of least surprise that
in most places (like ClassPathXmlApplicationContext or the web xml
application context), we take resource paths and assume that
    a/b/c/d/123.abc
is the same thing as
    /a/b/c/d/123.abc

That is not how ClassLoader.getResource treats things, and that's not
how Class.getResource treats things, so why are we doing it? At a
minimum, it should be strongly documented, but I think it's simpler to
just accept the first form only, to be like classloader resource
specifications in other java apps/libs. This would obviously break some
existing code. In fact, we even usually add the leading / right now
automatically if it's not there.

What do you guys think?






-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] 1.0 M3 prepared

[Trevor C. <pr...@se...>]

Yup, I'm one of the "special" people who override what you'd least expect=
 :)

The suggestion for an M4 is only if we deprecate any methods between M3 a=
nd
RC1 (which could happen).  Since it wouldn't de deprecated in M3, and I'm
assuming we want all deprecations removed before RC1, any signature chang=
es
in the next month (approx) would need to be accounted for.  If not new
deprecations are added, I agree that an M4 isn't required, but that would
indicate a public api freeze based on M3 (which I don't think we're doing=
).

Trevor



-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: November 23, 2003 2:36 PM
To: spr...@li...
Subject: Re: [Springframework-developer] 1.0 M3 prepared


Trevor,

Okidoki, so people have actually overridden the former userObject method.=
..
I'll re-add it as deprecated for M3, delegating to the getCommand method,=
 to
allow for catching it with the compiler. Thanks for reporting this *befor=
e*
the actual M3 release!

I guess migration from deprecated methods to their replacements should be
easy enough if people try M3 before any upcoming RC. Remove all invocatio=
ns
of deprecated methods in M3, then go on to RC1, and you'll be done :-) I
don't think that we need an M4 just for that reason.

Juergen


________________________________

Von: spr...@li... im Auftrag von
Trevor Cook
Gesendet: So 23.11.2003 20:14
An: spr...@li...
Betreff: RE: [Springframework-developer] 1.0 M3 prepared



I've updated our projects to M3, and everything is working properly now.

I did have a slight problem with a few places where I overrided userObjec=
t
(in the SimpleFormController) but no compilation errors were reported (th=
is
took a while to track down).  While the public api won't be frozen until =
the
RC, can I request that any changes to the public apis (method name change=
s
and parameter signatures) are done using the @deprecated tag, and the
deprecated method simply calls the new method.  This will ensure that the
compiler will report problems rather than things compiling ok and failing
properly.  I know Juergen has been doing this with many recent changes, b=
ut
an "across-the-board" policy would make things easier now that the size o=
f
Spring's code and my own has grown so large.  These deprecations can be
removed for the RC (possibly by creating an M4 first with deprecations st=
ill
in, and then an RC immediately with the deprecations removed for the "fin=
al"
public api).

+1 to including source but no libs with samples

Trevor

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: November 22, 2003 7:45 PM
To: spr...@li...
Subject: Re: [Springframework-developer] 1.0 M3 prepared


FYI, I've already committed the renaming from ListableBeanFactoryImpl to
DefaultListableBeanFactory. The web MVC exception stuff will follow
tomorrow.

I've also reworked the Tiles example, using
org.springframework.samples.tiles as package now, and auto-detecting the
Tiles DTD. The FileNameViewController has now moved to
org.springframework.web.servlet.mvc. And I've changed my mind: I do like =
to
include struts-1.1.jar and commons-digester.jar now, for an out-of-the-bo=
x
working example. It already annoys me having to copy those files in for
testing, so consider a new user...

I've just modified our build script to generate two release zips:
spring-framework-1.0-m3.zip (~5600 KB) and
spring-framework-1.0-m3-samples.zip (~5400 KB). Both use
spring-framework-1.0-m3 as path in the zip, for convenient extraction to =
the
same location. The former contains dist, docs, lib/aop-alliance,
lib/jakarta-commons/commons-logging.jar, src, and the readmes, while the
latter contains samples and the additional libs necessary for building an=
d
running them.

What do you think? Should I commit the changed build script and use it fo=
r
the M3 release? I believe it would make sense to split the release into
those two files, as 11 MB is already a bit large for a single distributio=
n.

Juergen


________________________________

Von: spr...@li... im Auftrag von
Colin Sampaleanu
Gesendet: Sa 22.11.2003 00:57
An: spr...@li...
Betreff: Re: [Springframework-developer] 1.0 M3 prepared



j=FCrgen h=F6ller [werk3AT] wrote:

>Everybody,
>
>I've just prepared the release as far as possible: fixed all javadoc
errors, added missing package javadocs, tested the samples. All tests for
shipped components pass on my machine (when running via Ant).
>
>The TLD is now loaded from the spring.jar file, referenced via the defau=
lt
URI http://www.springframework.org/tags (analogous to Struts and JSTL).
BaseCommandController uses setCommandName now, with setBeanName being
deprecated.
>
>Whoever wants to give it a try, fetch the latest CVS contents, run the
release target, and "play user" with spring-framework-1.0-m3.zip (it's in
the target/release directrory): unzip it, browse through the docs, build =
the
sample wars (call ant warfile or warfile.bat) and drop them into your
container's webapps directory.
>
>Alef, could you give the tiles-example a final try? I'm not keen on
including struts.jar in the Spring distribution, so the example should be
prepared for deployment with a manually added struts.jar.
>
>A final note on a further naming issue: I'm not entirely happy with
"ListableBeanFactoryImpl". For example, BeanWrapperImpl is *the*
implementation of BeanWrapper, hardly any chance for alternative
implementations - the interface is rather a simplified API for it. But
ListableBeanFactoryImpl implements ConfigurableListableBeanFactory with
registration methods for a specific properties format; this seems to be a
different case to me.
>
>So wouldn't it be more appropriate to call it "DefaultListableBeanFactor=
y"?
That name change should not affect typical applications anyway but just
"power users" who should be willing to migrate via a simple class name
change. I quite strongly prefer this name to "ListableBeanFactoryImpl",
actually. If we agree on the new name, let's better change it now instead=
 of
in the 1.0 RC phase.
>
>
>
I am ok with the name change, as it does make sense.

Btw, as per another email, I have added a new MethodCallFactoryBean
class. It should be totally ok for this release, as no other code was
touched, and there is a full unit test.

Regards,
Colin




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Classloading issue to resolve before M3 release!

[Colin S. <col...@ex...>]

I just figured out that we have an issue with the existing code in 
ClassloaderUtils.getResourceAsStream, which is used in a number of places.

Whoever wrote the original method:

    public static InputStream getResourceAsStream(Class clazz, String 
name) {
        ClassLoader ccl = Thread.currentThread().getContextClassLoader();
        InputStream in = null;
        if (ccl != null) {
            in = ccl.getResourceAsStream(name);
        }
        if (in == null) {
            in = clazz.getResourceAsStream(name);
        }
        return in;
    }

did not realize that ClassLoader.getResourceAsStream and 
Class.getResourceAsStream do _not_ behave the same way w/regards to the 
path this is supplied to them.

Class.getResource, expects to be given a path which is either relative 
or absolute to that class, as indicated by a leading /. If there is a 
leading slash, it strips off that slash, then passes on the request to 
its classloader (ie it calls ClassLoader.getResource). If there is no 
slash, it prepends the class package (without a leading slash) to the 
specified path, then calls getResource on its classloader. 
ClassLoader.getResource, on the other hand, expects that it is given 
only absolute paths, _without_ a leading slash. And it will fail if 
there is a leading slash.

As such, if the code above is called with a path that is correct for the 
call to the context classloader (ie no leading slash), it will be 
incorrect for the call to class.getResource (as it will be considered 
relative). If it is called with code that is fully qualified/absolute 
and correct for the class.getResurce (ie it has a leading slash), it 
will always fail for the context classloader getResource call.

Not good... Now this code is used in a number of places, usually with 
'/' prepended on the actual path. That is, the code assumes the resource 
lookup behaves in a similar fashion to Class.getResource, not 
ClassLoader.getResource.  In that respect, the solution of 'least 
surpirse' is to treat the context classloader case the same. Even though 
it doesn't actually use the class package, if the path doesn't start 
with '/', it should be assumed to be relative and added to the specified 
resource path. Then this should be documented more explicitly (ie that 
it behaves like Class.getResource, not ClassLoader.getResource).

Then, this could be deprecated, and we could make a prefered variation 
of getResource which doesn't take a class argument, just a resource 
path, and it would simply behave as the existing 
ClassLoader.getResource. From what I know, except in Java 1.1, the 
context classloader is always safe to use. (do we need Java 1.1 
compatibility here?)

Then there is the question of classPackageAsResourcePath, which I 
originally wrote, but actually is only really correct when then used to 
call the current ClassLoaderUtils.getResourceAsStream or 
Class.getResourceAsStream. At a minimum, it should be documented, but I 
think it would be cleaner to not have it prepend a leading slash at all, 
so it could be fed to the regular ClassLoader.getResource.

Finally, I think it possibly breaks the principal of least surprise that 
in most places (like ClassPathXmlApplicationContext or the web xml 
application context), we take resource paths and assume that
    a/b/c/d/123.abc
is the same thing as
    /a/b/c/d/123.abc

That is not how ClassLoader.getResource treats things, and that's not 
how Class.getResource treats things, so why are we doing it? At a 
minimum, it should be strongly documented, but I think it's simpler to 
just accept the first form only, to be like classloader resource 
specifications in other java apps/libs. This would obviously break some 
existing code. In fact, we even usually add the leading / right now 
automatically if it's not there.

What do you guys think?

Re: [Springframework-developer] 1.0 M3 prepared

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

Trevor,
=20
Okidoki, so people have actually overridden the former userObject =
method... I'll re-add it as deprecated for M3, delegating to the =
getCommand method, to allow for catching it with the compiler. Thanks =
for reporting this *before* the actual M3 release!
=20
I guess migration from deprecated methods to their replacements should =
be easy enough if people try M3 before any upcoming RC. Remove all =
invocations of deprecated methods in M3, then go on to RC1, and you'll =
be done :-) I don't think that we need an M4 just for that reason.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Trevor Cook
Gesendet: So 23.11.2003 20:14
An: spr...@li...
Betreff: RE: [Springframework-developer] 1.0 M3 prepared



I've updated our projects to M3, and everything is working properly now.

I did have a slight problem with a few places where I overrided =
userObject
(in the SimpleFormController) but no compilation errors were reported =
(this
took a while to track down).  While the public api won't be frozen until =
the
RC, can I request that any changes to the public apis (method name =
changes
and parameter signatures) are done using the @deprecated tag, and the
deprecated method simply calls the new method.  This will ensure that =
the
compiler will report problems rather than things compiling ok and =
failing
properly.  I know Juergen has been doing this with many recent changes, =
but
an "across-the-board" policy would make things easier now that the size =
of
Spring's code and my own has grown so large.  These deprecations can be
removed for the RC (possibly by creating an M4 first with deprecations =
still
in, and then an RC immediately with the deprecations removed for the =
"final"
public api).

+1 to including source but no libs with samples

Trevor

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: November 22, 2003 7:45 PM
To: spr...@li...
Subject: Re: [Springframework-developer] 1.0 M3 prepared


FYI, I've already committed the renaming from ListableBeanFactoryImpl to
DefaultListableBeanFactory. The web MVC exception stuff will follow
tomorrow.

I've also reworked the Tiles example, using
org.springframework.samples.tiles as package now, and auto-detecting the
Tiles DTD. The FileNameViewController has now moved to
org.springframework.web.servlet.mvc. And I've changed my mind: I do like =
to
include struts-1.1.jar and commons-digester.jar now, for an =
out-of-the-box
working example. It already annoys me having to copy those files in for
testing, so consider a new user...

I've just modified our build script to generate two release zips:
spring-framework-1.0-m3.zip (~5600 KB) and
spring-framework-1.0-m3-samples.zip (~5400 KB). Both use
spring-framework-1.0-m3 as path in the zip, for convenient extraction to =
the
same location. The former contains dist, docs, lib/aop-alliance,
lib/jakarta-commons/commons-logging.jar, src, and the readmes, while the
latter contains samples and the additional libs necessary for building =
and
running them.

What do you think? Should I commit the changed build script and use it =
for
the M3 release? I believe it would make sense to split the release into
those two files, as 11 MB is already a bit large for a single =
distribution.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Colin Sampaleanu
Gesendet: Sa 22.11.2003 00:57
An: spr...@li...
Betreff: Re: [Springframework-developer] 1.0 M3 prepared



j=FCrgen h=F6ller [werk3AT] wrote:

>Everybody,
>
>I've just prepared the release as far as possible: fixed all javadoc
errors, added missing package javadocs, tested the samples. All tests =
for
shipped components pass on my machine (when running via Ant).
>
>The TLD is now loaded from the spring.jar file, referenced via the =
default
URI http://www.springframework.org/tags (analogous to Struts and JSTL).
BaseCommandController uses setCommandName now, with setBeanName being
deprecated.
>
>Whoever wants to give it a try, fetch the latest CVS contents, run the
release target, and "play user" with spring-framework-1.0-m3.zip (it's =
in
the target/release directrory): unzip it, browse through the docs, build =
the
sample wars (call ant warfile or warfile.bat) and drop them into your
container's webapps directory.
>
>Alef, could you give the tiles-example a final try? I'm not keen on
including struts.jar in the Spring distribution, so the example should =
be
prepared for deployment with a manually added struts.jar.
>
>A final note on a further naming issue: I'm not entirely happy with
"ListableBeanFactoryImpl". For example, BeanWrapperImpl is *the*
implementation of BeanWrapper, hardly any chance for alternative
implementations - the interface is rather a simplified API for it. But
ListableBeanFactoryImpl implements ConfigurableListableBeanFactory with
registration methods for a specific properties format; this seems to be =
a
different case to me.
>
>So wouldn't it be more appropriate to call it =
"DefaultListableBeanFactory"?
That name change should not affect typical applications anyway but just
"power users" who should be willing to migrate via a simple class name
change. I quite strongly prefer this name to "ListableBeanFactoryImpl",
actually. If we agree on the new name, let's better change it now =
instead of
in the 1.0 RC phase.
>
>
>
I am ok with the name change, as it does make sense.

Btw, as per another email, I have added a new MethodCallFactoryBean
class. It should be totally ok for this release, as no other code was
touched, and there is a full unit test.

Regards,
Colin




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] 1.0 M3 prepared

[Trevor C. <pr...@se...>]

I've updated our projects to M3, and everything is working properly now.

I did have a slight problem with a few places where I overrided userObjec=
t
(in the SimpleFormController) but no compilation errors were reported (th=
is
took a while to track down).  While the public api won't be frozen until =
the
RC, can I request that any changes to the public apis (method name change=
s
and parameter signatures) are done using the @deprecated tag, and the
deprecated method simply calls the new method.  This will ensure that the
compiler will report problems rather than things compiling ok and failing
properly.  I know Juergen has been doing this with many recent changes, b=
ut
an "across-the-board" policy would make things easier now that the size o=
f
Spring's code and my own has grown so large.  These deprecations can be
removed for the RC (possibly by creating an M4 first with deprecations st=
ill
in, and then an RC immediately with the deprecations removed for the "fin=
al"
public api).

+1 to including source but no libs with samples

Trevor

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: November 22, 2003 7:45 PM
To: spr...@li...
Subject: Re: [Springframework-developer] 1.0 M3 prepared


FYI, I've already committed the renaming from ListableBeanFactoryImpl to
DefaultListableBeanFactory. The web MVC exception stuff will follow
tomorrow.

I've also reworked the Tiles example, using
org.springframework.samples.tiles as package now, and auto-detecting the
Tiles DTD. The FileNameViewController has now moved to
org.springframework.web.servlet.mvc. And I've changed my mind: I do like =
to
include struts-1.1.jar and commons-digester.jar now, for an out-of-the-bo=
x
working example. It already annoys me having to copy those files in for
testing, so consider a new user...

I've just modified our build script to generate two release zips:
spring-framework-1.0-m3.zip (~5600 KB) and
spring-framework-1.0-m3-samples.zip (~5400 KB). Both use
spring-framework-1.0-m3 as path in the zip, for convenient extraction to =
the
same location. The former contains dist, docs, lib/aop-alliance,
lib/jakarta-commons/commons-logging.jar, src, and the readmes, while the
latter contains samples and the additional libs necessary for building an=
d
running them.

What do you think? Should I commit the changed build script and use it fo=
r
the M3 release? I believe it would make sense to split the release into
those two files, as 11 MB is already a bit large for a single distributio=
n.

Juergen


________________________________

Von: spr...@li... im Auftrag von
Colin Sampaleanu
Gesendet: Sa 22.11.2003 00:57
An: spr...@li...
Betreff: Re: [Springframework-developer] 1.0 M3 prepared



j=FCrgen h=F6ller [werk3AT] wrote:

>Everybody,
>
>I've just prepared the release as far as possible: fixed all javadoc
errors, added missing package javadocs, tested the samples. All tests for
shipped components pass on my machine (when running via Ant).
>
>The TLD is now loaded from the spring.jar file, referenced via the defau=
lt
URI http://www.springframework.org/tags (analogous to Struts and JSTL).
BaseCommandController uses setCommandName now, with setBeanName being
deprecated.
>
>Whoever wants to give it a try, fetch the latest CVS contents, run the
release target, and "play user" with spring-framework-1.0-m3.zip (it's in
the target/release directrory): unzip it, browse through the docs, build =
the
sample wars (call ant warfile or warfile.bat) and drop them into your
container's webapps directory.
>
>Alef, could you give the tiles-example a final try? I'm not keen on
including struts.jar in the Spring distribution, so the example should be
prepared for deployment with a manually added struts.jar.
>
>A final note on a further naming issue: I'm not entirely happy with
"ListableBeanFactoryImpl". For example, BeanWrapperImpl is *the*
implementation of BeanWrapper, hardly any chance for alternative
implementations - the interface is rather a simplified API for it. But
ListableBeanFactoryImpl implements ConfigurableListableBeanFactory with
registration methods for a specific properties format; this seems to be a
different case to me.
>
>So wouldn't it be more appropriate to call it "DefaultListableBeanFactor=
y"?
That name change should not affect typical applications anyway but just
"power users" who should be willing to migrate via a simple class name
change. I quite strongly prefer this name to "ListableBeanFactoryImpl",
actually. If we agree on the new name, let's better change it now instead=
 of
in the 1.0 RC phase.
>
>
>
I am ok with the name change, as it does make sense.

Btw, as per another email, I have added a new MethodCallFactoryBean
class. It should be totally ok for this release, as no other code was
touched, and there is a full unit test.

Regards,
Colin




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] 1.0 M3 prepared

[Matthew E. P. <ma...@me...>]

B) Although I am new to the list, I agree with Mike.  Hibernate keeps =20=

track of this by putting a file called VERSION in the lib directory.  =20=

While it requires people to be maintain this file, it seems to solve =20
everyone's issues.  File are still named xxxx.jar without a date or =20
version number.  People who want versions know where to get them.


Cheers,
   matthew



On Nov 23, 2003, at 5:40 AM, j=FCrgen h=F6ller [werk3AT] wrote:

> A) OK, I've scrapped the distinction between main download and samples =
=20
> for the time being. An 11 MB download isn't that large, after all.
>
> B) Same as Rod, personally - for that kind of jar management, version =20=

> numbers are rather a nuisance, as you can't simply do a drop-in update =
=20
> but have to do a remove plus an add. We include the actual Spring =20
> version number as "Spring-Version" manifest attribute in =20
> spring.jar/spring-beans.jar/spring-jdbc.jar/spring-context.jar, BTW.
>
> C) Is there really no explicit documentation on it? Funnily enough, =20=

> noone has asked for it yet... The DTD is pretty self-explanatory and =20=

> enriched with comments, so it can serve as transitional documentation, =
=20
> I guess.
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag =20=

> von Rod Johnson
> Gesendet: So 23.11.2003 10:16
> An: spr...@li...
> Betreff: Re: [Springframework-developer] 1.0 M3 prepared
>
>
>
> A) I'm inclined to agree. I don't think a few megs are significant. It =
=20
> also
> makes it harder to work out real download numbers.
>
> B) Tough question. While it is nice to know what version things are, =20=

> in my
> projects as an end user I tend to rely on CVS to manage versioning. =20=

> E.g. my
> manifest classpath, constructed in the build script, might reference
> aopalliance.jar and I would rely on source control to ensure that it =20=

> was the
> correct version for my source. (Of course without EJB, a manifest =20
> classpath
> isn't usually needed.)
> Maybe we should survey what other projects do (or go Maven-friendly).
>
> C) We probably do need a document. The DTD has some documentation in =20=

> it.
>
> Regards,
> Rod
>
> ----- Original Message -----
> From: "Mike Cannon-Brookes" <mi...@at...>
> To: "Spring Developer" =20
> <spr...@li...>
> Sent: Sunday, November 23, 2003 5:38 AM
> Subject: Re: [Springframework-developer] 1.0 M3 prepared
>
>
> Can I make some suggestions before the release?
>
> A) ship all source with the release, including samples. I don't see =20=

> why we
> need multiple ZIPs? It just complicates things and will frustrate =
users
> trying out spring IMHO. Noone really cares if it's 11MB do they? =20
> (apologies
> if this is an old already discussed issue - I'm just not sure the =20
> reason for
> two JARs)
>
> B) Can we please, please, please version the JARs shipped? Eg
> aopalliance.jar is useless for people building apps, what version is =20=

> it?
> Managing dependencies explicitly is important - make it
> aopalliance-alpha1.jar or aopalliance-23Nov03.jar if it's from CVS =
etc.
>
> C) On a slightly related note, I couldn't find any docs (maybe I'm =20
> blind) on
> the exact syntax of the applicationContext.xml file? (ie how to set =20=

> lists,
> booleans etc)
>
> Cheers,
> Mike
>
> On 23/11/03 3:05 PM, "tri...@tr..." (tri...@tr...) penned =20=

> the
> words:
>
>> +1 for including the sample source in the base download.  It's good =20=

>> as a
>> reference.  I have updated the MVC step-by-step document to reflect =20=

>> the
> need
>> to
>> download both zips.
>>
>> Thomas
>>
>> Quoting Colin Sampaleanu <col...@ex...>:
>>
>>> j=FCrgen h=F6ller [werk3AT] wrote:
>>>
>>>> FYI, I've already committed the renaming from =20
>>>> ListableBeanFactoryImpl to
>>> DefaultListableBeanFactory. The web MVC exception stuff will follow
>>> tomorrow.
>>>>
>>>> I've also reworked the Tiles example, using
>>> org.springframework.samples.tiles as package now, and auto-detecting =
=20
>>> the
>>> Tiles DTD. The FileNameViewController has now moved to
>>> org.springframework.web.servlet.mvc. And I've changed my mind: I do =20=

>>> like
> to
>>> include struts-1.1.jar and commons-digester.jar now, for an
> out-of-the-box
>>> working example. It already annoys me having to copy those files in =20=

>>> for
>>> testing, so consider a new user...
>>>>
>>>> I've just modified our build script to generate two release zips:
>>> spring-framework-1.0-m3.zip (~5600 KB) and
>>> spring-framework-1.0-m3-samples.zip (~5400 KB). Both use
>>> spring-framework-1.0-m3 as path in the zip, for convenient =20
>>> extraction to
> the
>>> same location. The former contains dist, docs, lib/aop-alliance,
>>> lib/jakarta-commons/commons-logging.jar, src, and the readmes, while =
=20
>>> the
>>> latter contains samples and the additional libs necessary for =20
>>> building
> and
>>> running them.
>>>>
>>>> What do you think? Should I commit the changed build script and use =
=20
>>>> it
> for
>>> the M3 release? I believe it would make sense to split the release =20=

>>> into
> those
>>> two files, as 11 MB is already a bit large for a single =
distribution.
>>>>
>>>> Juergen
>>>>
>>>>
>>> It probably makes sense to split things up this way. If somebody =20
>>> doesn't
>>> care about the libs for the samples it's a drag to pull them down =20=

>>> each
>>> release. Maybe it would make sense though to still include _sources_ =
=20
>>> for
>>> the samples even with the first jar. Sample sources sometimes help =20=

>>> you
>>> figure stuff out that is not really related. I know that when I was
>>> initially looking at Spring and figuring out Application Contexts, I
>>> looked at all the contexts in all the samples, even if I had no =20
>>> interest
>
>>> at that time in actually building those samples or using those parts =
=20
>>> of
>>> Spring (like the MVC).
>>>
>>> Colin
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: SF.net Giveback Program.
>>> Does SourceForge.net help you be more productive?  Does it
>>> help you create better code?  SHARE THE LOVE, and help us help
>>> YOU!  Click Here: http://sourceforge.net/donate/
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-=20
>>> developer
>>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: SF.net Giveback Program.
>> Does SourceForge.net help you be more productive?  Does it
>> help you create better code?  SHARE THE LOVE, and help us help
>> YOU!  Click Here: http://sourceforge.net/donate/
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] 1.0 M3 prepared

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

I'd like to encourage everybody to try the current snapshot for Spring =
web MVC applications. As I've said in the corresponding mails, there =
shouldn't be any changes necessary for standard stuff, but you might =
need to adapt thrown exceptions if invoking controller super class =
methods - trivial to change, simply declare "throws Exception" if =
necessary.
=20
Whoever likes to play around can also have a look at the =
HandlerExceptionResolver stuff. I've added an example for it to =
Petclinic, forwarding DataAccessExceptions and TransactionExceptions to =
a special MVC-managed error page. For existing apps, simply don't worry =
about it.
=20
The Tiles example does now work out-of-the-box in the generated release =
distribution. Simply invoke warfile.bat and drop the war file from the =
dist directory into your container's webapps directory, just like with =
Countries and Petclinic.
=20
I'll prepare a short summary of deprecations and potentially =
incompatible changes (probably collecting them together in one file with =
Rod's summary of AOP changes), as there are quite a few in the meantime.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: So 23.11.2003 01:44
An: spr...@li...
Betreff: Re: [Springframework-developer] 1.0 M3 prepared



FYI, I've already committed the renaming from ListableBeanFactoryImpl to =
DefaultListableBeanFactory. The web MVC exception stuff will follow =
tomorrow.

I've also reworked the Tiles example, using =
org.springframework.samples.tiles as package now, and auto-detecting the =
Tiles DTD. The FileNameViewController has now moved to =
org.springframework.web.servlet.mvc. And I've changed my mind: I do like =
to include struts-1.1.jar and commons-digester.jar now, for an =
out-of-the-box working example. It already annoys me having to copy =
those files in for testing, so consider a new user...

I've just modified our build script to generate two release zips: =
spring-framework-1.0-m3.zip (~5600 KB) and =
spring-framework-1.0-m3-samples.zip (~5400 KB). Both use =
spring-framework-1.0-m3 as path in the zip, for convenient extraction to =
the same location. The former contains dist, docs, lib/aop-alliance, =
lib/jakarta-commons/commons-logging.jar, src, and the readmes, while the =
latter contains samples and the additional libs necessary for building =
and running them.

What do you think? Should I commit the changed build script and use it =
for the M3 release? I believe it would make sense to split the release =
into those two files, as 11 MB is already a bit large for a single =
distribution.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Sa 22.11.2003 00:57
An: spr...@li...
Betreff: Re: [Springframework-developer] 1.0 M3 prepared



j=FCrgen h=F6ller [werk3AT] wrote:

>Everybody,
>
>I've just prepared the release as far as possible: fixed all javadoc =
errors, added missing package javadocs, tested the samples. All tests =
for shipped components pass on my machine (when running via Ant).
>
>The TLD is now loaded from the spring.jar file, referenced via the =
default URI http://www.springframework.org/tags (analogous to Struts and =
JSTL). BaseCommandController uses setCommandName now, with setBeanName =
being deprecated.
>
>Whoever wants to give it a try, fetch the latest CVS contents, run the =
release target, and "play user" with spring-framework-1.0-m3.zip (it's =
in the target/release directrory): unzip it, browse through the docs, =
build the sample wars (call ant warfile or warfile.bat) and drop them =
into your container's webapps directory.
>
>Alef, could you give the tiles-example a final try? I'm not keen on =
including struts.jar in the Spring distribution, so the example should =
be prepared for deployment with a manually added struts.jar.
>
>A final note on a further naming issue: I'm not entirely happy with =
"ListableBeanFactoryImpl". For example, BeanWrapperImpl is *the* =
implementation of BeanWrapper, hardly any chance for alternative =
implementations - the interface is rather a simplified API for it. But =
ListableBeanFactoryImpl implements ConfigurableListableBeanFactory with =
registration methods for a specific properties format; this seems to be =
a different case to me.
>
>So wouldn't it be more appropriate to call it =
"DefaultListableBeanFactory"? That name change should not affect typical =
applications anyway but just "power users" who should be willing to =
migrate via a simple class name change. I quite strongly prefer this =
name to "ListableBeanFactoryImpl", actually. If we agree on the new =
name, let's better change it now instead of in the 1.0 RC phase.
>
>
>
I am ok with the name change, as it does make sense.

Btw, as per another email, I have added a new MethodCallFactoryBean
class. It should be totally ok for this release, as no other code was
touched, and there is a full unit test.

Regards,
Colin




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] 1.0 M3 prepared

[Mike Cannon-B. <mi...@at...>]

> A) OK, I've scrapped the distinction between main download and samples fo=
r the
> time being. An 11 MB download isn't that large, after all.
Cool.
=20
> B) Same as Rod, personally - for that kind of jar management, version num=
bers
> are rather a nuisance, as you can't simply do a drop-in update but have t=
o do
> a remove plus an add. We include the actual Spring version number as
> "Spring-Version" manifest attribute in
> spring.jar/spring-beans.jar/spring-jdbc.jar/spring-context.jar, BTW.
I'm not sure I agree here. Why bother keeping JARs versioned by CVS if they
have a version number in the file name?

You gain nothing but confusion IMHO. For example, as soon as the JAR moves
around for whatever reason - ie deployed in an app in an app server - you
suddenly have no idea what JAR it is. Very few people actually _use_ (or
ever read ;)) the manifest files.

If we can't version the JARs, can we at least have a README somewhere that
lists exactly which version the JARs are? Or is that in the manifests?
=20
> C) Is there really no explicit documentation on it? Funnily enough, noone=
 has
> asked for it yet... The DTD is pretty self-explanatory and enriched with
> comments, so it can serve as transitional documentation, I guess.
OK cool - didn't know there was a DTD - I'll try reading that first :)

M

> Juergen
>=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag von=
 Rod
> Johnson
> Gesendet: So 23.11.2003 10:16
> An: spr...@li...
> Betreff: Re: [Springframework-developer] 1.0 M3 prepared
>=20
>=20
>=20
> A) I'm inclined to agree. I don't think a few megs are significant. It al=
so
> makes it harder to work out real download numbers.
>=20
> B) Tough question. While it is nice to know what version things are, in m=
y
> projects as an end user I tend to rely on CVS to manage versioning. E.g. =
my
> manifest classpath, constructed in the build script, might reference
> aopalliance.jar and I would rely on source control to ensure that it was =
the
> correct version for my source. (Of course without EJB, a manifest classpa=
th
> isn't usually needed.)
> Maybe we should survey what other projects do (or go Maven-friendly).
>=20
> C) We probably do need a document. The DTD has some documentation in it.
>=20
> Regards,
> Rod
>=20
> ----- Original Message -----
> From: "Mike Cannon-Brookes" <mi...@at...>
> To: "Spring Developer" <spr...@li...>
> Sent: Sunday, November 23, 2003 5:38 AM
> Subject: Re: [Springframework-developer] 1.0 M3 prepared
>=20
>=20
> Can I make some suggestions before the release?
>=20
> A) ship all source with the release, including samples. I don't see why w=
e
> need multiple ZIPs? It just complicates things and will frustrate users
> trying out spring IMHO. Noone really cares if it's 11MB do they? (apologi=
es
> if this is an old already discussed issue - I'm just not sure the reason =
for
> two JARs)
>=20
> B) Can we please, please, please version the JARs shipped? Eg
> aopalliance.jar is useless for people building apps, what version is it?
> Managing dependencies explicitly is important - make it
> aopalliance-alpha1.jar or aopalliance-23Nov03.jar if it's from CVS etc.
>=20
> C) On a slightly related note, I couldn't find any docs (maybe I'm blind)=
 on
> the exact syntax of the applicationContext.xml file? (ie how to set lists=
,
> booleans etc)
>=20
> Cheers,
> Mike
>=20
> On 23/11/03 3:05 PM, "tri...@tr..." (tri...@tr...) penned the
> words:
>=20
>> +1 for including the sample source in the base download.  It's good as a
>> reference.  I have updated the MVC step-by-step document to reflect the
> need
>> to
>> download both zips.
>>=20
>> Thomas
>>=20
>> Quoting Colin Sampaleanu <col...@ex...>:
>>=20
>>> j=FCrgen h=F6ller [werk3AT] wrote:
>>>=20
>>>> FYI, I've already committed the renaming from ListableBeanFactoryImpl =
to
>>> DefaultListableBeanFactory. The web MVC exception stuff will follow
>>> tomorrow.
>>>>=20
>>>> I've also reworked the Tiles example, using
>>> org.springframework.samples.tiles as package now, and auto-detecting th=
e
>>> Tiles DTD. The FileNameViewController has now moved to
>>> org.springframework.web.servlet.mvc. And I've changed my mind: I do lik=
e
> to
>>> include struts-1.1.jar and commons-digester.jar now, for an
> out-of-the-box
>>> working example. It already annoys me having to copy those files in for
>>> testing, so consider a new user...
>>>>=20
>>>> I've just modified our build script to generate two release zips:
>>> spring-framework-1.0-m3.zip (~5600 KB) and
>>> spring-framework-1.0-m3-samples.zip (~5400 KB). Both use
>>> spring-framework-1.0-m3 as path in the zip, for convenient extraction t=
o
> the
>>> same location. The former contains dist, docs, lib/aop-alliance,
>>> lib/jakarta-commons/commons-logging.jar, src, and the readmes, while th=
e
>>> latter contains samples and the additional libs necessary for building
> and
>>> running them.
>>>>=20
>>>> What do you think? Should I commit the changed build script and use it
> for
>>> the M3 release? I believe it would make sense to split the release into
> those
>>> two files, as 11 MB is already a bit large for a single distribution.
>>>>=20
>>>> Juergen
>>>>=20
>>>>=20
>>> It probably makes sense to split things up this way. If somebody doesn'=
t
>>> care about the libs for the samples it's a drag to pull them down each
>>> release. Maybe it would make sense though to still include _sources_ fo=
r
>>> the samples even with the first jar. Sample sources sometimes help you
>>> figure stuff out that is not really related. I know that when I was
>>> initially looking at Spring and figuring out Application Contexts, I
>>> looked at all the contexts in all the samples, even if I had no interes=
t
>=20
>>> at that time in actually building those samples or using those parts of
>>> Spring (like the MVC).
>>>=20
>>> Colin
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: SF.net Giveback Program.
>>> Does SourceForge.net help you be more productive?  Does it
>>> help you create better code?  SHARE THE LOVE, and help us help
>>> YOU!  Click Here: http://sourceforge.net/donate/
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> -------------------------------------------------------
>> This SF.net email is sponsored by: SF.net Giveback Program.
>> Does SourceForge.net help you be more productive?  Does it
>> help you create better code?  SHARE THE LOVE, and help us help
>> YOU!  Click Here: http://sourceforge.net/donate/
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> 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: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> 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: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] MVC Exception Handling

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

I've just committed the exception handling change. The =
HandlerExceptionResolver interfaces can now decide to return a =
ModelAndView based on the exception and the handler object that was =
executed.
=20
A SimpleMappingExceptionResolver allows to map fully qualified exception =
class names (including base classes) to view names, restricting its =
mappings to a certain list of handlers to be set as bean references to =
the "mappedHandlers" property. Multiple resolver instances can thus =
define distinct mappings for different handlers. A generic one without =
mapped handlers can be the last in the ordered chain, providing fallback =
resolution.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: So 23.11.2003 10:10
An: spr...@li...
Betreff: Re: [Springframework-developer] MVC Exception Handling



Rob

> By having the exceptions handled at the DispatcherServlet all =
exceptions
are
> handled the same no matter which controller (i.e. place in the web
workflow)
> threw the exceptions.  This is great, if I always want ExceptionXYZ to
show
> the same view.  If you add a similar capability to
> org.springframework.web.servlet.mvc.AbstractController then the view /
> exception mapping could be customized for each.

True, but it definitely makes sense for there to be _one_ default.

It is possible to use an AOP proxy around an individual controller so =
that
an exception could be caught and replaced by a ModelAndView object also.
Although this mechanism is harder to configure and requires knowledge of
AOP, at least it is possible. (A BeanPostProcessor could make such AOP
configuration easier.)

However, there may be a case for extending the ExceptionResolver =
behaviour
to individual controllers. How would a controller-specific mapping work?
Couldn't just be known implementations of ExceptionResolver?

If there is an individual mapping, I wouldn't handle it in
AbstractController, but in DispatcherServlet, which knows which =
Controller
it just used. Then it's not tied to a particular AbstractController.

> When an exception occurs, the mapping in the AbstractController (or =
sub
> class) would be checked first, if no match was found then the mapping =
in
the
> DispatherServlet would be checked.  This would allow for "general" =
view /
> exception mappings to be done in the Dispatcher, while also allowing =
the
> AbstractController the opportunity to over-ride the more general view =
/
> exception mappings.
>
> Alternately, you could move the implementation of the Exception =
mapping to
> the AbstractController, and not have it in the DispatherServlet.  Then =
any
> exception mappings that are specific to that controller would be added =
to
> it, and you could have a separate place to declare any that are =
"global".
> The "global" ones would be added to the end of the ones declared for =
that
> particular AbstractController.  In this way you would still have the
> "general" view / exception mappings, but the code would only have to =
be in
> the AbstractController.
But this ties the behavior to AbstractController, thus degrading the
Controller interface and privileging concrete inheritance.

> Also, I hope the ExceptionResolver you implemented will work for both
> checked and unchecked exceptions.  In general, an unchecked exception
would
> just mean "something really bad and uncontrollable happened" to the =
user,
> but it could be useful to display different error messages to the user
> depending upon what the exception is.  I.E. if my app throws a runtime
> exception because a remote system is down (one that is generally flaky
let's
> say, and you have no control over it - you know, the kind of stuff you =
run
> into all the time with legacy systems) you may want to tell the user =
to
come
> back and try again in a few minutes.  But if your database server is =
down
> and causing you to bubble up unchecked DB exceptions, you may want to =
tell
> them to come back tomorrow.
Good point.

> Also, it would be great if your ExceptionResolver could not check for
exact
> matches to exceptions, but could check instanceof, or isassignable.  =
In
that
> way if I have a whole bunch of exceptions that are subclassed from =
some
> common one, and I want all of them to show the same view, I can simply =
add
> the base one to the ExceptionResolver, instead of each one subclassed =
from
> it.  Also, since your ExceptionResolver checks in "order" if I had one =
to
> two of those subclassed exceptions I wanted handled differently, I =
could
> register them before the base one.  This would again, allow those to =
be
> handled specially, and all the others would follow on to the base one.
Good points.

Regards,
Rod




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] 1.0 M3 prepared

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

A) OK, I've scrapped the distinction between main download and samples =
for the time being. An 11 MB download isn't that large, after all.
=20
B) Same as Rod, personally - for that kind of jar management, version =
numbers are rather a nuisance, as you can't simply do a drop-in update =
but have to do a remove plus an add. We include the actual Spring =
version number as "Spring-Version" manifest attribute in =
spring.jar/spring-beans.jar/spring-jdbc.jar/spring-context.jar, BTW.
=20
C) Is there really no explicit documentation on it? Funnily enough, =
noone has asked for it yet... The DTD is pretty self-explanatory and =
enriched with comments, so it can serve as transitional documentation, I =
guess.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: So 23.11.2003 10:16
An: spr...@li...
Betreff: Re: [Springframework-developer] 1.0 M3 prepared



A) I'm inclined to agree. I don't think a few megs are significant. It =
also
makes it harder to work out real download numbers.

B) Tough question. While it is nice to know what version things are, in =
my
projects as an end user I tend to rely on CVS to manage versioning. E.g. =
my
manifest classpath, constructed in the build script, might reference
aopalliance.jar and I would rely on source control to ensure that it was =
the
correct version for my source. (Of course without EJB, a manifest =
classpath
isn't usually needed.)
Maybe we should survey what other projects do (or go Maven-friendly).

C) We probably do need a document. The DTD has some documentation in it.

Regards,
Rod

----- Original Message -----
From: "Mike Cannon-Brookes" <mi...@at...>
To: "Spring Developer" <spr...@li...>
Sent: Sunday, November 23, 2003 5:38 AM
Subject: Re: [Springframework-developer] 1.0 M3 prepared


Can I make some suggestions before the release?

A) ship all source with the release, including samples. I don't see why =
we
need multiple ZIPs? It just complicates things and will frustrate users
trying out spring IMHO. Noone really cares if it's 11MB do they? =
(apologies
if this is an old already discussed issue - I'm just not sure the reason =
for
two JARs)

B) Can we please, please, please version the JARs shipped? Eg
aopalliance.jar is useless for people building apps, what version is it?
Managing dependencies explicitly is important - make it
aopalliance-alpha1.jar or aopalliance-23Nov03.jar if it's from CVS etc.

C) On a slightly related note, I couldn't find any docs (maybe I'm =
blind) on
the exact syntax of the applicationContext.xml file? (ie how to set =
lists,
booleans etc)

Cheers,
Mike

On 23/11/03 3:05 PM, "tri...@tr..." (tri...@tr...) penned =
the
words:

> +1 for including the sample source in the base download.  It's good as =
a
> reference.  I have updated the MVC step-by-step document to reflect =
the
need
> to
> download both zips.
>
> Thomas
>
> Quoting Colin Sampaleanu <col...@ex...>:
>
>> j=FCrgen h=F6ller [werk3AT] wrote:
>>
>>> FYI, I've already committed the renaming from =
ListableBeanFactoryImpl to
>> DefaultListableBeanFactory. The web MVC exception stuff will follow
>> tomorrow.
>>>
>>> I've also reworked the Tiles example, using
>> org.springframework.samples.tiles as package now, and auto-detecting =
the
>> Tiles DTD. The FileNameViewController has now moved to
>> org.springframework.web.servlet.mvc. And I've changed my mind: I do =
like
to
>> include struts-1.1.jar and commons-digester.jar now, for an
out-of-the-box
>> working example. It already annoys me having to copy those files in =
for
>> testing, so consider a new user...
>>>
>>> I've just modified our build script to generate two release zips:
>> spring-framework-1.0-m3.zip (~5600 KB) and
>> spring-framework-1.0-m3-samples.zip (~5400 KB). Both use
>> spring-framework-1.0-m3 as path in the zip, for convenient extraction =
to
the
>> same location. The former contains dist, docs, lib/aop-alliance,
>> lib/jakarta-commons/commons-logging.jar, src, and the readmes, while =
the
>> latter contains samples and the additional libs necessary for =
building
and
>> running them.
>>>
>>> What do you think? Should I commit the changed build script and use =
it
for
>> the M3 release? I believe it would make sense to split the release =
into
those
>> two files, as 11 MB is already a bit large for a single distribution.
>>>
>>> Juergen
>>>
>>>
>> It probably makes sense to split things up this way. If somebody =
doesn't
>> care about the libs for the samples it's a drag to pull them down =
each
>> release. Maybe it would make sense though to still include _sources_ =
for
>> the samples even with the first jar. Sample sources sometimes help =
you
>> figure stuff out that is not really related. I know that when I was
>> initially looking at Spring and figuring out Application Contexts, I
>> looked at all the contexts in all the samples, even if I had no =
interest

>> at that time in actually building those samples or using those parts =
of
>> Spring (like the MVC).
>>
>> Colin
>>
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: SF.net Giveback Program.
>> Does SourceForge.net help you be more productive?  Does it
>> help you create better code?  SHARE THE LOVE, and help us help
>> YOU!  Click Here: http://sourceforge.net/donate/
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] 1.0 M3 prepared

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

A) I'm inclined to agree. I don't think a few megs are significant. It also
makes it harder to work out real download numbers.

B) Tough question. While it is nice to know what version things are, in my
projects as an end user I tend to rely on CVS to manage versioning. E.g. my
manifest classpath, constructed in the build script, might reference
aopalliance.jar and I would rely on source control to ensure that it was the
correct version for my source. (Of course without EJB, a manifest classpath
isn't usually needed.)
Maybe we should survey what other projects do (or go Maven-friendly).

C) We probably do need a document. The DTD has some documentation in it.

Regards,
Rod

----- Original Message ----- 
From: "Mike Cannon-Brookes" <mi...@at...>
To: "Spring Developer" <spr...@li...>
Sent: Sunday, November 23, 2003 5:38 AM
Subject: Re: [Springframework-developer] 1.0 M3 prepared


Can I make some suggestions before the release?

A) ship all source with the release, including samples. I don't see why we
need multiple ZIPs? It just complicates things and will frustrate users
trying out spring IMHO. Noone really cares if it's 11MB do they? (apologies
if this is an old already discussed issue - I'm just not sure the reason for
two JARs)

B) Can we please, please, please version the JARs shipped? Eg
aopalliance.jar is useless for people building apps, what version is it?
Managing dependencies explicitly is important - make it
aopalliance-alpha1.jar or aopalliance-23Nov03.jar if it's from CVS etc.

C) On a slightly related note, I couldn't find any docs (maybe I'm blind) on
the exact syntax of the applicationContext.xml file? (ie how to set lists,
booleans etc)

Cheers,
Mike

On 23/11/03 3:05 PM, "tri...@tr..." (tri...@tr...) penned the
words:

> +1 for including the sample source in the base download.  It's good as a
> reference.  I have updated the MVC step-by-step document to reflect the
need
> to
> download both zips.
>
> Thomas
>
> Quoting Colin Sampaleanu <col...@ex...>:
>
>> jürgen höller [werk3AT] wrote:
>>
>>> FYI, I've already committed the renaming from ListableBeanFactoryImpl to
>> DefaultListableBeanFactory. The web MVC exception stuff will follow
>> tomorrow.
>>>
>>> I've also reworked the Tiles example, using
>> org.springframework.samples.tiles as package now, and auto-detecting the
>> Tiles DTD. The FileNameViewController has now moved to
>> org.springframework.web.servlet.mvc. And I've changed my mind: I do like
to
>> include struts-1.1.jar and commons-digester.jar now, for an
out-of-the-box
>> working example. It already annoys me having to copy those files in for
>> testing, so consider a new user...
>>>
>>> I've just modified our build script to generate two release zips:
>> spring-framework-1.0-m3.zip (~5600 KB) and
>> spring-framework-1.0-m3-samples.zip (~5400 KB). Both use
>> spring-framework-1.0-m3 as path in the zip, for convenient extraction to
the
>> same location. The former contains dist, docs, lib/aop-alliance,
>> lib/jakarta-commons/commons-logging.jar, src, and the readmes, while the
>> latter contains samples and the additional libs necessary for building
and
>> running them.
>>>
>>> What do you think? Should I commit the changed build script and use it
for
>> the M3 release? I believe it would make sense to split the release into
those
>> two files, as 11 MB is already a bit large for a single distribution.
>>>
>>> Juergen
>>>
>>>
>> It probably makes sense to split things up this way. If somebody doesn't
>> care about the libs for the samples it's a drag to pull them down each
>> release. Maybe it would make sense though to still include _sources_ for
>> the samples even with the first jar. Sample sources sometimes help you
>> figure stuff out that is not really related. I know that when I was
>> initially looking at Spring and figuring out Application Contexts, I
>> looked at all the contexts in all the samples, even if I had no interest

>> at that time in actually building those samples or using those parts of
>> Spring (like the MVC).
>>
>> Colin
>>
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: SF.net Giveback Program.
>> Does SourceForge.net help you be more productive?  Does it
>> help you create better code?  SHARE THE LOVE, and help us help
>> YOU!  Click Here: http://sourceforge.net/donate/
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] MVC Exception Handling

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

Rob

> By having the exceptions handled at the DispatcherServlet all exceptions
are
> handled the same no matter which controller (i.e. place in the web
workflow)
> threw the exceptions.  This is great, if I always want ExceptionXYZ to
show
> the same view.  If you add a similar capability to
> org.springframework.web.servlet.mvc.AbstractController then the view /
> exception mapping could be customized for each.

True, but it definitely makes sense for there to be _one_ default.

It is possible to use an AOP proxy around an individual controller so that
an exception could be caught and replaced by a ModelAndView object also.
Although this mechanism is harder to configure and requires knowledge of
AOP, at least it is possible. (A BeanPostProcessor could make such AOP
configuration easier.)

However, there may be a case for extending the ExceptionResolver behaviour
to individual controllers. How would a controller-specific mapping work?
Couldn't just be known implementations of ExceptionResolver?

If there is an individual mapping, I wouldn't handle it in
AbstractController, but in DispatcherServlet, which knows which Controller
it just used. Then it's not tied to a particular AbstractController.

> When an exception occurs, the mapping in the AbstractController (or sub
> class) would be checked first, if no match was found then the mapping in
the
> DispatherServlet would be checked.  This would allow for "general" view /
> exception mappings to be done in the Dispatcher, while also allowing the
> AbstractController the opportunity to over-ride the more general view /
> exception mappings.
>
> Alternately, you could move the implementation of the Exception mapping to
> the AbstractController, and not have it in the DispatherServlet.  Then any
> exception mappings that are specific to that controller would be added to
> it, and you could have a separate place to declare any that are "global".
> The "global" ones would be added to the end of the ones declared for that
> particular AbstractController.  In this way you would still have the
> "general" view / exception mappings, but the code would only have to be in
> the AbstractController.
But this ties the behavior to AbstractController, thus degrading the
Controller interface and privileging concrete inheritance.

> Also, I hope the ExceptionResolver you implemented will work for both
> checked and unchecked exceptions.  In general, an unchecked exception
would
> just mean "something really bad and uncontrollable happened" to the user,
> but it could be useful to display different error messages to the user
> depending upon what the exception is.  I.E. if my app throws a runtime
> exception because a remote system is down (one that is generally flaky
let's
> say, and you have no control over it - you know, the kind of stuff you run
> into all the time with legacy systems) you may want to tell the user to
come
> back and try again in a few minutes.  But if your database server is down
> and causing you to bubble up unchecked DB exceptions, you may want to tell
> them to come back tomorrow.
Good point.

> Also, it would be great if your ExceptionResolver could not check for
exact
> matches to exceptions, but could check instanceof, or isassignable.  In
that
> way if I have a whole bunch of exceptions that are subclassed from some
> common one, and I want all of them to show the same view, I can simply add
> the base one to the ExceptionResolver, instead of each one subclassed from
> it.  Also, since your ExceptionResolver checks in "order" if I had one to
> two of those subclassed exceptions I wanted handled differently, I could
> register them before the base one.  This would again, allow those to be
> handled specially, and all the others would follow on to the base one.
Good points.

Regards,
Rod

Re: [Springframework-developer] 1.0 M3 prepared

[Mike Cannon-B. <mi...@at...>]

Can I make some suggestions before the release?

A) ship all source with the release, including samples. I don't see why we
need multiple ZIPs? It just complicates things and will frustrate users
trying out spring IMHO. Noone really cares if it's 11MB do they? (apologies
if this is an old already discussed issue - I'm just not sure the reason fo=
r
two JARs)

B) Can we please, please, please version the JARs shipped? Eg
aopalliance.jar is useless for people building apps, what version is it?
Managing dependencies explicitly is important - make it
aopalliance-alpha1.jar or aopalliance-23Nov03.jar if it's from CVS etc.

C) On a slightly related note, I couldn't find any docs (maybe I'm blind) o=
n
the exact syntax of the applicationContext.xml file? (ie how to set lists,
booleans etc)=20

Cheers,
Mike

On 23/11/03 3:05 PM, "tri...@tr..." (tri...@tr...) penned the
words:

> +1 for including the sample source in the base download.  It's good as a
> reference.  I have updated the MVC step-by-step document to reflect the n=
eed
> to
> download both zips.
>=20
> Thomas
>=20
> Quoting Colin Sampaleanu <col...@ex...>:
>=20
>> j=FCrgen h=F6ller [werk3AT] wrote:
>>=20
>>> FYI, I've already committed the renaming from ListableBeanFactoryImpl t=
o
>> DefaultListableBeanFactory. The web MVC exception stuff will follow
>> tomorrow.
>>>=20
>>> I've also reworked the Tiles example, using
>> org.springframework.samples.tiles as package now, and auto-detecting the
>> Tiles DTD. The FileNameViewController has now moved to
>> org.springframework.web.servlet.mvc. And I've changed my mind: I do like=
 to
>> include struts-1.1.jar and commons-digester.jar now, for an out-of-the-b=
ox
>> working example. It already annoys me having to copy those files in for
>> testing, so consider a new user...
>>>=20
>>> I've just modified our build script to generate two release zips:
>> spring-framework-1.0-m3.zip (~5600 KB) and
>> spring-framework-1.0-m3-samples.zip (~5400 KB). Both use
>> spring-framework-1.0-m3 as path in the zip, for convenient extraction to=
 the
>> same location. The former contains dist, docs, lib/aop-alliance,
>> lib/jakarta-commons/commons-logging.jar, src, and the readmes, while the
>> latter contains samples and the additional libs necessary for building a=
nd
>> running them.
>>>=20
>>> What do you think? Should I commit the changed build script and use it =
for
>> the M3 release? I believe it would make sense to split the release into =
those
>> two files, as 11 MB is already a bit large for a single distribution.
>>>=20
>>> Juergen
>>> =20
>>>=20
>> It probably makes sense to split things up this way. If somebody doesn't
>> care about the libs for the samples it's a drag to pull them down each
>> release. Maybe it would make sense though to still include _sources_ for
>> the samples even with the first jar. Sample sources sometimes help you
>> figure stuff out that is not really related. I know that when I was
>> initially looking at Spring and figuring out Application Contexts, I
>> looked at all the contexts in all the samples, even if I had no interest
>> at that time in actually building those samples or using those parts of
>> Spring (like the MVC).
>>=20
>> Colin
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> -------------------------------------------------------
>> This SF.net email is sponsored by: SF.net Giveback Program.
>> Does SourceForge.net help you be more productive?  Does it
>> help you create better code?  SHARE THE LOVE, and help us help
>> YOU!  Click Here: http://sourceforge.net/donate/
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>=20
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] 1.0 M3 prepared

[<tri...@tr...>]

+1 for including the sample source in the base download.  It's good as a
reference.  I have updated the MVC step-by-step document to reflect the need to
download both zips.

Thomas

Quoting Colin Sampaleanu <col...@ex...>:

> jürgen höller [werk3AT] wrote:
> 
> >FYI, I've already committed the renaming from ListableBeanFactoryImpl to
> DefaultListableBeanFactory. The web MVC exception stuff will follow
> tomorrow.
> > 
> >I've also reworked the Tiles example, using
> org.springframework.samples.tiles as package now, and auto-detecting the
> Tiles DTD. The FileNameViewController has now moved to
> org.springframework.web.servlet.mvc. And I've changed my mind: I do like to
> include struts-1.1.jar and commons-digester.jar now, for an out-of-the-box
> working example. It already annoys me having to copy those files in for
> testing, so consider a new user...
> > 
> >I've just modified our build script to generate two release zips:
> spring-framework-1.0-m3.zip (~5600 KB) and
> spring-framework-1.0-m3-samples.zip (~5400 KB). Both use
> spring-framework-1.0-m3 as path in the zip, for convenient extraction to the
> same location. The former contains dist, docs, lib/aop-alliance,
> lib/jakarta-commons/commons-logging.jar, src, and the readmes, while the
> latter contains samples and the additional libs necessary for building and
> running them.
> > 
> >What do you think? Should I commit the changed build script and use it for
> the M3 release? I believe it would make sense to split the release into those
> two files, as 11 MB is already a bit large for a single distribution.
> > 
> >Juergen
> >  
> >
> It probably makes sense to split things up this way. If somebody doesn't 
> care about the libs for the samples it's a drag to pull them down each 
> release. Maybe it would make sense though to still include _sources_ for 
> the samples even with the first jar. Sample sources sometimes help you 
> figure stuff out that is not really related. I know that when I was 
> initially looking at Spring and figuring out Application Contexts, I 
> looked at all the contexts in all the samples, even if I had no interest 
> at that time in actually building those samples or using those parts of 
> Spring (like the MVC).
> 
> Colin
> 
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] 1.0 M3 prepared

[Colin S. <col...@ex...>]

jürgen höller [werk3AT] wrote:

>FYI, I've already committed the renaming from ListableBeanFactoryImpl to DefaultListableBeanFactory. The web MVC exception stuff will follow tomorrow.
> 
>I've also reworked the Tiles example, using org.springframework.samples.tiles as package now, and auto-detecting the Tiles DTD. The FileNameViewController has now moved to org.springframework.web.servlet.mvc. And I've changed my mind: I do like to include struts-1.1.jar and commons-digester.jar now, for an out-of-the-box working example. It already annoys me having to copy those files in for testing, so consider a new user...
> 
>I've just modified our build script to generate two release zips: spring-framework-1.0-m3.zip (~5600 KB) and spring-framework-1.0-m3-samples.zip (~5400 KB). Both use spring-framework-1.0-m3 as path in the zip, for convenient extraction to the same location. The former contains dist, docs, lib/aop-alliance, lib/jakarta-commons/commons-logging.jar, src, and the readmes, while the latter contains samples and the additional libs necessary for building and running them.
> 
>What do you think? Should I commit the changed build script and use it for the M3 release? I believe it would make sense to split the release into those two files, as 11 MB is already a bit large for a single distribution.
> 
>Juergen
>  
>
It probably makes sense to split things up this way. If somebody doesn't 
care about the libs for the samples it's a drag to pull them down each 
release. Maybe it would make sense though to still include _sources_ for 
the samples even with the first jar. Sample sources sometimes help you 
figure stuff out that is not really related. I know that when I was 
initially looking at Spring and figuring out Application Contexts, I 
looked at all the contexts in all the samples, even if I had no interest 
at that time in actually building those samples or using those parts of 
Spring (like the MVC).

Colin

Re: [Springframework-developer] MVC Exception Handling

[Rob B. <rob...@ve...>]

Jürgen,

Excellent addition...  How about taking it one step further?

By having the exceptions handled at the DispatcherServlet all exceptions are
handled the same no matter which controller (i.e. place in the web workflow)
threw the exceptions.  This is great, if I always want ExceptionXYZ to show
the same view.  If you add a similar capability to
org.springframework.web.servlet.mvc.AbstractController then the view /
exception mapping could be customized for each.

When an exception occurs, the mapping in the AbstractController (or sub
class) would be checked first, if no match was found then the mapping in the
DispatherServlet would be checked.  This would allow for "general" view /
exception mappings to be done in the Dispatcher, while also allowing the
AbstractController the opportunity to over-ride the more general view /
exception mappings.

Alternately, you could move the implementation of the Exception mapping to
the AbstractController, and not have it in the DispatherServlet.  Then any
exception mappings that are specific to that controller would be added to
it, and you could have a separate place to declare any that are "global".
The "global" ones would be added to the end of the ones declared for that
particular AbstractController.  In this way you would still have the
"general" view / exception mappings, but the code would only have to be in
the AbstractController.

Also, I hope the ExceptionResolver you implemented will work for both
checked and unchecked exceptions.  In general, an unchecked exception would
just mean "something really bad and uncontrollable happened" to the user,
but it could be useful to display different error messages to the user
depending upon what the exception is.  I.E. if my app throws a runtime
exception because a remote system is down (one that is generally flaky let's
say, and you have no control over it - you know, the kind of stuff you run
into all the time with legacy systems) you may want to tell the user to come
back and try again in a few minutes.  But if your database server is down
and causing you to bubble up unchecked DB exceptions, you may want to tell
them to come back tomorrow.

Also, it would be great if your ExceptionResolver could not check for exact
matches to exceptions, but could check instanceof, or isassignable.  In that
way if I have a whole bunch of exceptions that are subclassed from some
common one, and I want all of them to show the same view, I can simply add
the base one to the ExceptionResolver, instead of each one subclassed from
it.  Also, since your ExceptionResolver checks in "order" if I had one to
two of those subclassed exceptions I wanted handled differently, I could
register them before the base one.  This would again, allow those to be
handled specially, and all the others would follow on to the base one.

What do you think?
Later
Rob

Re: [Springframework-developer] 1.0 M3 prepared

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

FYI, I've already committed the renaming from ListableBeanFactoryImpl to =
DefaultListableBeanFactory. The web MVC exception stuff will follow =
tomorrow.
=20
I've also reworked the Tiles example, using =
org.springframework.samples.tiles as package now, and auto-detecting the =
Tiles DTD. The FileNameViewController has now moved to =
org.springframework.web.servlet.mvc. And I've changed my mind: I do like =
to include struts-1.1.jar and commons-digester.jar now, for an =
out-of-the-box working example. It already annoys me having to copy =
those files in for testing, so consider a new user...
=20
I've just modified our build script to generate two release zips: =
spring-framework-1.0-m3.zip (~5600 KB) and =
spring-framework-1.0-m3-samples.zip (~5400 KB). Both use =
spring-framework-1.0-m3 as path in the zip, for convenient extraction to =
the same location. The former contains dist, docs, lib/aop-alliance, =
lib/jakarta-commons/commons-logging.jar, src, and the readmes, while the =
latter contains samples and the additional libs necessary for building =
and running them.
=20
What do you think? Should I commit the changed build script and use it =
for the M3 release? I believe it would make sense to split the release =
into those two files, as 11 MB is already a bit large for a single =
distribution.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Sa 22.11.2003 00:57
An: spr...@li...
Betreff: Re: [Springframework-developer] 1.0 M3 prepared



j=FCrgen h=F6ller [werk3AT] wrote:

>Everybody,
>
>I've just prepared the release as far as possible: fixed all javadoc =
errors, added missing package javadocs, tested the samples. All tests =
for shipped components pass on my machine (when running via Ant).
>
>The TLD is now loaded from the spring.jar file, referenced via the =
default URI http://www.springframework.org/tags (analogous to Struts and =
JSTL). BaseCommandController uses setCommandName now, with setBeanName =
being deprecated.
>
>Whoever wants to give it a try, fetch the latest CVS contents, run the =
release target, and "play user" with spring-framework-1.0-m3.zip (it's =
in the target/release directrory): unzip it, browse through the docs, =
build the sample wars (call ant warfile or warfile.bat) and drop them =
into your container's webapps directory.
>
>Alef, could you give the tiles-example a final try? I'm not keen on =
including struts.jar in the Spring distribution, so the example should =
be prepared for deployment with a manually added struts.jar.
>
>A final note on a further naming issue: I'm not entirely happy with =
"ListableBeanFactoryImpl". For example, BeanWrapperImpl is *the* =
implementation of BeanWrapper, hardly any chance for alternative =
implementations - the interface is rather a simplified API for it. But =
ListableBeanFactoryImpl implements ConfigurableListableBeanFactory with =
registration methods for a specific properties format; this seems to be =
a different case to me.
>
>So wouldn't it be more appropriate to call it =
"DefaultListableBeanFactory"? That name change should not affect typical =
applications anyway but just "power users" who should be willing to =
migrate via a simple class name change. I quite strongly prefer this =
name to "ListableBeanFactoryImpl", actually. If we agree on the new =
name, let's better change it now instead of in the 1.0 RC phase.
>
>=20
>
I am ok with the name change, as it does make sense.

Btw, as per another email, I have added a new MethodCallFactoryBean
class. It should be totally ok for this release, as no other code was
touched, and there is a full unit test.

Regards,
Colin




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Fw: [Springframework-user] MVC Exception Handling

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

Good work.

I agree that being able to throw Exception is valuable. After all, the
implementation isn't _forced_ to declare such a broad throws clause if
people want more help from the compiler.

I agree that Struts-style "declarative" exception handling makes sense. That
was one of the worthwhile features of Struts 1.1. Of course our
implementation, in true Spring style, will be more open :-)

Regards,
Rod

----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Saturday, November 22, 2003 5:14 PM
Subject: [Springframework-developer] Fw: [Springframework-user] MVC
Exception Handling


Everybody,

Continuing the tradition of last minute changes: I've repeatedly thought
about exception handling in the web tier, especially when analyzing Struts
1.1 and WebWork2. Both of the latter allow an action to throw any Exception
(Struts 1.0 did not, BTW); Struts additionally supports declarative mapping
of exception to exception handlers.

Steve, who's mail I've quoted below, has the use cast that all of his
business methods throw checked exceptions, but our web controllers just
allow ServletException. Instead of wrapping his exceptions all the time, it
would be much nicer if our web controllers would allow any Exception to be
thrown, just like Struts 1.1. and WebWork.

A poster on our forums recently noted that he would like to be able to
forward to a specific error page if he encounters certain conditions in his
form controller methods (like referenceData or formBackingObject). This is
valid concern: Such exceptions effectively exit from the normal workflow to
a well-known error page within the web MVC framework.

Therefore:

1. I've just changed all our web controller signatures from
ServletException+IOException to Exception. DispatcherServlet wraps
Exceptions other than Servlet/IO in ServletExceptions.

2. I've introduced an ExceptionResolver mechanism: DispatcherServlet
registers all implementors of the interface ExceptionResolver and allows
them to resolve exceptions to ModelAndView objects, for forwarding to
specific error pages within the web MVC framework. Of course,
ExceptionResolvers can be ordered: They get invoked one by one until a
ModelAndView was returned; if none could resolve the exception, default
handling applies.

3. I've added a simple implementation of ExceptionResolver that allows to
map exception names to view names: SimpleMappingExceptionResolver (note that
by default, no exception resolver is used). Exception names can be any part
of the exception class or the exception message. An "exceptionAttribute" is
supported: The exception gets exposed in the model under that name, by
default "exception".

4. For exiting the workflow to a specific error page, I've introduced
ModelAndViewDefiningException: If a handler throws that exception, passing a
specific ModelAndView into its constructor, DispatcherServlet will
automatically forward to the specified view - without the need for an
ExceptionResolver! This is handy for known error conditions that lead to
well-known error pages, to be checked for example at form setup in a form
controller.

I'm quite keen on introducing this already for M3, as it removes a
restriction that neither Struts nor WebWork have, and allows for cool
exception handling strategies :-) Client code should just be affected at
very specific points if at all: for example, if calling showForm in custom
handleInvalidSubmit methods, the method needs to throw Exception now instead
of ServletException - should be straightforward to adapt. It is a good thing
that we mainly work with template methods: Allowing for more exception types
to get thrown does not affect client code there.

I'll wait till tomorrow with committing these changes: If there any
objections or further suggestions, please voice them promptly!

Juergen


________________________________

Von: spr...@li... im Auftrag von Steve
Gulics
Gesendet: Di 18.11.2003 22:25
An: springframework-user
Betreff: [Springframework-user] MVC Exception Handling



I've been looking at the sample apps and have some
questions on how Spring handles exceptions.

For example, in the Pet Clinic example, if a checked
exception is thrown when
getClinic().storeOwner(owner); is called in
AddOwnerForm I want to go to a specific error page
based on that exception. I guess I could put the call
in a try-catch block and based on the exception I
return the appropriate ModelAndView. The problem with
this approach is its very tedious. Especially since
all our current BusinessDelegates throw checked
exceptions.

Stuts has a clean approach which has the Struts
Action.excute method throw Exception which allows you
to define in the struts-config.xml a handler for the
exception that will control what page to forward to.
For example
<global-exceptions>
    <exception
      key="some.key"
      type="java.io.IOException"
      handler="com.yourcorp.ExceptionHandler"/>
</global-exceptions>

See the following url for more info:
http://jakarta.apache.org/struts/userGuide/building_controller.html#exception_handler

My question is what is the perferred Spring way to
handle these situations? Is it just try-catch blocks?
I understand that the Spring approach is not to use
Checked Exceptions but I cannot control that since all
the business delegates we currently have throw checked
exception and I cannot rewrite them at this time.

thanks,
Steve


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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-user mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-user




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Fw: [Springframework-user] MVC Exception Handling

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

Everybody,
=20
Continuing the tradition of last minute changes: I've repeatedly thought =
about exception handling in the web tier, especially when analyzing =
Struts 1.1 and WebWork2. Both of the latter allow an action to throw any =
Exception (Struts 1.0 did not, BTW); Struts additionally supports =
declarative mapping of exception to exception handlers.
=20
Steve, who's mail I've quoted below, has the use cast that all of his =
business methods throw checked exceptions, but our web controllers just =
allow ServletException. Instead of wrapping his exceptions all the time, =
it would be much nicer if our web controllers would allow any Exception =
to be thrown, just like Struts 1.1. and WebWork.
=20
A poster on our forums recently noted that he would like to be able to =
forward to a specific error page if he encounters certain conditions in =
his form controller methods (like referenceData or formBackingObject). =
This is valid concern: Such exceptions effectively exit from the normal =
workflow to a well-known error page within the web MVC framework.
=20
Therefore:
=20
1. I've just changed all our web controller signatures from =
ServletException+IOException to Exception. DispatcherServlet wraps =
Exceptions other than Servlet/IO in ServletExceptions.
=20
2. I've introduced an ExceptionResolver mechanism: DispatcherServlet =
registers all implementors of the interface ExceptionResolver and allows =
them to resolve exceptions to ModelAndView objects, for forwarding to =
specific error pages within the web MVC framework. Of course, =
ExceptionResolvers can be ordered: They get invoked one by one until a =
ModelAndView was returned; if none could resolve the exception, default =
handling applies.
=20
3. I've added a simple implementation of ExceptionResolver that allows =
to map exception names to view names: SimpleMappingExceptionResolver =
(note that by default, no exception resolver is used). Exception names =
can be any part of the exception class or the exception message. An =
"exceptionAttribute" is supported: The exception gets exposed in the =
model under that name, by default "exception".
=20
4. For exiting the workflow to a specific error page, I've introduced =
ModelAndViewDefiningException: If a handler throws that exception, =
passing a specific ModelAndView into its constructor, DispatcherServlet =
will automatically forward to the specified view - without the need for =
an ExceptionResolver! This is handy for known error conditions that lead =
to well-known error pages, to be checked for example at form setup in a =
form controller.
=20
I'm quite keen on introducing this already for M3, as it removes a =
restriction that neither Struts nor WebWork have, and allows for cool =
exception handling strategies :-) Client code should just be affected at =
very specific points if at all: for example, if calling showForm in =
custom handleInvalidSubmit methods, the method needs to throw Exception =
now instead of ServletException - should be straightforward to adapt. It =
is a good thing that we mainly work with template methods: Allowing for =
more exception types to get thrown does not affect client code there.
=20
I'll wait till tomorrow with committing these changes: If there any =
objections or further suggestions, please voice them promptly!
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag von =
Steve Gulics
Gesendet: Di 18.11.2003 22:25
An: springframework-user
Betreff: [Springframework-user] MVC Exception Handling



I've been looking at the sample apps and have some
questions on how Spring handles exceptions.

For example, in the Pet Clinic example, if a checked
exception is thrown when
getClinic().storeOwner(owner); is called in
AddOwnerForm I want to go to a specific error page
based on that exception. I guess I could put the call
in a try-catch block and based on the exception I
return the appropriate ModelAndView. The problem with
this approach is its very tedious. Especially since
all our current BusinessDelegates throw checked
exceptions.

Stuts has a clean approach which has the Struts
Action.excute method throw Exception which allows you
to define in the struts-config.xml a handler for the
exception that will control what page to forward to.
For example
<global-exceptions>
    <exception
      key=3D"some.key"
      type=3D"java.io.IOException"
      handler=3D"com.yourcorp.ExceptionHandler"/>
</global-exceptions>

See the following url for more info:
http://jakarta.apache.org/struts/userGuide/building_controller.html#excep=
tion_handler

My question is what is the perferred Spring way to
handle these situations? Is it just try-catch blocks?
I understand that the Spring approach is not to use
Checked Exceptions but I cannot control that since all
the business delegates we currently have throw checked
exception and I cannot rewrite them at this time.

thanks,
Steve


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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-user mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-user

Re: [Springframework-developer] MethodCallFactoryBean added, now MethodInvokingFactoryBean

[Colin S. <col...@ex...>]

I've actually renamed it to MethodInvokingFactoryBean, which is 
hopefully better all around.

Docs are now very specific about the singleton default. If anybody else 
thinks it should not be singleton by default, feel free to speak up.


Rod Johnson wrote:

>>I just realized that most of Spring refers to method invocations, not
>>    
>>
>method calls. Would people prefer that this class be called
>MethodInvocationFactoryBean instead?
>Yes.
>
>Probably singleton should default to true, but it would need to be well
>documented as this could confuse people in odd cases if they didn't realise
>there was caching.
>
>Regards,
>Rod
>
>----- Original Message ----- 
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Sent: Friday, November 21, 2003 11:54 PM
>Subject: [Springframework-developer] MethodCallFactoryBean added
>
>
>  
>
>>As per a previous message, I have added a new FactoryBean implementation
>>called MethodCallFactoryBean. It's a factory bean which will return the
>>result of a method call, either on a static class method as specified
>>via a fully qualified method name
>>     package1.package2.package3.ClassName.MethodName
>>or alternately the result of a method call on a ref bean in the context.
>>
>>The factory bean has an internal singleton property, which is true by
>>default. In this case, the method is only called the first time, and
>>subsequent invocations of getObject() on the factory will return the
>>exact same result. If the singleton property is set to false, then the
>>target method will be invoked on each call to getObject() on the bean.
>>
>>The following is an example of using the new factory bean to get at a
>>system property:
>>
>> <bean id="sysProps"
>>class="org.springframework.beans.factory.config.MethodCallFactoryBean">
>>   <property
>>
>>    
>>
>name="staticMethod"><value>java.lang.System.getProperties</value></property>
>  
>
>> </bean>
>> <bean id="javaVersion"
>>class="org.springframework.beans.factory.config.MethodCallFactoryBean">
>>   <property name="target"><ref local='sysProps'/></property>
>>   <property name="targetMethod"><value>getProperty</value></property>
>>   <property name="args">
>>     <list>
>>       <value>|java.version|</value>
>>     </list>
>>   </property>
>> </bean>
>>
>>I just realized that most of Spring refers to method invocations, not
>>method calls. Would people prefer that this class be called
>>MethodInvocationFactoryBean instead?
>>
>>Does anybody think the default value for the singleton property should
>>be false instead of true? My feeling is that most of the time this will
>>be used to call factories, so you would not want to do a method call on
>>each getBean() call...
>>
>>Regards,
>>Colin
>>
>>    
>>

Re: [Springframework-developer] MethodCallFactoryBean added

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

>I just realized that most of Spring refers to method invocations, not
method calls. Would people prefer that this class be called
MethodInvocationFactoryBean instead?
Yes.

Probably singleton should default to true, but it would need to be well
documented as this could confuse people in odd cases if they didn't realise
there was caching.

Regards,
Rod

----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Friday, November 21, 2003 11:54 PM
Subject: [Springframework-developer] MethodCallFactoryBean added


> As per a previous message, I have added a new FactoryBean implementation
> called MethodCallFactoryBean. It's a factory bean which will return the
> result of a method call, either on a static class method as specified
> via a fully qualified method name
>      package1.package2.package3.ClassName.MethodName
> or alternately the result of a method call on a ref bean in the context.
>
> The factory bean has an internal singleton property, which is true by
> default. In this case, the method is only called the first time, and
> subsequent invocations of getObject() on the factory will return the
> exact same result. If the singleton property is set to false, then the
> target method will be invoked on each call to getObject() on the bean.
>
> The following is an example of using the new factory bean to get at a
> system property:
>
>  <bean id="sysProps"
> class="org.springframework.beans.factory.config.MethodCallFactoryBean">
>    <property
>
name="staticMethod"><value>java.lang.System.getProperties</value></property>
>
>  </bean>
>  <bean id="javaVersion"
> class="org.springframework.beans.factory.config.MethodCallFactoryBean">
>    <property name="target"><ref local='sysProps'/></property>
>    <property name="targetMethod"><value>getProperty</value></property>
>    <property name="args">
>      <list>
>        <value>|java.version|</value>
>      </list>
>    </property>
>  </bean>
>
> I just realized that most of Spring refers to method invocations, not
> method calls. Would people prefer that this class be called
> MethodInvocationFactoryBean instead?
>
> Does anybody think the default value for the singleton property should
> be false instead of true? My feeling is that most of the time this will
> be used to call factories, so you would not want to do a method call on
> each getBean() call...
>
> Regards,
> Colin
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] 1.0 M3 prepared

[Colin S. <col...@ex...>]

jürgen höller [werk3AT] wrote:

>Everybody,
> 
>I've just prepared the release as far as possible: fixed all javadoc errors, added missing package javadocs, tested the samples. All tests for shipped components pass on my machine (when running via Ant).
> 
>The TLD is now loaded from the spring.jar file, referenced via the default URI http://www.springframework.org/tags (analogous to Struts and JSTL). BaseCommandController uses setCommandName now, with setBeanName being deprecated.
> 
>Whoever wants to give it a try, fetch the latest CVS contents, run the release target, and "play user" with spring-framework-1.0-m3.zip (it's in the target/release directrory): unzip it, browse through the docs, build the sample wars (call ant warfile or warfile.bat) and drop them into your container's webapps directory.
> 
>Alef, could you give the tiles-example a final try? I'm not keen on including struts.jar in the Spring distribution, so the example should be prepared for deployment with a manually added struts.jar.
> 
>A final note on a further naming issue: I'm not entirely happy with "ListableBeanFactoryImpl". For example, BeanWrapperImpl is *the* implementation of BeanWrapper, hardly any chance for alternative implementations - the interface is rather a simplified API for it. But ListableBeanFactoryImpl implements ConfigurableListableBeanFactory with registration methods for a specific properties format; this seems to be a different case to me.
> 
>So wouldn't it be more appropriate to call it "DefaultListableBeanFactory"? That name change should not affect typical applications anyway but just "power users" who should be willing to migrate via a simple class name change. I quite strongly prefer this name to "ListableBeanFactoryImpl", actually. If we agree on the new name, let's better change it now instead of in the 1.0 RC phase.
> 
>  
>
I am ok with the name change, as it does make sense.

Btw, as per another email, I have added a new MethodCallFactoryBean 
class. It should be totally ok for this release, as no other code was 
touched, and there is a full unit test.

Regards,
Colin

[Springframework-developer] MethodCallFactoryBean added

[Colin S. <col...@ex...>]

As per a previous message, I have added a new FactoryBean implementation 
called MethodCallFactoryBean. It's a factory bean which will return the 
result of a method call, either on a static class method as specified 
via a fully qualified method name
     package1.package2.package3.ClassName.MethodName
or alternately the result of a method call on a ref bean in the context.

The factory bean has an internal singleton property, which is true by 
default. In this case, the method is only called the first time, and 
subsequent invocations of getObject() on the factory will return the 
exact same result. If the singleton property is set to false, then the 
target method will be invoked on each call to getObject() on the bean.

The following is an example of using the new factory bean to get at a 
system property:

 <bean id="sysProps" 
class="org.springframework.beans.factory.config.MethodCallFactoryBean">
   <property 
name="staticMethod"><value>java.lang.System.getProperties</value></property> 

 </bean>
 <bean id="javaVersion" 
class="org.springframework.beans.factory.config.MethodCallFactoryBean">
   <property name="target"><ref local='sysProps'/></property>
   <property name="targetMethod"><value>getProperty</value></property>
   <property name="args">
     <list>
       <value>|java.version|</value>
     </list>
   </property>
 </bean>

I just realized that most of Spring refers to method invocations, not 
method calls. Would people prefer that this class be called 
MethodInvocationFactoryBean instead?

Does anybody think the default value for the singleton property should 
be false instead of true? My feeling is that most of the time this will 
be used to call factories, so you would not want to do a method call on 
each getBean() call...

Regards,
Colin

Re: [Springframework-developer] 1.0 M3 prepared

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

Thanks Juergen.

I assume the release includes the AOP change log?

Regarding ListableBeanFactoryImpl -> DefaultListableBeanFactory that's fine
by me.

Regards,
Rod

----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Friday, November 21, 2003 11:26 PM
Subject: [Springframework-developer] 1.0 M3 prepared


Everybody,

I've just prepared the release as far as possible: fixed all javadoc errors,
added missing package javadocs, tested the samples. All tests for shipped
components pass on my machine (when running via Ant).

The TLD is now loaded from the spring.jar file, referenced via the default
URI http://www.springframework.org/tags (analogous to Struts and JSTL).
BaseCommandController uses setCommandName now, with setBeanName being
deprecated.

Whoever wants to give it a try, fetch the latest CVS contents, run the
release target, and "play user" with spring-framework-1.0-m3.zip (it's in
the target/release directrory): unzip it, browse through the docs, build the
sample wars (call ant warfile or warfile.bat) and drop them into your
container's webapps directory.

Alef, could you give the tiles-example a final try? I'm not keen on
including struts.jar in the Spring distribution, so the example should be
prepared for deployment with a manually added struts.jar.

A final note on a further naming issue: I'm not entirely happy with
"ListableBeanFactoryImpl". For example, BeanWrapperImpl is *the*
implementation of BeanWrapper, hardly any chance for alternative
implementations - the interface is rather a simplified API for it. But
ListableBeanFactoryImpl implements ConfigurableListableBeanFactory with
registration methods for a specific properties format; this seems to be a
different case to me.

So wouldn't it be more appropriate to call it "DefaultListableBeanFactory"?
That name change should not affect typical applications anyway but just
"power users" who should be willing to migrate via a simple class name
change. I quite strongly prefer this name to "ListableBeanFactoryImpl",
actually. If we agree on the new name, let's better change it now instead of
in the 1.0 RC phase.

Juergen



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer