springframework-developer — Spring Framework developers list

RE: [Springframework-developer] Release schedule

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

Hi Paul,

Thanks for the contribution, anyway! Every feedback is helpful, be it =
bug reports, enhancement requests, or code contributions.

I guess that a lot of people will face your situation, i.e. having to =
use Struts due to project or even company standards. So straightforward =
integration between Struts and Spring is definitely a must. If we can =
achieve this so easily via ContextLoaderServlet/Listener and =
WebApplicationContextUtils, using a ServletContext attribute underneath, =
then this is really good news.

BTW, you are already part of the group! ;-) Seriously, if you want to =
take part, then try the current snapshot and report your experiences. Go =
through the API, or even some implementation, and note any obvious =
shortcomings. Within a short time, we need to write or review =
documentation for the website. There are so many ways to contribute!

Regards,
Juergen


> -----Original Message-----
> From: Paul Feaviour [mailto:pau...@ho...]=20
> Sent: Monday, March 10, 2003 3:28 PM
> To: Rod Johnson; Spring Developers (E-mail)
> Subject: Re: [Springframework-developer] Release schedule
>=20
>=20
> Guys,
>=20
> I would have to Juergen's analysis of the Struts plugin that=20
> I submitted - it does seem superfluous.  The plugin increases=20
> the number of 3rd party dependencies and this seems pointless=20
> if we can achieve the same end by using ServletContext.  I=20
> wrote it purely because my current project already uses=20
> Struts - not my decision - and was pointed in the direction=20
> of the plugin via the book.  I never thought of the=20
> alternatives, plus I was keen to submit something and become=20
> part of the group.
>=20
> I have a question regarding data access that I'd appreciate=20
> some help on: I need to write to and retrieve data from a=20
> clob - what would you say my best approach is, and can I use=20
> the data access framework?
>=20
> Regards,
>=20
> Paul
>=20
> ----- Original Message -----
> From: "Rod Johnson" <rod...@in...>
> To: "Trevor Cook" <tc...@in...>; "Spring=20
> Developers (E-mail)" <spr...@li...>
> Sent: Saturday, March 08, 2003 6:01 AM
> Subject: Re: [Springframework-developer] Release schedule
>=20
>=20
> > Trevor
> >
> > >  I was out-of-town for the past week with 2 deaths in the family.
> >
> > Sorry to hear this.
> >
> > > I will have the jdbc tests I promised committed by the end of the
> weekend.
> > >Sorry for the delay( especially to Thomas).  Also, this new test=20
> > >coverage puts the jdbc objects package over 85%.
> > I've added a couple of methods to JdbcTemplate and two new=20
> interfaces,=20
> > PreparedStatementSetter and BulkPreparedStatement setter. =20
> The aim is=20
> > to provide an easy-to-use API when we don't need to create the PS,=20
> > just set values on it.  I did this test-first (as I am doing=20
> > consistently now), so test coverage is up marginally.
> >
> > This coverage on the jdbc.object package is great! Thanks a lot!
> >
> > <trevor>
> > Finally, I agree with Juergen.  I've found it very easy to hook up=20
> > Spring
> to
> > various projects, and Struts appears to be similiarly easy.  Rather=20
> > than having native struts support inside Spring, it would=20
> propbably be=20
> > better
> to
> > simply maintain a how-to tutorial on integrating Spring=20
> with Struts. =20
> > It would accomplish the same thing without affecting the=20
> code base and=20
> > introducing dependancies. </trevor>
> >
> > Yes, my first thought was to do exactly as Paul did. (In=20
> fact I think=20
> > I mention it in the book somewhere.) But the ServletContext does=20
> > provide communication.
> >
> > Despite my low opinion of Struts, I think we have to help users who=20
> > want
> to
> > use Struts + Spring, as many people are committed to Struts=20
> and still=20
> > need many of the services Spring provides.
> >
> > Paul, what do you think?
> >
> > Regards,
> > Rod
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Etnus, makers of TotalView, The
> debugger
> > for complex code. Debugging C/C++ programs can leave you=20
> feeling lost=20
> > and disoriented. TotalView can help you find your way. Available on=20
> > major UNIX and Linux platforms. Try it free. www.etnus.com=20
> > _______________________________________________
> > Springframework-developer mailing list=20
> > Spr...@li...
> >=20
> https://lists.sourceforge.net/lists/listinfo/s> =
pringframework-developer
> >
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

[Springframework-developer] Current changes and next steps

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

Hi everybody,

Again some API polishing of the validation and web packages, checked in =
yesterday:

- introduced ObjectError in addition to FieldError
  (the field-specific FieldError extends the global ObjectError)

- changed error arrays returned by Errors interface to error lists
  (collections suit the new diversity of Object/FieldError better than =
arrays)

- introduced BindUtils for simple custom binding and validation
  (refactored version of the BaseCommandController code, for custom =
controllers)

- renamed HttpServletRequestDataBinder to ServletRequestDataBinder
  (it doesn't depend on HttpServletRequest)

- added text property to message tag
  (to be able to output arbitrary text too, with general HTML escaping =
support)

FYI, my next steps:

- improving doc and test coverage of the validation and web packages =
(0.8/0.9)

- support for multipart request handling (0.9)

I guess it would make sense if everybody gave a short informal outline =
of his next steps, including the target milestone (0.8/0.9/1.0), just to =
make sure that we're all aware, and that our efforts don't overlap.

Regards,
Juergen


DI J=FCrgen H=F6ller
Senior System Architect
__________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG

Re: [Springframework-developer] Fwd: [expertj2ee_with_rodjohnson] Endless loop with XmlBeanFactory example

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

Thanks Tony, I've emailed the guy asking for him to send me the code and
letting him know about the open source project.

Regards,
Rod

----- Original Message -----
From: "Anthony Falabella" <ton...@ho...>
To: <spr...@li...>
Sent: Monday, March 10, 2003 8:28 PM
Subject: [Springframework-developer] Fwd: [expertj2ee_with_rodjohnson]
Endless loop with XmlBeanFactory example


> Rod,
>
> I'm not sure if you're monitoring the mailing list wrox set up for you.
> Just in case, this one looked like something you might want to test for
with
> your BeanFactory changes...
>
>
>
>
>
>
> >From: "Michael Pinard" <B0...@FD...>
> >Reply-To: "ExpertJ2EE with RodJohnson"
> ><exp...@p2...>
> >To: "ExpertJ2EE with RodJohnson"
<exp...@p2...>
> >Subject: [expertj2ee_with_rodjohnson] Endless loop with XmlBeanFactory
> >example
> >Date: Mon, 10 Mar 2003 14:16:21 -0500
> >
> >
> >
> >
> >
> >When setting up the example from the book using the XmlBeanFactory, the
> >bean factory initialization process went into an endless loop with the
> >following XML due to the circular reference.  I have been able to modify
> >the code to allow circular references for singletons by tweaking
> >AbstractBeanFactory a bit.
> >
> ><?xml version="1.0" encoding="UTF-8"?>
> ><beans>
> >      <bean name="rod"
> >           singleton="true"
> >           class="TestBean">
> >           <property name="name">Rod</property>
> >           <property name="age">31</property>
> >           <property name="spouse" beanRef="true">kerry</property>
> >      </bean>
> >
> >      <bean name="kerry"
> >           singleton="true"
> >           class="TestBean">
> >           <property name="name">Kerry</property>
> >           <property name="age">34</property>
> >           <property name="spouse" beanRef="true">rod</property>
> >      </bean>
> ></beans>
> >
> >Thanks,
> >
> >Michael Pinard
> >Federated Systems Group
> >mp...@fd...
> >678.474.3085
> >
> >
> >---
> >Change your mail options at http://p2p.wrox.com/manager.asp or
> >to unsubscribe send a blank email to
> >lea...@p2....
>
>
> _________________________________________________________________
> MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
> http://join.msn.com/?page=features/virus
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Fwd: [expertj2ee_with_rodjohnson] Endless loop with XmlBeanFactory example

[Anthony F. <ton...@ho...>]

Rod,

I'm not sure if you're monitoring the mailing list wrox set up for you.  
Just in case, this one looked like something you might want to test for with 
your BeanFactory changes...






>From: "Michael Pinard" <B0...@FD...>
>Reply-To: "ExpertJ2EE with RodJohnson" 
><exp...@p2...>
>To: "ExpertJ2EE with RodJohnson" <exp...@p2...>
>Subject: [expertj2ee_with_rodjohnson] Endless loop with XmlBeanFactory 
>example
>Date: Mon, 10 Mar 2003 14:16:21 -0500
>
>
>
>
>
>When setting up the example from the book using the XmlBeanFactory, the
>bean factory initialization process went into an endless loop with the
>following XML due to the circular reference.  I have been able to modify
>the code to allow circular references for singletons by tweaking
>AbstractBeanFactory a bit.
>
><?xml version="1.0" encoding="UTF-8"?>
><beans>
>      <bean name="rod"
>           singleton="true"
>           class="TestBean">
>           <property name="name">Rod</property>
>           <property name="age">31</property>
>           <property name="spouse" beanRef="true">kerry</property>
>      </bean>
>
>      <bean name="kerry"
>           singleton="true"
>           class="TestBean">
>           <property name="name">Kerry</property>
>           <property name="age">34</property>
>           <property name="spouse" beanRef="true">rod</property>
>      </bean>
></beans>
>
>Thanks,
>
>Michael Pinard
>Federated Systems Group
>mp...@fd...
>678.474.3085
>
>
>---
>Change your mail options at http://p2p.wrox.com/manager.asp or
>to unsubscribe send a blank email to 
>lea...@p2....


_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.  
http://join.msn.com/?page=features/virus

Re: [Springframework-developer] Release schedule

[Paul F. <pau...@ho...>]

Guys,

I would have to Juergen's analysis of the Struts plugin that I submitted -
it does seem superfluous.  The plugin increases the number of 3rd party
dependencies and this seems pointless if we can achieve the same end by
using ServletContext.  I wrote it purely because my current project already
uses Struts - not my decision - and was pointed in the direction of the
plugin via the book.  I never thought of the alternatives, plus I was keen
to submit something and become part of the group.

I have a question regarding data access that I'd appreciate some help on: I
need to write to and retrieve data from a clob - what would you say my best
approach is, and can I use the data access framework?

Regards,

Paul

----- Original Message -----
From: "Rod Johnson" <rod...@in...>
To: "Trevor Cook" <tc...@in...>; "Spring Developers
(E-mail)" <spr...@li...>
Sent: Saturday, March 08, 2003 6:01 AM
Subject: Re: [Springframework-developer] Release schedule


> Trevor
>
> >  I was out-of-town for the past week with 2 deaths in the family.
>
> Sorry to hear this.
>
> > I will have the jdbc tests I promised committed by the end of the
weekend.
> >Sorry for the delay( especially to Thomas).  Also, this new test coverage
> >puts the jdbc objects package over 85%.
> I've added a couple of methods to JdbcTemplate and two new interfaces,
> PreparedStatementSetter and BulkPreparedStatement setter.  The aim is to
> provide an easy-to-use API when we don't need to create the PS, just set
> values on it.  I did this test-first (as I am doing consistently now), so
> test coverage is up marginally.
>
> This coverage on the jdbc.object package is great! Thanks a lot!
>
> <trevor>
> Finally, I agree with Juergen.  I've found it very easy to hook up Spring
to
> various projects, and Struts appears to be similiarly easy.  Rather than
> having native struts support inside Spring, it would propbably be better
to
> simply maintain a how-to tutorial on integrating Spring with Struts.  It
> would accomplish the same thing without affecting the code base and
> introducing dependancies.
> </trevor>
>
> Yes, my first thought was to do exactly as Paul did. (In fact I think I
> mention it in the book somewhere.) But the ServletContext does provide
> communication.
>
> Despite my low opinion of Struts, I think we have to help users who want
to
> use Struts + Spring, as many people are committed to Struts and still need
> many of the services Spring provides.
>
> Paul, what do you think?
>
> Regards,
> Rod
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The
debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on major UNIX
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] BeanFactory changes

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

I like the changes you've made.  Removal of support for the old way is also fine with me.
BTW - I expect to have the ErrorCoded changes ready for Thurs.  The changes will not include anything for Exceptions, and msg resolution only occurs from the Context's MessageSource (as you and Juergen proposed).
 Rod Johnson <rod...@in...> wrote:Guys,

I've just checked in the following changes to the BeanFactory:

Instead of the "custom bean definition" support used so far, which I was
never entirely happy with, I've implemented a simpler and more elegant
approach to introducing an additional step of indirection if necessary in
creating a bean.

If a bean implements the new com.interface21.beans.factory.FactoryBean
interface, it is automatically considered a factory and used to create
beans.

This can be used to replace the current way of returning EJB references, and
also for the forthcoming AOP support. (The present mechanism could not
easily support the kind of thing I wanted for AOP.)

It's used as follows--there are no longer any special XML tags, and support
is no longer limited to XML bean definitions:

class="com.interface21.beans.factory.DummyFactory">

false



It's possible to specify "pass-through" properties, which will be applied to
the new instance after it has been returned by the factory. In general, the
factory can configure the managed instances any way it likes, but pass
through support is useful for some things, and is included in the "custom
definition" mechanism.

class="com.interface21.beans.factory.DummyFactory">

true



name=passThrough




The propertyValues are converted from a string using a new property editor.

It's also possible to "dereference" a factory bean, to programmatically
configure the factory. For example,

DummyFactory df = (DummyFactory) beanFactory.getBean("&prototypeFactory");

This is also something that I want for the AOP stuff, but I think it's
useful in general. An exception is thrown if the named bean isn't a factory
bean. I think I must have chosen the syntax because I was feeling nostalgic
about programming in C after chatting with some friends yesterday!

The reason I'm writing this is so that everyone is aware of the new
functionality, but also to see if everyone is happy if I delete support for
the old "custom definitions " approach. (I haven't changed it so far.)

This will have the disadvantage of making some of the text in the book out
of date (which I don't much like in general), but I think it's worthwhile. I
don't like having more than one way of doing something: it makes source code
hard to maintain and confuses users.

As Juergen and others have said, I think we should be ready to deprecate and
prune, especially in the early stages. Otherwise it's just too easy to end
up with a bloated mess that's unpleasant to work on and doesn't give users
clear direction.

Thus I would like to remove the old custom bean definition code before 0.8
(ie, next week), unless anyone has any objection.

As I've been doing for the past few months, I've developed this test first,
so test coverage should also be slightly improved. I've added a few other
additional BeanFactory tests, as well.

I'm about to start updating the book's sample application to use Spring, so
that it can be our first sample app. I'm looking forward to trying the new
JDBC stuff in anger.

Should we put samples apps and non-trivial examples in their own modules in
CVS?

Regards,
Rod



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

RE: [Springframework-developer] BeanFactory changes

[Kopylenko, D. <dko...@ac...>]

Hello everyone,

>I'm about to start updating the book's sample application to use Spring, so
>that it can be our first sample app. I'm looking forward to trying the new
>JDBC stuff in anger.

>Should we put samples apps and non-trivial examples in their own modules in
>CVS?

Rod, it would really be great if you also include the full test suite for
the sample app.

Thanks,

Dmitriy.




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

RE: [Springframework-developer] BeanFactory changes

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

Hi Rod, everyone,

> Instead of the "custom bean definition" support used so far,=20
> which I was never entirely happy with, I've implemented a=20
> simpler and more elegant approach to introducing an=20
> additional step of indirection if necessary in creating a bean.
>=20
> If a bean implements the new com.interface21.beans.factory.FactoryBean
> interface, it is automatically considered a factory and used=20
> to create beans.

As I've already stated previously, I consider this a welcome and =
appropriate change.

> It's also possible to "dereference" a factory bean, to=20
> programmatically configure the factory. For example,
>=20
> DummyFactory df =3D (DummyFactory)=20
> beanFactory.getBean("&prototypeFactory");

I'm not entirely sure if I endorse the syntax, but I don't really mind =
it either. Wouldn't a BeanFactory.getFactoryBean(String) method to the =
job too?

> The reason I'm writing this is so that everyone is aware of=20
> the new functionality, but also to see if everyone is happy=20
> if I delete support for the old "custom definitions "=20
> approach. (I haven't changed it so far.)

> Thus I would like to remove the old custom bean definition=20
> code before 0.8 (ie, next week), unless anyone has any objection.

I don't object, quite on the contrary. I'm not a fan of dragging along =
deprecated APIs at all.

> As I've been doing for the past few months, I've developed=20
> this test first, so test coverage should also be slightly=20
> improved. I've added a few other additional BeanFactory=20
> tests, as well.

BTW, I still owe Spring some more tests for LocaleResolver, validation =
support, and the like. Definitely forthcoming, although I'm not sure if =
I can make it for 0.8. There are still some minor API and functionality =
issues within validation and web support that I'd like to address. =
Repeat to myself: "test first", "test first", "test first"... ;-)

> I'm about to start updating the book's sample application to=20
> use Spring, so that it can be our first sample app. I'm=20
> looking forward to trying the new JDBC stuff in anger.
>
> Should we put samples apps and non-trivial examples in their=20
> own modules in CVS?

Thumbs up! I've already thought about the book's sample app and its =
current state.

Concerning CVS structure, it would definitely make sense to separate =
non-trivial examples. I'm just not sure about the most convenient way. =
How do we generate the libs for the sample apps, to allow for easy setup =
from CVS? The example apps will probably depend on the main module for =
building etc - this should be achievable with a separate module that =
references the main module's build script.

Finally, in terms of distribution: Should there be a separate examples =
download, or should they be included in the main download? Do we like to =
separate binary and source distribution (analogous to Tomcat), or offer =
a combined one (analogous to Log4J)? Do we include all the third-party =
libraries or just give respective download URLs? Or do we include all =
but specific larger ones that not everyone will need, like Velocity?

Personally, I tend to prefer a combined download for developers, =
including sources, third party libs, and Spring binaries (usable =
out-of-the-nox for both application and framework development) - =
provided that it is of reasonable size (currently just ~1500 KB, without =
Velocity). Of course, it would make sense to offer a binary-only =
download too, with just the libraries needed for application development =
(i.e. no Clover, no mock objects, etc - currently ~650 KB, again without =
Velocity). So even with generated JavaDocs, some additional docs, and an =
example app, the combined download will probably not exceed 2 MB, and =
the binary download clock in around 1 MB.

The only drawback is that users have to copy some framework and third =
party JARs to WEB-INF\lib if they want to run the example app, but this =
should be easy to document. Of course, we could go the Struts/WebWork =
way of providing preassembled WARs and EARs that duplicate all the =
libraries - but look at their distribution file sizes, ~20 MB/~17 MB for =
the zipped versions... I believe that Spring's distribution size should =
express Spring's general slimness and clearness, thus I vote for a =
"normalized" distribution.

Regards,
Juergen

[Springframework-developer] BeanFactory changes

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

Guys,

I've just checked in the following changes to the BeanFactory:

Instead of the "custom bean definition" support used so far, which I was
never entirely happy with, I've implemented a simpler and more elegant
approach to introducing an additional step of indirection if necessary in
creating a bean.

If a bean implements the new com.interface21.beans.factory.FactoryBean
interface, it is automatically considered a factory and used to create
beans.

This can be used to replace the current way of returning EJB references, and
also for the forthcoming AOP support. (The present mechanism could not
easily support the kind of thing I wanted for AOP.)

It's used as follows--there are no longer any special XML tags, and support
is no longer limited to XML bean definitions:

<bean name="prototypeFactory"
 class="com.interface21.beans.factory.DummyFactory">
    <property name="singleton">false</property>
</bean>

It's possible to specify "pass-through" properties, which will be applied to
the new instance after it has been returned by the factory. In general, the
factory can configure the managed instances any way it likes, but pass
through support is useful for some things, and is included in the "custom
definition" mechanism.

<bean name="factoryPassThrough"
     class="com.interface21.beans.factory.DummyFactory">
 <property name="singleton">true</property>
 <property name="propertyValues">
  name=passThrough
 </property>
</bean>

The propertyValues are converted from a string using a new property editor.

It's also possible to "dereference" a factory bean, to programmatically
configure the factory. For example,

DummyFactory df = (DummyFactory) beanFactory.getBean("&prototypeFactory");

This is also something that I want for the AOP stuff, but I think it's
useful in general. An exception is thrown if the named bean isn't a factory
bean. I think I must have chosen the syntax because I was feeling nostalgic
about programming in C after chatting with some friends yesterday!

The reason I'm writing this is so that everyone is aware of the new
functionality, but also to see if everyone is happy if I delete support for
the old "custom definitions " approach. (I haven't changed it so far.)

This will have the disadvantage of making some of the text in the book out
of date (which I don't much like in general), but I think it's worthwhile. I
don't like having more than one way of doing something: it makes source code
hard to maintain and confuses users.

As Juergen and others have said, I think we should be ready to deprecate and
prune, especially in the early stages. Otherwise it's just too easy to end
up with a bloated mess that's unpleasant to work on and doesn't give users
clear direction.

Thus I would like to remove the old custom bean definition code before 0.8
(ie, next week), unless anyone has any objection.

As I've been doing for the past few months, I've developed this test first,
so test coverage should also be slightly improved. I've added a few other
additional BeanFactory tests, as well.

I'm about to start updating the book's sample application to use Spring, so
that it can be our first sample app. I'm looking forward to trying the new
JDBC stuff in anger.

Should we put samples apps and non-trivial examples in their own modules in
CVS?

Regards,
Rod

Re: [Springframework-developer] File upload aka multipart request handling

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

SGkgZmlsZSB1cGxvYWRlcnMsDQogDQpDb25jZXJuaW5nIFNwcmluZyBtdWx0aXBhcnQgaGFuZGxp
bmc6IFRoZXJlJ3MgYSBzZWNvbmQgd2F5IG9mIHByb3ZpZGluZyBwbHVnZ2FibGUgbXVsdGlwYXJ0
IHN1cHBvcnQgdGhhdCBJIHByZWZlciBpbiB0aGUgbWVhbnRpbWUuIFRoZSBnb2FsIGlzIHN0aWxs
IHRvIGF1dG9tYXRpY2FsbHkgZXhjaGFuZ2UgdGhlIEh0dHBTZXJ2bGV0UmVxdWVzdCB3aXRoIGEg
TXVsdGlwYXJ0U2VydmxldFJlcXVlc3QgaW4gY2FzZSBvZiAibXVsdGlwYXJ0L2Zvcm0tZGF0YSIu
IEJ1dCBpbnN0ZWFkIG9mIGFkZGluZyBhIE11bHRpcGFydFJlc29sdmVyIGNhcGFiaWxpdHkgdG8g
Q29udHJvbGxlclNlcnZsZXQsIHdlIGNvdWxkIHNpbXBseSB1c2UgYSBzb3BoaXN0aWNhdGVkIHNl
cnZsZXQgZmlsdGVyIHRoYXQgaGFuZGxlcyB0aGUgcmVxdWVzdCBleGNoYW5naW5nIGJlZm9yZSBh
bmQgdGhlIHJlc291cmNlIGNsZWFudXAgYWZ0ZXIgY3VzdG9tIHJlcXVlc3QgcHJvY2Vzc2luZy4N
CiANClRoZSBiYXNpYyBpZGVhIGlzIGluc3BpcmVkIGJ5IEphc29uIEh1bnRlcidzIE11bHRpcGFy
dEZpbHRlciwgYnV0IHVzaW5nIHRoZSBnZW5lcmljIGludGVyZmFjZXMgdGhhdCBJJ3ZlIHByb3Bv
c2VkLCBhbmQgaW5jbHVkaW5nIHJlc291cmNlIGNsZWFudXAuIEFuIEFic3RyYWN0TXVsdGlwYXJ0
RmlsdGVyIGltcGxlbWVudHMgYWxsIHRoZSBwcm9jZXNzaW5nIGFuZCBjbGVhbnVwLCB1c2luZyBh
IHNpbXBsZSB0ZW1wbGF0ZSBtZXRob2QgIk11bHRpcGFydFNlcnZsZXRSZXF1ZXN0IGNyZWF0ZU11
bHRpcGFydFJlcXVlc3QoSHR0cFNlcnZsZXRSZXF1ZXN0KSIuIENvbmNyZXRlIHN1YmNsYXNzZXMg
bGlrZSBDb3NNdWx0aXBhcnRGaWx0ZXIgYW5kIEpha2FydGFNdWx0aXBhcnRGaWx0ZXIgc2ltcGx5
IGltcGxlbWVudCB0aGlzIHRlbXBsYXRlIG1ldGhvZCwgaS5lLiByZXR1cm4gdGhlaXIgaW1wbGVt
ZW50YXRpb24gb2YgdGhlIE11bHRpcGFydFNlcnZsZXRSZXF1ZXN0IGludGVyZmFjZSAoYXNzdW1h
Ymx5IGEgc3ViY2xhc3Mgb2YgYSBwcm92aWRlZCBBYnN0cmFjdE11bHRpcGFydFNlcnZsZXRSZXF1
ZXN0IHRoYXQgaW1wbGVtZW50cyB0aGUgY29udmVuaWVuY2Ugc3R1ZmYpLg0KIA0KVGhlIG1ham9y
IGFkdmFudGFnZSBvZiB0aGUgZmlsdGVyIGFwcHJvYWNoIGlzIHRoYXQgaXQgaXMgY29tcGxldGVs
eSBpbmRlcGVuZGVudCBvZiB0aGUgcmVzdCBvZiBTcHJpbmcuIEluIGZhY3QgaXQgY291bGQgYmUg
YSBzZXBhcmF0ZSBzbWFsbCBsaWJyYXJ5LCBidXQgaXQgZG9lc24ndCBuZWVkIHRvIGJlIC0gZmlu
ZS1ncmFudWxhciByZXVzYWJpbGl0eSBldmVuIGluIGEgbGFyZ2VyIGxpYnJhcnkgaXMgbW9yZSBp
bXBvcnRhbnQgdGhhbiBhIGxvdCBvZiBzbWFsbCBmcmFjdHVyZWQgSkFScywgSU1ITy4gQW55d2F5
LCBhIG11bHRpcGFydCBmaWx0ZXIgY291bGQgYmUgdXNlZCBpbiBhbnkgd2ViIGFwcGxpY2F0aW9u
LCBubyBtYXR0ZXIgd2hhdCBvdGhlciBTcHJpbmcgcGFydHMgYXJlIHVzZWQgaW4gdGhhdCBhcHAu
IEFuZCBJIGRvbid0IHNlZSBhIGRyYXdiYWNrIGNvbXBhcmVkIHRvIGRpcmVjdCBzdXBwb3J0IHdp
dGhpbiBDb250cm9sbGVyU2VydmxldCwgYXMgZmlsdGVyIG1hcHBpbmdzIGFsbG93IGZvciBmbGV4
aWJsZSBjb25maWd1cmF0aW9uLCBldmVuIHBlciBzcGVjaWZpYyBjb250cm9sbGVyIGlmIGRlc2ly
ZWQuDQogDQpBcHJvcG9zIGNvbmZpZ3VyYXRpb246IFN1Y2ggYSBmaWx0ZXIgd291bGQgaGF2ZSB0
byBiZSBjb25maWd1cmVkIGluIHdlYi54bWwgaW5zdGVhZCBvZiBpbiBhIFNwcmluZyBhcHBsaWNh
dGlvbiBjb250ZXh0LiBCdXQgdGhhdCBzaG91bGRuJ3QgbWF0dGVyLCBhcyBubyBvdGhlciBiZWFu
cyBuZWVkIHRvIGtub3cgb3IgdXNlIG11bHRpcGFydCBoYW5kbGVycy4gRm9yIGVhc2Ugb2YgcGFy
YW1ldGVyIHBhcnNpbmcsIEFic3RyYWN0TXVsdGlwYXJ0RmlsdGVyIHNob3VsZCBleHRlbmQgRmls
dGVyQmVhbiwgYSBuZXcgU3ByaW5nIGZpbHRlciBiYXNlIGNsYXNzIHRoYXQgYmluZHMgaXRzIGNv
bmZpZyBwYXJhbWV0ZXJzIHRvIGJlYW4gcHJvcGVydGllcywgYW5hbG9nb3VzIHRvIEh0dHBTZXJ2
bGV0QmVhbi4NCiANCklNTywgdGhlcmUncyBzaWduaWZpY2FudCBhZGRlZCB2YWx1ZSBpbiBzdWNo
IGEgbXVsdGlwYXJ0IGZpbHRlci4gQ09TIHByb3ZpZGVzIGEgcmF0aGVyIHByaW1pdGl2ZSBmaWx0
ZXIgd2l0aG91dCByZXNvdXJjZSBjbGVhbnVwIC0gdGhlIGFwcGxpY2F0aW9uIGRldmVsb3BlciBo
YXMgdG8gY2FyZSBhYm91dCB0ZW1wb3JhcnkgZmlsZSBjbGVhbnVwLCBldmVuIGluIGNhc2UgYSBT
ZXJ2bGV0RXhjZXB0aW9uIGJlaW5nIHRocm93biAtLCBhbmQgbm8gc3VwcG9ydCBmb3IgaW4tbWVt
b3J5IHN0b3JhZ2UuIEpha2FydGEgQ29tbW9ucyBGaWxlVXBsb2FkIHByb3ZpZGVzIHRoZSBsYXR0
ZXIgYnV0IG5vIGZpbHRlciBvciBIdHRwU2VydmxldFJlcXVlc3Qgd3JhcHBlciwgYXMgaXQgY3Vy
cmVudGx5IGp1c3Qgc2VydmVzIGFzIGxvdy1sZXZlbCBtdWx0aXBhcnQgcHJvdG9jb2wgaGFuZGxl
ciBmb3IgU3RydXRzLiBJbXBsZW1lbnRpbmcgdGhlIHByb3Bvc2VkIGFwcHJvYWNoIGZvciBib3Ro
IHNob3VsZCBiZSBzdHJhaWdodGZvcndhcmQgYW5kIHJlc3VsdCBpbiBhIHZlcnkgdGhpbiBsYXll
ciBvbiB0b3AuDQogDQpXaGF0IGRvIHlvdSB0aGluaz8NCiANCkp1ZXJnZW4NCiANCiANCg0KCS0t
LS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBKw7xyZ2VuIEjDtmxsZXIg
W21haWx0bzpqdWVyZ2VuLmhvZWxsZXJAbGl3ZXN0LmF0XSANCglHZXNlbmRldDogTW8gMjQuMDIu
MjAwMyAxNjoyNCANCglBbjogc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vm
b3JnZS5uZXQgDQoJQ2M6IA0KCUJldHJlZmY6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBG
aWxlIHVwbG9hZCBha2EgbXVsdGlwYXJ0IHJlcXVlc3QgaGFuZGxpbmcNCgkNCgkNCg0KCUhpIGV2
ZXJ5Ym9keSwNCgkNCglJJ2QgbGlrZSB0byBjb21tdW5pY2F0ZSBhbiBpZGVhIHRoYXQgSSd2ZSBi
ZWVuIHRoaW5raW5nIGFib3V0IGZvciBxdWl0ZSBhDQoJd2hpbGUuIEN1cnJlbnRseSBoYW5naW5n
IGFyb3VuZCBhdCBob21lIGJlaW5nIGEgYml0IHNpY2ssIHRoaXMgaXMgYSBnb29kIHdheQ0KCXRv
IHVzZSB0aGUgdGltZS4uLiA7LSkgQW55d2F5LCBJJ3ZlIGFscmVhZHkgcmFpc2VkIHRoZSB0b3Bp
YyBvZiB1dGlsaXR5DQoJbGlicmFyaWVzIG9uIHRoZSBXcm94IGZvcnVtIHNvbWUgdGltZSBhZ28s
IGFuZCBJJ3ZlIGRvbmUgc29tZSByZXNlYXJjaA0KCXNpbmNlLiBUaGUgbWFpbiBpc3N1ZSBpcyBm
aWxlIHVwbG9hZCBha2EgbXVsdGlwYXJ0IHJlcXVlc3QgaGFuZGxpbmcuDQoJDQoJVGhlcmUgYXJl
IGN1cnJlbnRseSAyIG5vdGV3b3J0aHkgcmV1c2FibGUgdXBsb2FkIGxpYnJhcmllczoNCgktIEph
c29uIEh1bnRlcidzIENPUyAoY29tLm9yZWlsbHkuc2VydmxldCk6IHRoZSBjbGFzc2ljLCB1bmRl
ciBKYXNvbidzICJidXkNCglteSBib29rIiBsaWNlbnNlOw0KCS0gSmFrYXJ0YSdzIENvbW1vbnMg
RmlsZVVwbG9hZCAoY3VycmVudGx5IDEuMCBiZXRhKTogYSBuZXcgYWx0ZXJuYXRpdmUsDQoJdW5k
ZXIgdGhlIEFwYWNoZSBsaWNlbnNlLg0KCQ0KCVRoZSBsYXR0ZXIgaXMgbm93IHRoZSBkZWZhdWx0
IGltcGxlbWVudGF0aW9uIG9mIFN0cnV0cyAxLjEncw0KCU11bHRpcGFydFJlcXVlc3RIYW5kbGVy
IChhbHRlcm5hdGl2ZWx5LCBTdHJ1dHMgc3RpbGwgaGFzIHRoZSBvbGQgMS4wDQoJaW1wbGVtZW50
YXRpb24sIHRoZSBzaW1wbGUgRGlza011bHRpcGFydFJlcXVlc3RIYW5kbGVyKS4gQ09TIG1heSBi
ZSBvbGRlcg0KCWFuZCBiZXR0ZXIgdGVzdGVkLCBidXQgQ29tbW9ucyBGaWxlVXBsb2FkIGlzIG1v
cmUgc29waGlzdGljYXRlZDogRm9yDQoJZXhhbXBsZSwgaXQgY2FuIGtlZXAgdXBsb2FkZWQgZmls
ZXMgc21hbGxlciB0aGFuIGEgc3BlY2lmaWVkIHRocmVzaG9sZCBpbg0KCW1lbW9yeSBpbnN0ZWFk
IG9mIHdyaXRpbmcgZXZlcnl0aGluZyB0ZW1wb3JhcmlseSB0byBkaXNrLg0KCQ0KCU15IGdvYWwg
aXMgdG8gc3VwcG9ydCBmaWxlIHVwbG9hZCB3aXRoaW4gU3ByaW5nJ3Mgd2ViIHBhY2thZ2UsIGlu
IGENCglzdHJhaWdodGZvcndhcmQgYW5kIHBsdWdnYWJsZSB3YXkuIFRoZSBvYnZpb3VzIHdheSB3
b3VsZCBiZSBzb21lIG11bHRpcGFydA0KCWNoZWNrIGluIENvbnRyb2xsZXJTZXJ2bGV0J3MgZG9T
ZXJ2aWNlIG1ldGhvZCB0aGF0IGV4Y2hhbmdlcyB0aGUgc3RhbmRhcmQNCglIdHRwU2VydmxldFJl
cXVlc3Qgd2l0aCBhIHdyYXBwaW5nIE11bHRpcGFydFNlcnZsZXRSZXF1ZXN0IChhbiBpbnRlcmZh
Y2UNCglkZXJpdmVkIGZyb20gSHR0cFNlcnZsZXRSZXF1ZXN0KSBpZiBpdCBkZXRlY3RzIGEgbXVs
dGlwYXJ0IHJlcXVlc3QuDQoJQ29udHJvbGxlciBpbXBsZW1lbnRhdGlvbnMgY2FuIGNoZWNrIGZv
ciBhIG11bHRpcGFydCByZXF1ZXN0IHZpYSAicmVxdWVzdA0KCWluc3RhbmNlb2YgTXVsdGlwYXJ0
U2VydmxldFJlcXVlc3QiLCBvciBzaW1wbHkgY2FzdCB0byB0aGUgY2xhc3MgaWYgdGhleQ0KCWV4
cGVjdCBvbmUuDQoJDQoJVGhlIGZvbGxvd2luZyBwcm9wb3NhbCBmb3IgU3ByaW5nJ3MgbXVsdGlw
YXJ0IGhhbmRsZXIgaW50ZXJmYWNlcyBpcw0KCW9idmlvdXNseSBpbnNwaXJlZCBieSBib3RoIENP
UycgTXVsdGlwYXJ0UmVxdWVzdCBhbmQgQ29tbW9ucyBGaWxlVXBsb2FkJ3MNCglGaWxlSXRlbSBj
bGFzc2VzLCBzbyBkb24ndCBibGFtZSBtZSEgOy0pIEl0IHNob3VsZCBiZSBlYXN5IHRvIHdyaXRl
DQoJaW1wbGVtZW50YXRpb25zIGZvciBDT1MgYW5kIENvbW1vbnMgRmlsZVVwbG9hZCB0aGF0IHdl
IGNvdWxkIGluY2x1ZGUgb3V0IG9mDQoJdGhlIGJveC4gT2YgY291cnNlLCB3ZSBhcmUgb25seSBh
bGxvd2VkIHRvIGluY2x1ZGUgQ29tbW9ucyBGaWxlVXBsb2FkIGluIGENCglTcHJpbmcgZGlzdHJp
YnV0aW9uLCBpbiB0ZXJtcyBvZiBsaWNlbnNlLiBXaG9ldmVyIHdhbnRzIHRvIHVzZSBDT1MgY291
bGQNCglzaW1wbHkgZG93bmxvYWQgaXQsIGFkZCBpdCB0byBoaXMgd2ViIGFwcCBsaWJyYXJpZXMs
IGFuZCBjb25maWd1cmUgYWZmZWN0ZWQNCglTcHJpbmcgY29udHJvbGxlciBzZXJ2bGV0cyBhY2Nv
cmRpbmdseS4NCgkNCglUaGUgTXVsdGlwYXJ0U2VydmxldFJlcXVlc3QgaW50ZXJmYWNlIG5lZWRz
IHRvIHN1cHBvcnQgZ2V0UGFyYW1ldGVyIGFuZA0KCWFzc29jaWF0ZWQgbWV0aG9kcywgdG8gYmUg
YWJsZSB0byBoYW5kbGUgc2ltcGxlIHBhcmFtZXRlcnMgaW4gYSBtdWx0aXBhcnQNCglyZXF1ZXN0
IHRyYW5zcGFyZW50bHksIGp1c3QgbGlrZSB3aGVuIGRlYWxpbmcgd2l0aCBhIG5vcm1hbCByZXF1
ZXN0LiBGb3INCglmaWxlIGhhbmRsaW5nLCBJIHByb3Bvc2UgdG8gYWRkIHRoZSBmb2xsb3dpbmcg
bWV0aG9kcyBiZXlvbmQNCglIdHRwU2VydmxldFJlcXVlc3QsIGFuYWxvZ291cyB0byBwYXJhbWV0
ZXIgaGFuZGxpbmc6DQoJLSBNdWx0aXBhcnRGaWxlIGdldEZpbGUoU3RyaW5nIG5hbWUpLi4uIHJl
dHVybmluZyBhIGZpbGUgZGVzY3JpcHRvciBmb3IgdGhlDQoJc3BlY2lmaWVkIGZpbGUsIG9yIG51
bGwNCgktIE1hcCBnZXRGaWxlTWFwKCkuLi4gcmV0dXJuaW5nIGEgTWFwIHdpdGggZmlsZSBuYW1l
cyBhcyBrZXlzIGFuZA0KCU11bHRpcGFydEZpbGUgaW5zdGFuY2VzIGFzIHZhbHVlcw0KCS0gY2xl
YXJGaWxlUmVzb3VyY2VzKCkuLi4gY2xlYXJpbmcgYWxsIHRlbXBvcmFyeSBmaWxlIHJlc291cmNl
cw0KCShhdXRvbWF0aWNhbGx5IGNhbGxlZCBieSBDb250cm9sbGVyU2VydmxldCBhZnRlciBDb250
cm9sbGVyIHByb2Nlc3NpbmcpDQoJDQoJTXVsdGlwYXJ0RmlsZSBpcyBhbiBpbnRlcmZhY2Ugd2l0
aCB0aGUgZm9sbG93aW5nIG1ldGhvZHM6DQoJLSBJbnB1dFN0cmVhbSBnZXRJbnB1dFN0cmVhbSgp
Li4uIHJldHVybmluZyBhbiBpbnB1dCBzdHJlYW0gd2l0aCB0aGUNCgljb250ZW50cyBvZiB0aGUg
ZmlsZQ0KCS0gU3RyaW5nIGdldEZpbGVOYW1lKCkuLi4gcmV0dXJuaW5nIHRoZSBvcmlnaW5hbCBm
aWxlIG5hbWUgZ2l2ZW4gYnkgdGhlDQoJY2xpZW50DQoJLSBTdHJpbmcgZ2V0Q29udGVudFR5cGUo
KS4uLiByZXR1cm5pbmcgdGhlIGNvbnRlbnQgdHlwZSBnaXZlbiBieSB0aGUgY2xpZW50DQoJDQoJ
VGhlc2Ugc2hvdWxkIGFsbG93IGZvciBib3RoIHNpbXBsZSBpbXBsZW1lbnRhdGlvbnMgYW5kIHNp
bXBsZSB1c2FnZSBieQ0KCWN1c3RvbSBjb250cm9sbGVyIGltcGxlbWVudGF0aW9ucy4gVGhlIGlu
dGVyZmFjZXMgY291bGQgZXZlbiBiZSB1c2VkIGJ5DQoJSlNQcywgYXMgdGhlIHdyYXBwZWQgcmVx
dWVzdCB3aWxsIGFsc28gYmUgdXNlZCB3aGVuIGZvcndhcmRpbmcsIGFsdGhvdWdoDQoJdGhhdCBp
cyBub3QgcmVjb21tZW5kZWQgcHJhY3RpY2UuIE5vcm1hbGx5LCBhIGN1c3RvbSB1cGxvYWQgY29u
dHJvbGxlciB3aWxsDQoJZXZhbHVhdGUgdGhlIHVwbG9hZGVkIGZpbGVzIGFuZCBwYXJhbWV0ZXJz
LCBhbmQgdHJhbnNmZXIgdGhlbSB0byBzb21lDQoJYXBwbGljYXRpb24tc3BlY2lmaWMgc3RvcmFn
ZSBsb2NhdGlvbiB0aGF0IGNvdWxkIGJlIGEgZmlsZXN5c3RlbSBvciBhDQoJZGF0YWJhc2UuIEZv
ciBhcHBsaWNhdGlvbiBwcm9ncmFtbWVycywgaXQgaXMgbm90IGltcG9ydGFudCB3aGVyZSB0aGUg
ZmlsZXMNCglhcmUgc3RvcmVkIHRlbXBvcmFyaWx5IG9yIGlmIHRoZXkgYXJlIHN0b3JlZCBvbiBk
aXNrIGF0IGFsbCwgdGhlcmVmb3JlIHRoZQ0KCWludGVyZmFjZXMgZG8gbm90IGNvdmVyIHN1Y2gg
YXNwZWN0cy4gRXNzZW50aWFsbHksIG11bHRpcGFydCBoYW5kbGluZyBzaG91bGQNCgliZSBhcyBl
YXN5IGFuZCB0cmFuc3BhcmVudCBhcyBwb3NzaWJsZS4NCgkNCglGaW5hbGx5LCBob3cgd2lsbCBh
IENvbnRyb2xsZXJTZXJ2bGV0IHJldHJpZXZlIGEgTXVsdGlwYXJ0U2VydmxldFJlcXVlc3QNCglp
bnN0YW5jZSwgdXNpbmcgdGhlIHRvb2xraXQgb2YgdGhlIGFwcGxpY2F0aW9uJ3MgY2hvaWNlPyBB
IHN0cmFpZ2h0Zm9yd2FyZA0KCVNwcmluZyB3YXkgd291bGQgYmUgdG8gZGVmaW5lIGEgc3RhbmRh
cmQgYmVhbiBuYW1lICJtdWx0aXBhcnRSZXNvbHZlciINCgkoYW5hbG9nb3VzIHRvICJ2aWV3UmVz
b2x2ZXIiIGFuZCAibG9jYWxlUmVzb2x2ZXIiKSB0aGF0IG5lZWRzIHRvIGltcGxlbWVudA0KCXRo
ZSBpbnRlcmZhY2UgTXVsdGlwYXJ0UmVzb2x2ZXI6DQoJLSBNdWx0aXBhcnRTZXJ2bGV0UmVxdWVz
dCBjcmVhdGVNdWx0aXBhcnRSZXF1ZXN0KEh0dHBTZXJ2bGV0UmVxdWVzdA0KCXJlcXVlc3QpLi4u
IGNyZWF0aW5nIGEgd3JhcHBlcg0KCS0gYm9vbGVhbiBoYXNNdWx0aXBhcnRDb250ZW50KEh0dHBT
ZXJ2bGV0UmVxdWVzdCByZXF1ZXN0KS4uLiBjaGVja2luZyB0aGUNCgljb250ZW50IHR5cGUNCgkN
CglPZiBjb3Vyc2UsIENvbnRyb2xsZXJTZXJ2bGV0IHNob3VsZCBzaW1wbHkgaWdub3JlIG11bHRp
cGFydCBoYW5kbGluZyB3aGVuDQoJdGhlcmUncyBubyAibXVsdGlwYXJ0UmVzb2x2ZXIiIGJlYW4s
IG1heWJlIGxvZyBhIHdhcm5pbmcgb24gaW5pdGlhbGl6YXRpb24uDQoJDQoJV2hhdCBkbyB5b3Ug
dGhpbms/IElmIHdlIHNldHRsZSBvbiB0aGUgcHJvcG9zYWwsIEkgY291bGQgaW1wbGVtZW50IGl0
DQoJcHJvbXB0bHkgKHJpZ2h0IGFmdGVyIGxvY2FsZSByZXNvbHV0aW9uKS4gSSBkZWZpbml0ZWx5
IGNvbnNpZGVyIGZpbGUgdXBsb2FkDQoJYSAxLjAgaXNzdWUsIGFzIGJvdGggU3RydXRzIGFuZCBX
ZWJXb3JrIGhhdmUgYnVpbHQtaW4gc3VwcG9ydCBmb3IgaXQuDQoJDQoJSnVlcmdlbg0KDQo=

Re: [Springframework-developer] Bug

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

Dmitry,

Thanks for pointing this out - I have fixed the problem.

--Thomas

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

-- 
Thomas Risberg
tri...@tr...

Re: [Springframework-developer] Release schedule

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

Hi,

> -- Thomas, were are with we your JDBC changes? This is perhaps the biggest
> area of change nearly ready to go --
> -- 

I have just committed my changes to some of the JDBC classes.  Most of
my changes relate to the SQLExceptionTranslater functionality.  I
created an SQLExceptionTranslaterFactory that loads error codes defined
in a file named 'sql-error-codes.xml'.  This is done on startup, and
whenever a new JdbcTemplate class is created it will get the
SQLExceptionTranslater from this factory file.  The factory will check
to see what database is used and create a new SQLExceptionTranslater
populated with the corresponding error codes for translation.  If the
database does not have a defined set of error codes, then we will fall
back on using a SQLStateSQLExeptionTranslater.

The 'sql-error-codes.xml' is loaded from the classpath with the
XmlBeanFactory.  For a Tomcat web app I put 'sql-error-codes.xml' in the
WEB-INF\classes directory.  In general, I tend to put this file in the
same directory where I put the log4j.properties file.  To use this
functionality we need the XmlBeans classes as well as the core and jdbc
classes.  I added a task 'xmlbean' to the build script to build this
extra jar file.  I have the following jar files in my WEB-INF\lib
directory:  spring-core-0.8.jar, spring-jdbc-0.8.jar and
spring-xmlbean-0.8.jar.

I have tested and included a few codes for Oracle 9i, MySQL 4.0,
PostgreSQL 7.3, Microsoft SQL Server 2000 and IBM DB2 8.1.  Postgres
does not use any error codes or sql state currently, so we will have to
come up with an alternative strategy if we want some translations.

Let me know if there are any issues.


Thomas

Re: [Springframework-developer] Release schedule

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

Trevor

>  I was out-of-town for the past week with 2 deaths in the family.

Sorry to hear this.

> I will have the jdbc tests I promised committed by the end of the weekend.
>Sorry for the delay( especially to Thomas).  Also, this new test coverage
>puts the jdbc objects package over 85%.
I've added a couple of methods to JdbcTemplate and two new interfaces,
PreparedStatementSetter and BulkPreparedStatement setter.  The aim is to
provide an easy-to-use API when we don't need to create the PS, just set
values on it.  I did this test-first (as I am doing consistently now), so
test coverage is up marginally.

This coverage on the jdbc.object package is great! Thanks a lot!

<trevor>
Finally, I agree with Juergen.  I've found it very easy to hook up Spring to
various projects, and Struts appears to be similiarly easy.  Rather than
having native struts support inside Spring, it would propbably be better to
simply maintain a how-to tutorial on integrating Spring with Struts.  It
would accomplish the same thing without affecting the code base and
introducing dependancies.
</trevor>

Yes, my first thought was to do exactly as Paul did. (In fact I think I
mention it in the book somewhere.) But the ServletContext does provide
communication.

Despite my low opinion of Struts, I think we have to help users who want to
use Struts + Spring, as many people are committed to Struts and still need
many of the services Spring provides.

Paul, what do you think?

Regards,
Rod

RE: [Springframework-developer] Release schedule

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

Schedule looks great to me.

Also, I was out-of-town for the past week with 2 deaths in the family.  =
I
will have the jdbc tests I promised committed by the end of the =
weekend.
Sorry for the delay( especially to Thomas).  Also, this new test =
coverage
puts the jdbc objects package over 85%.

Finally, I agree with Juergen.  I've found it very easy to hook up =
Spring to
various projects, and Struts appears to be similiarly easy.  Rather =
than
having native struts support inside Spring, it would propbably be =
better to
simply maintain a how-to tutorial on integrating Spring with Struts.  =
It
would accomplish the same thing without affecting the code base and
introducing dependancies.

Trevor D. Cook


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: March 6, 2003 11:11 PM
To: j=FCrgen h=F6ller [werk3AT];
spr...@li...
Subject: Re: [Springframework-developer] Release schedule


I agree: I think a release schedule is very important. Of course it's =
hard
to commit to deadlines for open source projects, but if we want people =
to
start using Spring we need to give them a roadmap, and a download ASAP.

I think the API is unlikely to change much from now to 1.0, although =
some
internals might change a bit (e.g. JDBC changes), so I think we're =
nearly
ready for 0.8 now.

I pretty much agree with Juergen re timescales.

0.8: download, polished JavaDoc, with better package.html files. I've =
been
using EclipseUML (modelling plugin for Eclipse) and I'm impressed. I =
might
try to add some class diagrams to package.html files. How about we say =
March
23 for this (2 weeks + a weekend), as I think we're fairly close and =
there's
huge value in having a download.
We will need to coordinate tasks closely. I'm not sure how best to do =
this.
Yann, you mentioned SourceForge facilities: can you please help suggest =
how
best to use them, as I'm unsure.
-- Thomas, were are with we your JDBC changes? This is perhaps the =
biggest
area of change nearly ready to go --

0.9: Whatever we have one month later (late April). A progress release.
Would be good to get Struts plugin in here, although maybe we could =
even do
that for 0.8.

1.0 beta: Mid May. Should be exactly what we hope to have in 1.0, =
possibly
with incomplete docs.

1.0: Late May. I'm talking at TSS symposium in late June and I think it
would be great if we were at 1.0 by then, as I'd like to mention =
Spring. We
need:
- tutorial
- sample app (yes, maybe the first one could be based on the book's)
- overview docs of areas such as JDBC/Web
- website as Juergen says
- significantly improved test coverage. We're currently at 44%: I would =
like
to see >=3D 60% by 1.0, and hopefully a steady increase up till then.

No AOP in any of these releases. I'm hoping to knock that into shape =
over
the next 3 weeks, but anyone who's interested can check out CVS.

Outstanding issues:
- Packaging, regarding the old EJB/WAR class loader issues when =
deploying
WAR+EJB EARs. Hopefully the present packaging will work fine for 0.8. =
Things
may get tougher with Thomas's new JDBC stuff.

Regards,
Rod

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Thursday, March 06, 2003 10:18 AM
Subject: [Springframework-developer] Release schedule


Hi committers,

We should try to approach a 0.8 release ASAP, as the lack of a formal
distribution definitely hinders Spring adopting. IMO we should aim at =
end of
March.

Unfortunately, the lack of documentation is a major issue: Currently, a
potential user should have both Rod's book and the framework sources. I
consider polishing JavaDoc comments and including generated JavaDoc a =
must,
already for 0.8. Separate online documentation will be a must for 1.0, =
but
not earlier, I guess. Any volunteers for either?

The further schedule will probably consist of 0.9 at end of April and =
1.0
around June. Of course, the actual dates will be determined by Spring's
quality and stability, not by a deadline. Nevertheless, I have the urge =
to
proceed release-oriented.

IMHO, we are easily feature-complete for 0.8 now, as multipart request
handling can also wait until 0.9. Beyond that, we should think about =
further
must-haves for 1.0. The Struts plugin comes to my mind, for example, =
and
better test coverage and homogeneous code style. Beyond the framework
itself, we will need example apps, and a nice little website with some =
sort
of "project identity".

What do you think?

Regards,
Juergen


DI J=FCrgen H=F6ller
Senior System Architect
__________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG


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




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

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

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

[Springframework-developer] Bug

[Kopylenko, D. <dko...@ac...>]

Hello gang.

Could someone check the "bug area" on sourceforge site. :-)

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

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

> I'm not so keen on this. I think when throwing an exception,=20
> code should only provide an error code. It won't necessarily=20
> know about how messages are
> resolved: this is a presentation issue.

I agree completely. Message resolution should happen at model =
aggregation or view rendering time.

> Maybe a compromise would be to have a fallback approach, in=20
> which the ErrorResolver implementation, if it failed to look=20
> up a message for an exception's error code, looked for a=20
> ResourceBundle called messages.properties in the same package=20
> as the exception. I think this would allow what you propose,=20
> but still permit the use of an override at framework level.

I don't really like such a fallback. Hardcoding to a resource bundle =
here would kind of violate Spring's message source approach. What about =
allowing for a dedicated error message source, configured via the =
application context and specified by the error resolver?

> Btw, the present approach isn't limited to a single message=20
> source: MessageSources nest.

At least in theory... ;-)

Seriously, I've just tried it, and it didn't work with =
ResourceBundleMessageSources, due to a ResourceBundle's =
MissingResourceException going up to AbstractNestingMessageSource and =
being converted to NoSuchMessageException there.

A little fix in ResourceBundleMessageSource's resolve method, namely =
catching the MissingResourceException and converting it to a null return =
value, corrects this. I've just committed it - now MessageSources do =
indeed nest! :-)

Juergen

RE: [Springframework-developer] Release schedule

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

Paul,

I must admit I haven't thought about the internals of Struts support =
earlier. But now that I've reviewed your plugin, I am aware of how easy =
this actually is. We just need to initialize the ApplicationContext and =
expose it to the ServletContext, and off we go writing Struts actions =
that use Spring beans via retrieving the ApplicationContext from the =
ServletContext.

Facing this simple way, I wonder if we need explicit Struts support at =
all, at least in the technical sense. Isn't setting up a standard =
ContextLoaderServlet or ContextLoaderListener in web.xml just as easy as =
registering a Struts-specific plugin in struts-config.xml? The Struts =
plugin doesn't seem to add any specific handling, as the ServletContext =
contained by the ActionServlet instance should be equal to the standard =
ServletContext of the web application.

The only obvious difference seems to be the attribute name, which is not =
meant for manual usage in standard Spring. But Struts actions could =
simply retrieve the current ApplicationContext via =
com.interface21.web.context.support.WebApplicationContextUtils.getWebAppl=
icationContext(ServletContext), using Spring's standard attribute name =
underneath.

So, should we adopt my proposed pattern? Its major advantage is its =
simplicity - it does not need any specific Struts support at all, =
especially no binary dependency on Struts classes within Spring. And it =
should work nicely, at the same level of convenience as the Struts =
plugin. Is there any added value of the latter that I am missing?

Finally, with Spring's newly refactored ContextLoader class, a minimal =
Plugin implementation should do the job now, analogous to the =
ContextLoaderListener implementation - if one really needs configuration =
via struts-config.xml. Instead of replicating the initialization code, =
the following should be enough:

  public void init(ActionServlet servlet, ModuleConfig config) throws =
ServletException {
    ContextLoader.initContext(servlet.getServletContext(), =
contextClass);
  }

But still, I consider configuration via web.xml equally simple.

Regards,
Juergen


> -----Original Message-----
> From: Paul Feaviour [mailto:pau...@ho...]=20
> Sent: Thursday, March 06, 2003 12:06 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Release schedule
>=20
>=20
> Juergen/group
>=20
> Wow - I am very impressed with the amount of work you are=20
> contributing towards the Spring framework - if only I could=20
> find the time I would love to be more active.
>=20
> Personally, I think it would help if tasks were cleary=20
> defined and assigned to individuals - I am unsure what areas=20
> need looking at and am conscience that I may be duplicating=20
> effort if I just dive in.  I know that tasks are discussed=20
> within this list but this should be documented  - or does=20
> this go against the open source idealogy.
>=20
> BTW I have attached a struts plugin that I have written and=20
> am using with success - it needs reviewing.
>=20
> Here is a brief description of its use - I assume struts familarity:
>=20
> A Struts PlugIn can be used to provide close integration with=20
> Spring's bean based infrastructure.  The root=20
> com.interface21.web.context.WebApplicationContext object,=20
> which defines JavaBeans and their relationships ,can be added=20
> to a web application's ServletContext by this PlugIn, as an=20
> alternative to using the ContextLoaderServlet.
>=20
> PlugIn modules can be configured using the <plug-in> element=20
> in the struts-config.xml file.  Classes that implement the=20
> PlugIn interface must have a zero-argument constructor,=20
> configuration is performed by providing standard JavaBeans=20
> property setter methods.
>=20
> The PlugIn requires a single configuration parameter to be=20
> provided in the deployment descriptor, contextClass. This=20
> parameter is the class name of the WebApplicationContext=20
> implementation to provide a context for this
> application, in this case XmlWebApplicationContext.   The=20
> PlugIn merely
> instantiates the class and provides it with the current=20
> ServletContext object.
>=20
> <plug-in className=3D"com.phoenix.web.context.ContextLoaderPlugin">
>     <set-property property=3D"contextClass"=20
> =
value=3D"com.interface21.web.context.support.XmlWebApplicationContext"/>
> </plug-in>
>=20
> The WebApplicationContext requires a configUrl to be set in=20
> the web.xml file.  This is the URL to the configuration file=20
> that defines the business objects and their relationships. =20
> These are exposed as JavaBeans to classes in the web=20
> application framework, servlet filters and JSP custom tags.
>=20
> <context-param>
>     <param-name>configUrl</param-name>
>     <param-value>/WEB-INF/applicationContext.xml</param-value>
> </context-param>
>=20
> Struts Actions can access these business objects by looking=20
> up the WebApplicationContext in the ServletContext.
>=20
> Note:  Certain bean names have special significance and one=20
> must be provided in the configuration file, "messageSource". =20
> This defines an internationalizable repository for errors and=20
> other messages.  Even if the application uses the Struts=20
> resource bundle, this is still required, along with the=20
> messages.properties file in /WEB-INF/classes.
>=20
> <bean name=3D"messageSource"=20
> class=3D"com.interface21.context.support.ResourceBundleMessageSource">
>     <property name=3D"basename">messages</property>
> </bean>
>=20
>=20
> ----- Original Message -----
> From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> To: <spr...@li...>
> Sent: Thursday, March 06, 2003 10:18 AM
> Subject: [Springframework-developer] Release schedule
>=20
>=20
> Hi committers,
>=20
> We should try to approach a 0.8 release ASAP, as the lack of=20
> a formal distribution definitely hinders Spring adopting. IMO=20
> we should aim at end of March.
>=20
> Unfortunately, the lack of documentation is a major issue:=20
> Currently, a potential user should have both Rod's book and=20
> the framework sources. I consider polishing JavaDoc comments=20
> and including generated JavaDoc a must, already for 0.8.=20
> Separate online documentation will be a must for 1.0, but not=20
> earlier, I guess. Any volunteers for either?
>=20
> The further schedule will probably consist of 0.9 at end of=20
> April and 1.0 around June. Of course, the actual dates will=20
> be determined by Spring's quality and stability, not by a=20
> deadline. Nevertheless, I have the urge to proceed release-oriented.
>=20
> IMHO, we are easily feature-complete for 0.8 now, as=20
> multipart request handling can also wait until 0.9. Beyond=20
> that, we should think about further must-haves for 1.0. The=20
> Struts plugin comes to my mind, for example, and better test=20
> coverage and homogeneous code style. Beyond the framework=20
> itself, we will need example apps, and a nice little website=20
> with some sort of "project identity".
>=20
> What do you think?
>=20
> Regards,
> Juergen
>=20
>=20
> DI J=FCrgen H=F6ller
> Senior System Architect
> __________________________________
>=20
> werk3ATS - division systementwicklung
> part of werk3AT internetmedien oeg
>=20
> europaplatz 4
> A - 4020 linz
>=20
> t.  +43 (0) 732 71 65 29
> f.  +43 (0) 732 71 65 29 3
> jue...@we...
> www.werk3at.com
> __________________________________
> werk3ATS - WIR ENTWICKELN ERFOLG
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of=20
> TotalView, The debugger for complex code. Debugging C/C++=20
> programs can leave you feeling lost and disoriented.=20
> TotalView can help you find your way. Available on major UNIX=20
> and Linux platforms. Try it free. www.etnus.com=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20

Re: [Springframework-developer] Release schedule

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

The schedule sounds good to me as well. 
 jürgen_höller_[werk3AT] <jue...@we...> wrote: Hi committers,

We should try to approach a 0.8 release ASAP, as the lack of a formal distribution definitely hinders Spring adopting. IMO we should aim at end of March.

Unfortunately, the lack of documentation is a major issue: Currently, a potential user should have both Rod's book and the framework sources. I consider polishing JavaDoc comments and including generated JavaDoc a must, already for 0.8. Separate online documentation will be a must for 1.0, but not earlier, I guess. Any volunteers for either?

The further schedule will probably consist of 0.9 at end of April and 1.0 around June. Of course, the actual dates will be determined by Spring's quality and stability, not by a deadline. Nevertheless, I have the urge to proceed release-oriented.

IMHO, we are easily feature-complete for 0.8 now, as multipart request handling can also wait until 0.9. Beyond that, we should think about further must-haves for 1.0. The Struts plugin comes to my mind, for example, and better test coverage and homogeneous code style. Beyond the framework itself, we will need example apps, and a nice little website with some sort of "project identity".

What do you think?

Regards,
Juergen


DI Jürgen Höller
Senior System Architect
__________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

t. +43 (0) 732 71 65 29
f. +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG


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

Re: [Springframework-developer] Release schedule

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

JavaOne is also mid June...

Rod Johnson wrote:
> I agree: I think a release schedule is very important. Of course it's hard
> to commit to deadlines for open source projects, but if we want people to
> start using Spring we need to give them a roadmap, and a download ASAP.
> 
> I think the API is unlikely to change much from now to 1.0, although some
> internals might change a bit (e.g. JDBC changes), so I think we're nearly
> ready for 0.8 now.
> 
> I pretty much agree with Juergen re timescales.
> 
> 0.8: download, polished JavaDoc, with better package.html files. I've been
> using EclipseUML (modelling plugin for Eclipse) and I'm impressed. I might
> try to add some class diagrams to package.html files. How about we say March
> 23 for this (2 weeks + a weekend), as I think we're fairly close and there's
> huge value in having a download.
> We will need to coordinate tasks closely. I'm not sure how best to do this.
> Yann, you mentioned SourceForge facilities: can you please help suggest how
> best to use them, as I'm unsure.
> -- Thomas, were are with we your JDBC changes? This is perhaps the biggest
> area of change nearly ready to go --
> 
> 0.9: Whatever we have one month later (late April). A progress release.
> Would be good to get Struts plugin in here, although maybe we could even do
> that for 0.8.
> 
> 1.0 beta: Mid May. Should be exactly what we hope to have in 1.0, possibly
> with incomplete docs.
> 
> 1.0: Late May. I'm talking at TSS symposium in late June and I think it
> would be great if we were at 1.0 by then, as I'd like to mention Spring. We
> need:
> - tutorial
> - sample app (yes, maybe the first one could be based on the book's)
> - overview docs of areas such as JDBC/Web
> - website as Juergen says
> - significantly improved test coverage. We're currently at 44%: I would like
> to see >= 60% by 1.0, and hopefully a steady increase up till then.
> 
> No AOP in any of these releases. I'm hoping to knock that into shape over
> the next 3 weeks, but anyone who's interested can check out CVS.
> 
> Outstanding issues:
> - Packaging, regarding the old EJB/WAR class loader issues when deploying
> WAR+EJB EARs. Hopefully the present packaging will work fine for 0.8. Things
> may get tougher with Thomas's new JDBC stuff.
> 
> Regards,
> Rod
> 
> ----- Original Message -----
> From: "jürgen höller [werk3AT]" <jue...@we...>
> To: <spr...@li...>
> Sent: Thursday, March 06, 2003 10:18 AM
> Subject: [Springframework-developer] Release schedule
> 
> 
> Hi committers,
> 
> We should try to approach a 0.8 release ASAP, as the lack of a formal
> distribution definitely hinders Spring adopting. IMO we should aim at end of
> March.
> 
> Unfortunately, the lack of documentation is a major issue: Currently, a
> potential user should have both Rod's book and the framework sources. I
> consider polishing JavaDoc comments and including generated JavaDoc a must,
> already for 0.8. Separate online documentation will be a must for 1.0, but
> not earlier, I guess. Any volunteers for either?
> 
> The further schedule will probably consist of 0.9 at end of April and 1.0
> around June. Of course, the actual dates will be determined by Spring's
> quality and stability, not by a deadline. Nevertheless, I have the urge to
> proceed release-oriented.
> 
> IMHO, we are easily feature-complete for 0.8 now, as multipart request
> handling can also wait until 0.9. Beyond that, we should think about further
> must-haves for 1.0. The Struts plugin comes to my mind, for example, and
> better test coverage and homogeneous code style. Beyond the framework
> itself, we will need example apps, and a nice little website with some sort
> of "project identity".
> 
> What do you think?
> 
> Regards,
> Juergen

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

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

Tony,

> Very quickly though, in response to your question of "Wouldn't this mean
extending MessageSource with overloaded getMessage versions that feature an
errorArgs parameter?".  Yes,
> my changes initially started out with changing the MessageSource interface
(and the implementations) to handle passing in an "Object[] errorArgs"
param.
I'm fine with this.

> From there it let to some changes elsewhere, including looking at the
Errors object.
> One thing that should probably discuss is the concept of a single message
source.
> Initially I though a single message source would be fine, but as this is a
framework I've since
> changed my opinion.  My opinion now is this.  We can leave each Context to
have it's
> own single message source, but we can allow configuration (using the
framework's bean
> factory code) to allow other classes to have whatever message SOURCES they
need.
> Let's look at this as an example.  One of my code proposals is to add an
Exception class into the framework
> that will be able to resolve messages from a ResourceBundle.
I'm not so keen on this. I think when throwing an exception, code should
only provide an error code. It won't necessarily know about how messages are
resolved: this is a presentation issue.

Maybe a compromise would be to have a fallback approach, in which the
ErrorResolver implementation, if it failed to look up a message for an
exception's error code, looked for a ResourceBundle called
messages.properties in the same package as the exception. I think this would
allow what you propose, but still permit the use of an override at framework
level.

Btw, the present approach isn't limited to a single message source:
MessageSources nest.

> BTW - I think we should have 2 overloads for the methods that allow a
Locale to be passed in.
> If it is passed in we use it.  If it is not passed in, fall back to the
"defaultLocale".
> Currently the way I've coded the "defaultLocale" is whatever Java resolves
to.  This needs to be changed
> to work with the changes that have been made for the Locale to be passed
in from HTTPRequests.
> This definately needs to be discussed (shouldn't be a big deal).
Sounds reasonable.

Regards,
Rod

Re: [Springframework-developer] Release schedule

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

I agree: I think a release schedule is very important. Of course it's hard
to commit to deadlines for open source projects, but if we want people to
start using Spring we need to give them a roadmap, and a download ASAP.

I think the API is unlikely to change much from now to 1.0, although some
internals might change a bit (e.g. JDBC changes), so I think we're nearly
ready for 0.8 now.

I pretty much agree with Juergen re timescales.

0.8: download, polished JavaDoc, with better package.html files. I've been
using EclipseUML (modelling plugin for Eclipse) and I'm impressed. I might
try to add some class diagrams to package.html files. How about we say March
23 for this (2 weeks + a weekend), as I think we're fairly close and there's
huge value in having a download.
We will need to coordinate tasks closely. I'm not sure how best to do this.
Yann, you mentioned SourceForge facilities: can you please help suggest how
best to use them, as I'm unsure.
-- Thomas, were are with we your JDBC changes? This is perhaps the biggest
area of change nearly ready to go --

0.9: Whatever we have one month later (late April). A progress release.
Would be good to get Struts plugin in here, although maybe we could even do
that for 0.8.

1.0 beta: Mid May. Should be exactly what we hope to have in 1.0, possibly
with incomplete docs.

1.0: Late May. I'm talking at TSS symposium in late June and I think it
would be great if we were at 1.0 by then, as I'd like to mention Spring. We
need:
- tutorial
- sample app (yes, maybe the first one could be based on the book's)
- overview docs of areas such as JDBC/Web
- website as Juergen says
- significantly improved test coverage. We're currently at 44%: I would like
to see >= 60% by 1.0, and hopefully a steady increase up till then.

No AOP in any of these releases. I'm hoping to knock that into shape over
the next 3 weeks, but anyone who's interested can check out CVS.

Outstanding issues:
- Packaging, regarding the old EJB/WAR class loader issues when deploying
WAR+EJB EARs. Hopefully the present packaging will work fine for 0.8. Things
may get tougher with Thomas's new JDBC stuff.

Regards,
Rod

----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Thursday, March 06, 2003 10:18 AM
Subject: [Springframework-developer] Release schedule


Hi committers,

We should try to approach a 0.8 release ASAP, as the lack of a formal
distribution definitely hinders Spring adopting. IMO we should aim at end of
March.

Unfortunately, the lack of documentation is a major issue: Currently, a
potential user should have both Rod's book and the framework sources. I
consider polishing JavaDoc comments and including generated JavaDoc a must,
already for 0.8. Separate online documentation will be a must for 1.0, but
not earlier, I guess. Any volunteers for either?

The further schedule will probably consist of 0.9 at end of April and 1.0
around June. Of course, the actual dates will be determined by Spring's
quality and stability, not by a deadline. Nevertheless, I have the urge to
proceed release-oriented.

IMHO, we are easily feature-complete for 0.8 now, as multipart request
handling can also wait until 0.9. Beyond that, we should think about further
must-haves for 1.0. The Struts plugin comes to my mind, for example, and
better test coverage and homogeneous code style. Beyond the framework
itself, we will need example apps, and a nice little website with some sort
of "project identity".

What do you think?

Regards,
Juergen


DI Jürgen Höller
Senior System Architect
__________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG


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

[Springframework-developer] sample application

[Bob M. <bo...@ex...>]

 I think the first sample app shoud be the small skeleton code that came with the book. It should be deployable in Tomcat and not require JBoss or even a database. Has anyone converted this to work with the current build? -Bob> For a sample app,  could we use the one that came with the book?

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

Re: [Springframework-developer] Release schedule

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

Sounds like a plan to me.  However, I lean more towards a 1.0 release in 
April and pushing new features to a 1.1 release.  For a sample app, 
could we use the one that came with the book?

jürgen höller [werk3AT] wrote:
> Hi committers,
> 
> We should try to approach a 0.8 release ASAP, as the lack of a formal distribution definitely hinders Spring adopting. IMO we should aim at end of March.
> 
> Unfortunately, the lack of documentation is a major issue: Currently, a potential user should have both Rod's book and the framework sources. I consider polishing JavaDoc comments and including generated JavaDoc a must, already for 0.8. Separate online documentation will be a must for 1.0, but not earlier, I guess. Any volunteers for either?
> 
> The further schedule will probably consist of 0.9 at end of April and 1.0 around June. Of course, the actual dates will be determined by Spring's quality and stability, not by a deadline. Nevertheless, I have the urge to proceed release-oriented.
> 
> IMHO, we are easily feature-complete for 0.8 now, as multipart request handling can also wait until 0.9. Beyond that, we should think about further must-haves for 1.0. The Struts plugin comes to my mind, for example, and better test coverage and homogeneous code style. Beyond the framework itself, we will need example apps, and a nice little website with some sort of "project identity".
> 
> What do you think?
> 
> Regards,
> Juergen

Re: [Springframework-developer] Release schedule

[Paul F. <pau...@ho...>]

Juergen/group

Wow - I am very impressed with the amount of work you are contributing
towards the Spring framework - if only I could find the time I would love to
be more active.

Personally, I think it would help if tasks were cleary defined and assigned
to individuals - I am unsure what areas need looking at and am conscience
that I may be duplicating effort if I just dive in.  I know that tasks are
discussed within this list but this should be documented  - or does this go
against the open source idealogy.

BTW I have attached a struts plugin that I have written and am using with
success - it needs reviewing.

Here is a brief description of its use - I assume struts familarity:

A Struts PlugIn can be used to provide close integration with Spring's bean
based infrastructure.  The root
com.interface21.web.context.WebApplicationContext object, which defines
JavaBeans and their relationships ,can be added to a web application's
ServletContext by this PlugIn, as an alternative to using the
ContextLoaderServlet.

PlugIn modules can be configured using the <plug-in> element in the
struts-config.xml file.  Classes that implement the PlugIn interface must
have a zero-argument constructor, configuration is performed by providing
standard JavaBeans property setter methods.

The PlugIn requires a single configuration parameter to be provided in the
deployment descriptor, contextClass. This parameter is the class name of the
WebApplicationContext implementation to provide a context for this
application, in this case XmlWebApplicationContext.   The PlugIn merely
instantiates the class and provides it with the current ServletContext
object.

<plug-in className="com.phoenix.web.context.ContextLoaderPlugin">
    <set-property property="contextClass"
value="com.interface21.web.context.support.XmlWebApplicationContext"/>
</plug-in>

The WebApplicationContext requires a configUrl to be set in the web.xml
file.  This is the URL to the configuration file that defines the business
objects and their relationships.  These are exposed as JavaBeans to classes
in the web application framework, servlet filters and JSP custom tags.

<context-param>
    <param-name>configUrl</param-name>
    <param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>

Struts Actions can access these business objects by looking up the
WebApplicationContext in the ServletContext.

Note:  Certain bean names have special significance and one must be provided
in the configuration file, "messageSource".  This defines an
internationalizable repository for errors and other messages.  Even if the
application uses the Struts resource bundle, this is still required, along
with the messages.properties file in /WEB-INF/classes.

<bean name="messageSource"
class="com.interface21.context.support.ResourceBundleMessageSource">
    <property name="basename">messages</property>
</bean>


----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Thursday, March 06, 2003 10:18 AM
Subject: [Springframework-developer] Release schedule


Hi committers,

We should try to approach a 0.8 release ASAP, as the lack of a formal
distribution definitely hinders Spring adopting. IMO we should aim at end of
March.

Unfortunately, the lack of documentation is a major issue: Currently, a
potential user should have both Rod's book and the framework sources. I
consider polishing JavaDoc comments and including generated JavaDoc a must,
already for 0.8. Separate online documentation will be a must for 1.0, but
not earlier, I guess. Any volunteers for either?

The further schedule will probably consist of 0.9 at end of April and 1.0
around June. Of course, the actual dates will be determined by Spring's
quality and stability, not by a deadline. Nevertheless, I have the urge to
proceed release-oriented.

IMHO, we are easily feature-complete for 0.8 now, as multipart request
handling can also wait until 0.9. Beyond that, we should think about further
must-haves for 1.0. The Struts plugin comes to my mind, for example, and
better test coverage and homogeneous code style. Beyond the framework
itself, we will need example apps, and a nice little website with some sort
of "project identity".

What do you think?

Regards,
Juergen


DI Jürgen Höller
Senior System Architect
__________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG


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

[Springframework-developer] Release schedule

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

Hi committers,

We should try to approach a 0.8 release ASAP, as the lack of a formal =
distribution definitely hinders Spring adopting. IMO we should aim at =
end of March.

Unfortunately, the lack of documentation is a major issue: Currently, a =
potential user should have both Rod's book and the framework sources. I =
consider polishing JavaDoc comments and including generated JavaDoc a =
must, already for 0.8. Separate online documentation will be a must for =
1.0, but not earlier, I guess. Any volunteers for either?

The further schedule will probably consist of 0.9 at end of April and =
1.0 around June. Of course, the actual dates will be determined by =
Spring's quality and stability, not by a deadline. Nevertheless, I have =
the urge to proceed release-oriented.

IMHO, we are easily feature-complete for 0.8 now, as multipart request =
handling can also wait until 0.9. Beyond that, we should think about =
further must-haves for 1.0. The Struts plugin comes to my mind, for =
example, and better test coverage and homogeneous code style. Beyond the =
framework itself, we will need example apps, and a nice little website =
with some sort of "project identity".

What do you think?

Regards,
Juergen


DI J=FCrgen H=F6ller
Senior System Architect
__________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG