springframework-developer

[Springframework-developer] 1.0 M3 prepared

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

Everybody,
=20
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).
=20
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.
=20
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.
=20
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.
=20
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.
=20
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
Juergen
=20

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

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