springframework-developer — Spring Framework developers list

[Springframework-developer] PropertiesConfigurer, Log4jConfig, getResourceAsStream

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

SSd2ZSByZWNlbnRseSBmaW5pc2hlZCBzb21lIG5ldyBtaW5vciBmZWF0dXJlczoNCg0KLSBQcm9w
ZXJ0aWVzQ29uZmlndXJlcjogQW4gQXBwbGljYXRpb25Db250ZXh0QXdhcmUgYmVhbiB0aGF0IHJl
YWRzIGEgY3VzdG9tIGNvbmZpZyAocHJvcGVydGllcykgZmlsZSBhbmQgc2V0cyBhcmJpdHJhcnkg
YmVhbiBwcm9wZXJ0aWVzIGFjY29yZGluZ2x5LiBUaGlzIGlzIG1lYW50IGZvciBhZG1pbmlzdHJh
dG9yIGNvbmZpZyBmaWxlcyAoYWRtaW5pc3RyYXRvcnMgc2hvdWxkbid0IGtub3cgYWJvdXQgYmVh
biBkZWZpbml0aW9uIGZpbGVzKSB0aGF0IHNpbXBseSBvdmVycmlkZSB2YXJpb3VzIGJlYW4gcHJv
cGVydHkgZGVmYXVsdHMuIFRoZSBjb25maWcgZmlsZSBmb3JtYXQgaXMgImJlYW5OYW1lLnByb3Bl
cnR5PXZhbHVlIiAtIGRlc2NyaXB0aXZlIGFuZCBoYW5keS4gSSdtIG5vdCBzdXJlIGFib3V0IHRo
ZSBuYW1lICJQcm9wZXJ0aWVzQ29uZmlndXJlciIgdGhvdWdoIC0gYW55IHN1Z2dlc3Rpb25zPyBN
YXliZSAiUHJvcGVydHlGaWxlQ29uZmlndXJlciI/DQoNCi0gTG9nNGpDb25maWc6IFNwZWNpYWwg
TG9nNEogaW5pdGlhbGl6YXRpb24gc3VwcG9ydCBmb3Igd2ViIGFwcHMgKGluIGNvbS5pbnRlcmZh
Y2UyMS53ZWIudXRpbC5sb2c0aiksIGluc3RlYWQgb2YgTG9nNEoncyBpbXBsaWNpdCBzdGFuZGFy
ZCBpbml0aWFsaXphdGlvbi4gQWxsb3dzIGZvciBsb2c0aiBjb25maWcgcmVmcmVzaCBjaGVja3Mg
dmlhIGNvbmZpZ3VyZUFuZFdhdGNoLCBhbmQgc3VwcG9ydHMgbG9nIGZpbGUgcm9vdCBkaXJlY3Rv
cmllcyBwZXIgd2ViIGFwcC4gVGhlIHNpbXBsZSByZXF1aXJlbWVudCBmb3IgdGhlIGxhdHRlciBp
cyB0aGF0IG9uZSBzaG91bGQgYmUgYWJsZSB0byBwdXQgbG9nIGZpbGVzIGluIHRoZSB3ZWIgYXBw
J3MgV0VCLUlORiBkaXJlY3RvcnksIHVzaW5nIGEgcGF0aCByZWxhdGl2ZSB0byB0aGUgd2ViIGFw
cCByb290LiBJJ3ZlIGFwcHJvYWNoZWQgdGhpcyBpc3N1ZSB2aWEgY3VzdG9tIEZpbGVBcHBlbmRl
ciBzdWJjbGFzc2VzIG5hbWVkIFJlbGF0aXZlUGF0aEZpbGVBcHBlbmRlciBhbmQgUmVsYXRpdmVQ
YXRoUm9sbGluZ0ZpbGVBcHBlbmRlciB0aGF0IGFkZCBzdXBwb3J0IGZvciBMb2c0akNvbmZpZydz
IGxvZ0ZpbGVSb290IHByb3BlcnR5LiBUaGVyZSBhcmUgYm90aCBhIExvZzRqQ29uZmlnTGlzdGVu
ZXIgYW5kIGEgTG9nNGpDb25maWdTZXJ2bGV0IHRoYXQgYXV0b21hdGljYWxseSBzZXQgdGhpcyBw
cm9wZXJ0eS4gQWRkaXRpb25hbGx5LCBMb2c0akNvbmZpZ1NlcnZsZXQgYWRkcyBzdXBwb3J0IGZv
ciBjdXN0b20gTG9nNEogY29uZmlnIGZpbGUgbG9jYXRpb25zIGFuZCBjb25maWd1cmFibGUgcmVm
cmVzaCBjaGVja3MuDQoNCi0gQXBwbGljYXRpb25Db250ZXh0LmdldFJlc291cmNlQXNTdHJlYW06
IEEgbmV3IG1ldGhvZCBvZiBBcHBsaWNhdGlvbkNvbnRleHQgdGhhdCBzdXBwb3J0cyBjb250ZXh0
LXJlbGF0aXZlIHJlc291cmNlIGxvYWRpbmcsIGFuYWxvZ291cyB0byBTZXJ2bGV0Q29udGV4dC5n
ZXRSZXNvdXJjZUFzU3RyZWFtLiBUaGUgZGVmYXVsdCBpbXBsZW1lbnRhdGlvbiBpbiBBYnN0cmFj
dEFwcGxpY2F0aW9uQ29udGV4dCBzdXBwb3J0cyBmdWxseSBxdWFsaWZpZWQgVVJMcywgYWJzb2x1
dGUgZmlsZSBwYXRocywgYW5kIGZpbGUgcGF0aHMgcmVsYXRpdmUgdG8gdGhlIFZNIGV4ZWN1dGlv
biBkaXJlY3RvcnkuIFRoZSBpbXBsZW1lbnRhdGlvbiBpbiBYbWxXZWJBcHBsaWNhdGlvbkNvbnRl
eHQgaW50ZXJwcmV0cyByZWxhdGl2ZSBmaWxlIHBhdGhzIGFzIHJlbGF0aXZlIHRvIHRoZSB3ZWIg
YXBwIHJvb3QgZGlyZWN0b3J5LiBUaGlzIGFsbG93cyBmb3IgbG9hZGluZyBvZiBmaWxlcyByZWxh
dGl2ZSB0byB0aGUgd2ViIGFwcCByb290IHdpdGhvdXQgaW50cm9kdWNpbmcgd2ViIGRlcGVuZGVu
Y2llcywgZS5nLiBpbiBBYnN0cmFjdFhtbEFwcGxpY2F0aW9uQ29udGV4dCwgUHJvcGVydGllc0Nv
bmZpZ3VyZXIsIGFuZCBWZWxvY2l0eUNvbmZpZ3VyZXIuIFJlbGF0aXZlIGZpbGUgcGF0aHMgYXJl
IHNpbXBseSBpbnRlcnByZXRlZCBhcyByZWxhdGl2ZSB0byB0aGUgVk0gZXhlY3V0aW9uIGRpcmVj
dG9yeSBpbiB0aGUgbm9uLXdlYiBjYXNlLg0KDQpUaGUgbGF0dGVyIGlzIGFscmVhZHkgY2hlY2tl
ZCBpbiBzaW5jZSBGcmlkYXksIGFjY29tcGFueWluZyB0aGUgbmV3IE1lc3NhZ2VTb3VyY2UgdW5p
dCB0ZXN0cy4gSSB3aWxsIGNoZWNrIGluIHRoZSBvdGhlciB0d28gc29vbiBpZiB0aGVyZSBhcmVu
J3QgYW55IGJldHRlciBzdWdnZXN0aW9ucyBpbiB0ZXJtcyBvZiBkaWZmZXJlbnQgc29sdXRpb25z
IHRvIHRoZSBzYW1lIHByb2JsZW1zLiANCg0KSnVlcmdlbg0KDQoNCkRJIErDvHJnZW4gSMO2bGxl
ciANClNlbmlvciBTeXN0ZW0gQXJjaGl0ZWN0IA0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXyANCg0Kd2VyazNBVFMgLSBkaXZpc2lvbiBzeXN0ZW1lbnR3aWNrbHVuZyANCnBhcnQg
b2Ygd2VyazNBVCBpbnRlcm5ldG1lZGllbiBvZWcgDQoNCmV1cm9wYXBsYXR6IDQgDQpBIC0gNDAy
MCBsaW56IA0KDQp0LiAgKzQzICgwKSA3MzIgNzEgNjUgMjkgDQpmLiAgKzQzICgwKSA3MzIgNzEg
NjUgMjkgMyANCmp1ZXJnZW4uaG9lbGxlckB3ZXJrM2F0LmNvbSANCnd3dy53ZXJrM2F0LmNvbSAN
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQp3ZXJrM0FUUyAtIFdJUiBFTlRX
SUNLRUxOIEVSRk9MRyANCg0K

[Springframework-developer] MessageSource API functionality feedback

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

One of the signatures of the overloads to the MessageSource interface will look like this:

        String getMessage(String code, Locale locale, Object args[], String defaultMessage);


Currently the code I have will substitute the args parameter into the message it finds from the associated MessageSource class's resolve function.  What it does not do, is substitute in the args into the defaultMessage param.  So the caller of this method must "fill in all the args" when they create the value to place within the defaultMessage.  Is this the behavior you'd like?  

My opinion is to have the method internally fill in the arg values for the user the same way.  (Also makes it easier for the developer to just copy and paste what they've put into the file that is storing the messages if they wish to pass it as a defaultMessage.)

RE: [Springframework-developer] Fwd: MessageSource

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

Yes, an update of my copy of the code (and a merge with my changes corrected the problem).  Thank you.
 
 jürgen_höller_[werk3AT] <jue...@we...> wrote:Hi Tony,

I'm not sure what you mean regarding the MessageSource nesting. Actually, the code that you mention looks as follows:

if ((this.messageSource instanceof NestingMessageSource) && this.parent != null) {
((NestingMessageSource) messageSource).setParent(this.parent);
}

So the PARENT application context gets the PARENT of this context's message source, i.e. RB.parent = AppCtx.parent, AppCtx.messageSource = RB. I don't see a circular reference... Could you recheck and clarify this issue?

Working with 2 message resource bundles, one for my ApplicationContext and one for my ControllerServlet, works nicely - with keys in the latter bundle, with keys in the former bundle, and with keys that do not exist in any bundle.

Regards,
Juergen



-----Original Message-----
From: Tony Falabella [mailto:ton...@ya...] 
Sent: Friday, March 14, 2003 4:40 PM
To: spr...@li...
Subject: [Springframework-developer] Fwd: MessageSource


My changes are ready to integrate for the ErrorCoded stuff - please advise on how you'd like to coordinate it. (My preference would be to allow me to integrate and I will do as Juergen did, giving a high level description of what I did with each of the classes.)
I am however, now getting an error in one of the tests I wrote but never integrated for the ResourceMessageBundle, and it is a result of the change Juergen made to the ResouceBundleMessageSource. Juergen's change was to return a null if a MissingResourceException is thrown rather than throwing the an exception so that you traverse to the parent to try to resolve the msg. HIS CHANGE APPEARS TO BE CORRECT. However it appears to have uncovered another problem. 
When trying to resolve a message, I now get caught in an infininant loop. What I am seeing is the following:

I have 2 objects to deal with in the test I am running. The ResourceBundleMessageSource (call this RB) and the XMLWebApplicationContext. (AppCtx)

Upon startup, the AbstractApplicationContext.refresh() method gets called. Within it the ResourceBundleMessageSource bean is obtained from the factory. Then the following code is run:
if ((this.messageSource instanceof NestingMessageSource) && this.parent != null) {
( (NestingMessageSource) messageSource).setParent(this.messageSource);
}

Ultimately, what happens is that the we get a circular reference with, RB.parent = AppCtx, AppCtx.messageSource = RB. The resolver keeps going in a loop.
So I guess my first question is, what should the MessageSource's parent be, when it belongs to a Ctx? Should it be the Ctx itself, the Ctx parent, or the Ctx parent's MessageSource? (I haven't yet tested it, but I think it should be the Ctx parent's MessageSource).

Re: [Springframework-developer] mock objects

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

I like the new naming you've come up with.  We are using a similar naming convention on a project I am currently on.  For us however, the "mock" package convention can be at various "levels" within the package structure.  For example we might have "com.interface21.web.mock" and "com.interface21.web.bind.mock".
 
 jürgen_höller_[werk3AT] <jue...@we...> wrote:Hi everybody,

I'm currently trying to integrate the basic mock objects from the test tree into the src tree, on the occasion of writing some test suites for an application project that uses Spring. The rationale behind this is that most of the mock objects are not just useful for Spring tests but also for application tests. This demands including them in the Spring distribution, and thus moving them to the main source tree. Besides, the "servletapi", "mo.ejb", and "jdbc" package names in the test tree aren't proper anyway.

My main need are the JNDI mocks that allow for building a JNDI tree with the application's environment, containing JDBC data sources and in our case Hibernate session factories - completely without any container. To achieve this, I've created a new SimpleDataSource mock that simply returns new connections on every getConnection call - which works nicely with Hibernate (BTW, in contrast to SingleConnectionDataSource that cannot handle standard Connection.close calls). TestDataSource is now in com.interface21.jdbc.core in the test tree, derived from SimpleDataSource.

Thus, I've moved the JNDI mocks to com.interface21.jndi.mock, and the JDBC mocks (SimpleDataSource and SingleConnectionDataSource) to com.interface21.jdbc.mock. Consequently, I've additionally moved the 2 EJB mocks to com.interface21.ejb.mock, and the Servlet mocks to com.interface21.web.mock. I don't use the latter 2 for application tests currently, but I might choose to do so sometime.

Of course, this step adds a few classes to the main source tree and to the distribution JARS, but that couple of KBs is hardly worth thinking about. I'd mainly like to know if anyone objects to moving these mock objects to the main source tree as a matter of principle, and if the new package names would be OK.

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:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] mock objects

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

Perfect.  Similiarly I created all my mock test objects in
com.interface21.jdbc.mock , so it sounds like it will stay compatible.

Rod, do we have a new clover jar available?  The current one is =
expired, and
I wanted to run coverage tests before submitting my jdbc tests (I =
emailed
you a few days ago, but may have messed up the address).

Trevor D. Cook


-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]
Sent: March 14, 2003 1:53 PM
To: spr...@li...
Subject: [Springframework-developer] mock objects


Hi everybody,

I'm currently trying to integrate the basic mock objects from the test =
tree
into the src tree, on the occasion of writing some test suites for an
application project that uses Spring. The rationale behind this is that =
most
of the mock objects are not just useful for Spring tests but also for
application tests. This demands including them in the Spring =
distribution,
and thus moving them to the main source tree. Besides, the =
"servletapi",
"mo.ejb", and "jdbc" package names in the test tree aren't proper =
anyway.

My main need are the JNDI mocks that allow for building a JNDI tree =
with the
application's environment, containing JDBC data sources and in our case
Hibernate session factories - completely without any container. To =
achieve
this, I've created a new SimpleDataSource mock that simply returns new
connections on every getConnection call - which works nicely with =
Hibernate
(BTW, in contrast to SingleConnectionDataSource that cannot handle =
standard
Connection.close calls). TestDataSource is now in =
com.interface21.jdbc.core
in the test tree, derived from SimpleDataSource.

Thus, I've moved the JNDI mocks to com.interface21.jndi.mock, and the =
JDBC
mocks (SimpleDataSource and SingleConnectionDataSource) to
com.interface21.jdbc.mock. Consequently, I've additionally moved the 2 =
EJB
mocks to com.interface21.ejb.mock, and the Servlet mocks to
com.interface21.web.mock. I don't use the latter 2 for application =
tests
currently, but I might choose to do so sometime.

Of course, this step adds a few classes to the main source tree and to =
the
distribution JARS, but that couple of KBs is hardly worth thinking =
about.
I'd mainly like to know if anyone objects to moving these mock objects =
to
the main source tree as a matter of principle, and if the new package =
names
would be OK.

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:Crypto Challenge is now open!=20
Get cracking and register here for some mind boggling fun and=20
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
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.459 / Virus Database: 258 - Release Date: 2/25/03
=20

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

[Springframework-developer] mock objects

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

Hi everybody,

I'm currently trying to integrate the basic mock objects from the test =
tree into the src tree, on the occasion of writing some test suites for =
an application project that uses Spring. The rationale behind this is =
that most of the mock objects are not just useful for Spring tests but =
also for application tests. This demands including them in the Spring =
distribution, and thus moving them to the main source tree. Besides, the =
"servletapi", "mo.ejb", and "jdbc" package names in the test tree aren't =
proper anyway.

My main need are the JNDI mocks that allow for building a JNDI tree with =
the application's environment, containing JDBC data sources and in our =
case Hibernate session factories - completely without any container. To =
achieve this, I've created a new SimpleDataSource mock that simply =
returns new connections on every getConnection call - which works nicely =
with Hibernate (BTW, in contrast to SingleConnectionDataSource that =
cannot handle standard Connection.close calls). TestDataSource is now in =
com.interface21.jdbc.core in the test tree, derived from =
SimpleDataSource.

Thus, I've moved the JNDI mocks to com.interface21.jndi.mock, and the =
JDBC mocks (SimpleDataSource and SingleConnectionDataSource) to =
com.interface21.jdbc.mock. Consequently, I've additionally moved the 2 =
EJB mocks to com.interface21.ejb.mock, and the Servlet mocks to =
com.interface21.web.mock. I don't use the latter 2 for application tests =
currently, but I might choose to do so sometime.

Of course, this step adds a few classes to the main source tree and to =
the distribution JARS, but that couple of KBs is hardly worth thinking =
about. I'd mainly like to know if anyone objects to moving these mock =
objects to the main source tree as a matter of principle, and if the new =
package names would be OK.

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] MessageSource

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

I'll try them tonight.  Also, I will be committing some ResourceBundleMessageSourceTestSuite class when I integrate.  Hopefully we aren't duplicating efforts. 
I'll let you know know what I find. 
 jürgen_höller_[werk3AT] <jue...@we...> wrote: Actually, there weren't any MessageSource test cases around, not before and not after my changes. So I have just added some tests to AbstractApplicationContextTests/StaticApplicationContextTests/WebApplicationContextTests, and also some slight reworking of exception handling in AbstractNestingMessageSource and ResourceBundleMessageSource. It's already committed, please give it a try! On my installation, all tests pass.

BTW, I hope that everything compiles - I'm currently trying some name changes concerning the mock objects, but haven't committed them yet, so I had to commit very selectively.

Juergen


-----Original Message-----
From: Tony Falabella [mailto:ton...@ya...] 
Sent: Friday, March 14, 2003 5:16 PM
To: jürgen höller [werk3AT]; spr...@li...
Subject: RE: [Springframework-developer] MessageSource


Yes, you are correct about the line in the code (that was a mod I made to try to break the circular ref problem I was encountering). Perhaps it is my ResourceBundleTestSuite I constructed. 
Juergen, can you point me at a test case you have that does the nested msg source? The problem is only seen by me if it is not resolved in ANY context AND you did not pass in a defaultMessage. 
Thanks. 


-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] MessageSource

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

Actually, there weren't any MessageSource test cases around, not before =
and not after my changes. So I have just added some tests to =
AbstractApplicationContextTests/StaticApplicationContextTests/WebApplicat=
ionContextTests, and also some slight reworking of exception handling in =
AbstractNestingMessageSource and ResourceBundleMessageSource. It's =
already committed, please give it a try! On my installation, all tests =
pass.

BTW, I hope that everything compiles - I'm currently trying some name =
changes concerning the mock objects, but haven't committed them yet, so =
I had to commit very selectively.

Juergen


-----Original Message-----
From: Tony Falabella [mailto:ton...@ya...]=20
Sent: Friday, March 14, 2003 5:16 PM
To: j=FCrgen h=F6ller [werk3AT]; =
spr...@li...
Subject: RE: [Springframework-developer] MessageSource


Yes, you are correct about the line in the code (that was a mod I made =
to try to break the circular ref problem I was encountering).  Perhaps =
it is my ResourceBundleTestSuite I constructed. =20
Juergen, can you point me at a test case you have that does the nested =
msg source?  The problem is only seen by me if it is not resolved in ANY =
context AND you did not pass in a defaultMessage.=20
Thanks.=20

RE: [Springframework-developer] MessageSource

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

Yes, you are correct about the line in the code (that was a mod I made to try to break the circular ref problem I was encountering).  Perhaps it is my ResourceBundleTestSuite I constructed.  
Juergen, can you point me at a test case you have that does the nested msg source?  The problem is only seen by me if it is not resolved in ANY context AND you did not pass in a defaultMessage.
Thanks.
 jürgen_höller_[werk3AT] <jue...@we...> wrote:Hi Tony,

I'm not sure what you mean regarding the MessageSource nesting. Actually, the code that you mention looks as follows:

if ((this.messageSource instanceof NestingMessageSource) && this.parent != null) {
((NestingMessageSource) messageSource).setParent(this.parent);
}

So the PARENT application context gets the PARENT of this context's message source, i.e. RB.parent = AppCtx.parent, AppCtx.messageSource = RB. I don't see a circular reference... Could you recheck and clarify this issue?

Working with 2 message resource bundles, one for my ApplicationContext and one for my ControllerServlet, works nicely - with keys in the latter bundle, with keys in the former bundle, and with keys that do not exist in any bundle.

Regards,
Juergen



-----Original Message-----
From: Tony Falabella [mailto:ton...@ya...] 
Sent: Friday, March 14, 2003 4:40 PM
To: spr...@li...
Subject: [Springframework-developer] Fwd: MessageSource


My changes are ready to integrate for the ErrorCoded stuff - please advise on how you'd like to coordinate it. (My preference would be to allow me to integrate and I will do as Juergen did, giving a high level description of what I did with each of the classes.)
I am however, now getting an error in one of the tests I wrote but never integrated for the ResourceMessageBundle, and it is a result of the change Juergen made to the ResouceBundleMessageSource. Juergen's change was to return a null if a MissingResourceException is thrown rather than throwing the an exception so that you traverse to the parent to try to resolve the msg. HIS CHANGE APPEARS TO BE CORRECT. However it appears to have uncovered another problem. 
When trying to resolve a message, I now get caught in an infininant loop. What I am seeing is the following:

I have 2 objects to deal with in the test I am running. The ResourceBundleMessageSource (call this RB) and the XMLWebApplicationContext. (AppCtx)

Upon startup, the AbstractApplicationContext.refresh() method gets called. Within it the ResourceBundleMessageSource bean is obtained from the factory. Then the following code is run:
if ((this.messageSource instanceof NestingMessageSource) && this.parent != null) {
( (NestingMessageSource) messageSource).setParent(this.messageSource);
}

Ultimately, what happens is that the we get a circular reference with, RB.parent = AppCtx, AppCtx.messageSource = RB. The resolver keeps going in a loop.
So I guess my first question is, what should the MessageSource's parent be, when it belongs to a Ctx? Should it be the Ctx itself, the Ctx parent, or the Ctx parent's MessageSource? (I haven't yet tested it, but I think it should be the Ctx parent's MessageSource).

[Springframework-developer] Fwd: MessageSource

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

My changes are ready to integrate for the ErrorCoded stuff - please advise on how you'd like to coordinate it.  (My preference would be to allow me to integrate and I will do as Juergen did, giving a high level description of what I did with each of the classes.)

I am however, now getting an error in one of the tests I wrote but never integrated for the ResourceMessageBundle, and it is a result of the change Juergen made to the ResouceBundleMessageSource.  Juergen's change was to return a null if a MissingResourceException is thrown rather than throwing the an exception so that you traverse to the parent to try to resolve the msg.  HIS CHANGE APPEARS TO BE CORRECT.  However it appears to have uncovered another problem.  

When trying to resolve a message,  I now get caught in an infininant loop.  What I am seeing is the following:
 
I have 2 objects to deal with in the test I am running.  The ResourceBundleMessageSource (call this RB) and the XMLWebApplicationContext. (AppCtx)
 

Upon startup, the AbstractApplicationContext.refresh() method gets called.  Within it the ResourceBundleMessageSource bean is obtained from the factory.  Then the following code is run:

  if ((this.messageSource instanceof NestingMessageSource) && this.parent != null) {
   ( (NestingMessageSource) messageSource).setParent(this.messageSource);
  }


Ultimately, what happens is that the we get a circular reference with, RB.parent = AppCtx, AppCtx.messageSource = RB.  The resolver keeps going in a loop.

So I guess my first question is, what should the MessageSource's parent be, when it belongs to a Ctx?  Should it be the Ctx itself, the Ctx parent, or the Ctx parent's MessageSource?  (I haven't yet tested it, but I think it should be the Ctx parent's MessageSource).

 


 

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. :-)