springframework-developer — Spring Framework developers list

Re: [Springframework-developer] Multipart File Handling

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

UC5TLjogRnVubnkgaG93IHRoZSBkaXJlY3Rpb24gb2YgYW4gb3duIGFyZ3VtZW50IGNhbiBjaGFu
Z2UgaW4gdGhlIGNvdXJzZSBvZiBhIHNpbmdsZSBlbWFpbCA7LSkgT2YgY291cnNlLCBJIHdhcyB0
YWxraW5nIGFib3V0IFByb3BlcnR5RWRpdG9yJ3Mgc2V0QXNUZXh0IChhbmQgdGhlIGluZGlyZWN0
aW9uIHdpdGggU3RyaW5nIHZhbHVlcyB0aGF0IG1hdGNoIGZpZWxkIG5hbWVzKSBpbiB0aGUgZmly
c3QgcGFyYWdyYXBoLCBhbmQgaGF2ZW4ndCBoYWQgcmVhbGl6ZWQgYXQgdGhhdCB0aW1lIHRoYXQg
dGhlcmUgd2FzIHRoZSBjb21wbGV0ZWx5IGRpZmZlcmVudCBzZXRWYWx1ZSBvcHRpb24gdG9vLi4u
DQogDQpKdWVyZ2VuDQogDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0K
CVZvbjogasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXSANCglHZXNlbmRldDogRGkgMTQuMTAuMjAw
MyAwMToyNiANCglBbjogVHJldm9yIENvb2s7IFNwcmluZyBEZXZlbG9wZXJzIA0KCUNjOiANCglC
ZXRyZWZmOiBSZTogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIE11bHRpcGFydCBGaWxlIEhh
bmRsaW5nDQoJDQoJDQoNCglUcmV2b3IsDQoJDQoJU29ycnkgaWYgSSd2ZSBiZWVuIGEgYml0IGVh
Z2VyIGluIHRlcm1zIG9mIGdldHRpbmcgcmlkIG9mIHRoZSBQcm9wZXJ0eUVkaXRvciBzdHVmZiBm
b3IgbXVsdGlwYXJ0IGZpbGVzLiBJIHN0cm9uZ2x5IGJlbGlldmUgdGhhdCB0aGUgSmF2YUJlYW5z
IFByb3BlcnR5RWRpdG9yIGlzIG5vdCBhcHByb3ByaWF0ZSBmb3IgbXVsdGlwYXJ0IGZpbGVzIHRo
b3VnaCwgYXMgaXQgaXMgYWJvdXQgY29udmVydGluZyAqU3RyaW5nKiBwYXJhbWV0ZXJzIHRvIG90
aGVyIHR5cGVzLiBUaGlzIGlzIGZpbmUgZm9yIHN0YW5kYXJkIFNlcnZsZXRSZXF1ZXN0IHBhcmFt
ZXRlcnMgdGhhdCBjb21lIGluIGFzIFN0cmluZyB2YWx1ZXMgYW5kIG5lZWQgdG8gYmUgYm91bmQg
dG8gYXJiaXRyYXJ5IHByb3BlcnRpZXMgb2YgY29tbWFuZCBvYmplY3RzLiBNdWx0aXBhcnQgZmls
ZXMgb24gdGhlIG90aGVyIGhhbmQgYXJlIGJ5IHRoZWlyIHZlcnkgbmF0dXJlIGNvbXBsZXggb2Jq
ZWN0czsgdGhleSBkbyBub3QgaGF2ZSBhIG5hdHVyYWwgU3RyaW5nIHJlcHJlc2VudGF0aW9uLg0K
CQ0KCVRoZSBwcmV2aW91cyBtZWNoYW5pc20gb2YgYmluZGluZyBtdWx0aXBhcnQgZmlsZXMgdmlh
IFByb3BlcnR5RWRpdG9yIHJlcXVpcmVkIE11bHRpcGFydEh0dHBTZXJ2bGV0UmVxdWVzdCdzIGdl
dFBhcmFtZXRlciBtZXRob2QgdG8gcmV0dXJuIHRoZSBmaWVsZCBuYW1lIGFzIHZhbHVlIGEgbGEg
Z2V0UGFyYW1ldGVyKCJteWZpZWxkIikgLT4gIm15ZmllbGQiLCBzbyB0aGF0IGEgUHJvcGVydHlF
ZGl0b3IgdGhhdCBjYW4ganVzdCBzZWUgdGhlIHZhbHVlIHdvdWxkIGJlIGFibGUgdG8gaWRlbnRp
ZnkgdGhlIGZpZWxkIG5hbWUgYW5kIGludm9rZSBNdWx0aXBhcnRIdHRwU2VydmxldFJlcXVlc3Qn
cyBnZXRGaWxlKCJteWZpZWxkIikgdG8gcmV0dXJuIHRoZSBNdWx0aXBhcnRGaWxlIGluc3RhbmNl
LiBUaGlzICppcyogYSB3b3JrYXJvdW5kLCBhcyBpdCBpcyBub3QgYXQgYWxsIG5hdHVyYWwgdG8g
aGF2ZSBnZXRQYXJhbWV0ZXIgcmV0dXJuIHRoZSBmaWVsZCBuYW1lIGFzIHZhbHVlIGluIGNhc2Ug
b2YgYSBtdWx0aXBhcnQgZmlsZS4NCgkNCglTZXJ2bGV0UmVxdWVzdERhdGFCaW5kZXIgaXMgbm90
IGEgYmFkIHBsYWNlIGZvciBiaW5kaW5nIG11bHRpcGFydCBmaWxlcywgZ2l2ZW4gdGhhdCBvdXIg
TXVsdGlwYXJ0SHR0cFNlcnZsZXRSZXF1ZXN0IGlzIGEgZ2VuZXJpYyBpbnRlcmZhY2UgdGhhdCBy
ZXNpZGVzIGluIHRoZSBub24tRGlzcGF0Y2hlclNlcnZsZXQtc3BlY2lmaWMgd2ViLm11bHRpcGFy
dCBwYWNrYWdlIG5vdy4gSSBhZ3JlZSB0aGF0IGl0IGlzbid0IGdlbmVyYWxseSBwcmVmZXJhYmxl
IHRvIGhhcmRjb2RlIGJpbmRpbmcgb3B0aW9ucywgYnV0IEkndmUgaW5pdGlhbGx5IGZlbHQgdGhh
dCB0aGVyZSBhcmVuJ3QgYW55IG90aGVyIG1lYW5pbmdmdWwgY29udmVyc2lvbnMgdGhhbiBhIE11
bHRpcGFydEZpbGUgaXRzZWxmIG9yIGEgYnl0ZVtdIGFzIHZhbHVlIG9mIGEgY29tbWFuZCBiZWFu
IHByb3BlcnR5LiBOb3RlIHRoYXQgeW91IGNhbiBhbHdheXMgb3ZlcnJpZGUgQmFzZUNvbW1hbmRD
b250cm9sbGVyJ3Mgb25CaW5kQW5kVmFsaWRhdGUgdG8gcGVyZm9ybSAqY3VzdG9tKiBiaW5kaW5n
Lg0KCQ0KCS0tLS0tDQoJDQoJT24gc2Vjb25kIHRob3VnaHQsIEkgYWdyZWUgdGhhdCBhIHBsdWdn
YWJsZSBjb252ZXJzaW9uIG1lY2hhbmlzbSBpcyBwcmVmZXJhYmxlLiBJJ3ZlIGp1c3QgcmV3b3Jr
ZWQgdGhlIG11bHRpcGFydCBiaW5kaW5nIGludG8gYSBQcm9wZXJ0eUVkaXRvciBtZWNoYW5pc20g
YWdhaW4sIGJ1dCB3aXRoIGEgZGlmZmVyZW50IGltcGxlbWVudGF0aW9uIHBhdHRlcm46IFNlcnZs
ZXRSZXF1ZXN0RGF0YUJpbmRlciBzaW1wbHkgYmluZHMgdGhlIGZpbGUgbWFwIHJldHVybmVkIGJ5
IE11bHRpcGFydEh0dHBTZXJ2bGV0UmVxdWVzdC5nZXRGaWxlTWFwIGFzIHByb3BlcnR5IHZhbHVl
cy4gVGhpcyBtZWFucyB0aGF0IGJlYW4gcHJvcGVydGllcyBvZiB0eXBlIE11bHRpcGFydEZpbGUg
Y2FuIGJlIHBvcHVsYXRlZCBkaXJlY3RseSwgd2l0aG91dCBjb252ZXJzaW9uLiBPdGhlciB0eXBl
cyBnbyB0aHJvdWdoIHRoZSBQcm9wZXJ0eUVkaXRvciBtZWNoYW5pc20sIGJ1dCB2aWEgY2FsbGlu
ZyBzZXRWYWx1ZShPYmplY3QpIGluc3RlYWQgb2Ygc2V0QXNUZXh0KFN0cmluZykuDQoJDQoJQnl0
ZUFycmF5TXVsdGlwYXJ0RmlsZUVkaXRvciBhbmQgU3RyaW5nTXVsdGlwYXJ0RmlsZUVkaXRvciBp
bXBsZW1lbnQgc2V0VmFsdWUgdG8gdHJhbnNmb3JtIHRoZSBnaXZlbiBNdWx0aXBhcnRGaWxlIGlu
c3RhbmNlIGludG8gZWl0aGVyIGEgYnl0ZSBhcnJheSBvciBhIFN0cmluZywgdGhlIGxhdHRlciB3
aXRoIGNvbmZpZ3VyYWJsZSBjaGFyc2V0LiBOb3RlIHRoYW4gbm9uZSBvZiB0aGVzZSBuZWVkcyBh
IE11bHRpcGFydEh0dHBTZXJ2bGV0UmVxdWVzdDogVGhleSByZWNlaXZlIHRoZSBNdWx0aXBhcnRG
aWxlIGluc3RhbmNlcyBib3VuZCBhcyBwcm9wZXJ0eSB2YWx1ZXMgYnkgU2VydmxldFJlcXVlc3RE
YXRhQmluZGVyLiBUaG9zZSB0d28gY3VzdG9tIGVkaXRvcnMgbmVlZCB0byBiZSByZWdpc3RlcmVk
IHdpdGggU2VydmxldFJlcXVlc3REYXRhQmluZGVyIHZpYSByZWdpc3RlckN1c3RvbUVkaXRvciwg
cHJlZmVyYWJseSBmb3Igc3BlY2lmaWMgZmllbGRzIHRvIGF2b2lkIGNvbmZsaWN0cyB3aXRoIG90
aGVyIGZpZWxkcyBvZiB0aGUgdHlwZSBieXRlIGFycmF5IG9yIFN0cmluZy4NCgkNCglJIGNvbnNp
ZGVyIHRoaXMgYSBnb29kIHNvbHV0aW9uLCBtb3JlIGZsZXhpYmxlIHRoYW4gdGhlIGhhcmRjb2Rl
ZCBiaW5kaW5nLCBidXQgYWxzbyBjbGVhbmVyIHRoYW4gdGhlIFByb3BlcnR5RWRpdG9yIGluZGly
ZWN0aW9uIHdpdGggU3RyaW5nIHBhcmFtZXRlcnMuIFRoYW5rcyBmb3IgcG9pbnRpbmcgYXQgdGhl
IGlzc3VlIGFnYWluISBPdmVycmlkaW5nIFByb3BlcnR5RWRpdG9yJ3Mgc2V0VmFsdWUgaXMgZ2Vu
ZXJhbGx5IGEgbmljZSB3YXkgdG8gY29udmVydCBmcm9tIG5vbi1TdHJpbmcgdmFsdWVzIHRvIHRo
ZSByZXF1aXJlZCB0eXBlOyBJIGRpZG4ndCB0aGluayBvZiBpdCBhdCBmaXJzdCwgYW5kIEkgaGFk
IHRvIHR3ZWFrIEJlYW5XcmFwcGVySW1wbCBhIGJpdCB0byBhbGxvdyBmb3IgaXQuIEkgaG9wZSB5
b3UgbGlrZSB0aGUgY3VycmVudCBzb2x1dGlvbiB0b287IGRvZXMgaXQgZnVsZmlsIHlvdXIgcmVx
dWlyZW1lbnRzIG5vdz8NCgkNCglKdWVyZ2VuDQoJDQoJDQoJDQoJICAgICAgICAtLS0tLVVyc3By
w7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQoJICAgICAgICBWb246IFRyZXZvciBDb29rIFttYWls
dG86cHJpc2UwM0BzZW50ZXgubmV0XQ0KCSAgICAgICAgR2VzZW5kZXQ6IE1vIDEzLjEwLjIwMDMg
MjI6MjINCgkgICAgICAgIEFuOiBqw7xyZ2VuIGjDtmxsZXIgW3dlcmszQVRdOyBTcHJpbmcgRGV2
ZWxvcGVycw0KCSAgICAgICAgQ2M6DQoJICAgICAgICBCZXRyZWZmOiBSRTogW1NwcmluZ2ZyYW1l
d29yay1kZXZlbG9wZXJdIE11bHRpcGFydCBGaWxlIEhhbmRsaW5nDQoJICAgICAgIA0KCSAgICAg
ICANCgkNCgkgICAgICAgIDxqdWVyZ2VuPg0KCSAgICAgICAgRnVydGhlcm1vcmUsIEkndmUgZHJv
cHBlZCB0aGUgcHJldmlvdXMgUHJvcGVydHlFZGl0b3JzIHN1cHBvcnQsIGFuZCB0aGUgYXNzb2Np
YXRlZCByZXF1aXJlbWVudCBmb3IgZmlsZSBwYXJhbWV0ZXJzIGhhdmluZyB0byBiZSBhdmFpbGFi
bGUgYXMgbm9ybWFsIHBhcmFtZXRlcnMgd2l0aCB0aGUgZmllbGQgbmFtZSBhcyB2YWx1ZS4gVGhh
dCBzZWVtZWQgbGlrZSBhIHdvcmthcm91bmQ7IGluc3RlYWQsIEkndmUgYWRkZWQgZXhwbGljaXQg
ZGV0ZWN0aW9uIHRvIFNlcnZsZXRSZXF1ZXN0RGF0YUJpbmRlciwgd2hpY2ggaXMgbm93IGFibGUg
dG8gYmluZCBmaWxlIHBhcmFtZXRlcnMgYXMgTXVsdGlwYXJ0RmlsZSBvciBieXRlW10sIGRlcGVu
ZGluZyBvbiB0aGUgdHlwZSBvZiB0aGUgdGFyZ2V0IGJlYW4gcHJvcGVydHkuIEkndmUgbm90IHJl
aW50cm9kdWNlZCBiaW5kaW5nIHRoZSBvcmlnaW5hbCBmaWxlIG5hbWUgdG8gYSBTdHJpbmcgcHJv
cGVydHksIGFzIEkgY2FuJ3Qgc2VlIHRoZSB2YWx1ZSBvZiB0aGF0IGZlYXR1cmUuDQoJICAgICAg
ICA8L2p1ZXJnZW4+DQoJICAgICAgIA0KCSAgICAgICAgTm8gcHJvYmxlbSBkcm9wcGluZyB0aGUg
U3RyaW5nIDw+IGZpbGVuYW1lLCBJIHdhc24ndCBzdXJlIGlmIHRoYXQgd291bGQgYmUgdXNlZnVs
IG9yIG5vdC4NCgkgICAgICAgDQoJICAgICAgICBJIGRvIGhhdmUgYSBwcm9ibGVtIHdpdGggZHJv
cHBpbmcgdGhlIFByb3BlcnR5RWRpdG9ycyBzdXBwb3J0LCBzaW5jZSBpbiBteSBtaW5kIGl0IHJl
bW92ZXMgZmxleGliaWxpdHkgYW5kIGNvbnNpc3RlbmN5Lg0KCSAgICAgICANCgkgICAgICAgIFRy
ZWF0aW5nIGFsbCB0aGUgZGF0YSAoc2ltcGxlIHRleHQgZmllbGRzIG9yIGZpbGVzKSBhcyBwYXJh
bWV0ZXJzIHNlZW1zIHRvIG1ha2UgYSBsb3QgbW9yZSBzZW5zZSB0byBtZSBzaW5jZSB5b3UgY2Fu
IHRoZW4gdHJlYXQgZXZlcnkgcGllY2Ugb2YgZGF0YSB0aGUgc2FtZSAoaW5zdGVhZCBvZiBoYXZp
bmcgdG8gaGFuZGxlIHBhcmFtZXRlcnMgYW5kIGZpbGVzIHNlcGVyYXRlbHkpLiAgSWYgdGhlIGlt
cGxlbWVudGF0aW9uIHdhcyBhIGxpdHRsZSBjbHVtc3kgSSBhcG9sb2dpemUsIGJ1dCB0aGUgY29u
Y2VwdCB3YXMgbm90IGEgd29ya2Fyb3VuZCBidXQgYSBnb2FsIHRvIGFsbG93IHRoZSB1c2VyIHRv
IGJlIGFibGUgdG8gdHJlYXQgYWxsIGRhdGEgaW4gdGhlIHNhbWUgbWFubmVyLg0KCSAgICAgICAN
CgkgICAgICAgIFRoZSBpc3N1ZSBvZiBmbGV4aWJpbGl0eSBpcyBkdWUgdG8gdGhlICJleHBsaWNp
dCBkZXRlY3Rpb24gdG8gU2VydmxldFJlcXVlc3REYXRhQmluZGVyIi4gIEluIHRoZSBwcmV2aW91
cyBpbXBsZW1lbnRhdGlvbiBhbmQgdGhlIGN1cnJlbnQgb25lLCBmaWxlcyB3ZXJlIGF1dG9tYXRp
Y2FsbHkgYm91bmQgdG8gYW4gb2JqZWN0IGJhc2VkIG9uIHRoZSB0YXJnZXQgcHJvcGVydGllcyB0
eXBlLiAgVGhlIGRpZmZlcmVuY2Ugd2FzIHRoYXQgeW91IGNvdWxkIG92ZXJyaWRlIGl0IHdpdGgg
YSBjdXN0b20gcHJvcGVydHkgZWRpdG9yIChpbiB0aGUgQmFzZUNvbW1hbmRDb250cm9sbGVyIGlu
aXRCaW5kZXIgbWV0aG9kLCBmb3IgZXhhbXBsZSkuICBVbmRlciB0aGUgY3VycmVudCBpbXBsZW1l
bnRhdGlvbiwgdGhlcmUgaXMgbm8gd2F5IHRvIG92ZXJyaWRlIGhvdyB0aGUgZmlsZSBpcyBhdHRh
Y2hlZCB0byB0aGUgYmVhbi4gIERvIHlvdSAob3IgYW55Ym9keSBlbHNlKSBoYXZlIGFueSBzdWdn
ZXN0aW9ucyBvbiBob3cgdG8gb3ZlcnJpZGUgdGhlIGRlZmF1bHQgU3ByaW5nIGhhbmRsaW5nIChj
dXJyZW50bHkgaGFyZC1jb2RlZCBpbiBTZXJ2bGV0UmVxdWVzdERhdGFCaW5kZXIpLCBvciBhbnkg
aWRlYXMgb2YgaG93IHRvIGNoYW5nZSB0aGUgaW1wbGVtZW50YXRpb24gdG8gYWxsb3cgdGhpcyBj
dXN0b20gaGFuZGxpbmc/DQoJICAgICAgIA0KCSAgICAgICAgVHJldm9yIEQuIENvb2sNCgkgICAg
ICAgDQoJICAgICAgIA0KCQ0KCU4YSFlYdRZ3GittPnhaGnpNeCcXensIHEIQNXrbrse+JylySOi2
n3EHet+617JKB2pnenjLpkfLsnEHeti2WMu6fnp3WM+Ky50Hamd6IA0KDQo=

[Springframework-developer] Springframework-developer -- confirmation of subscription -- request 959834

[Austin M. <aus...@ya...>]

Re: [Springframework-developer] Multipart File Handling

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

VHJldm9yLA0KIA0KU29ycnkgaWYgSSd2ZSBiZWVuIGEgYml0IGVhZ2VyIGluIHRlcm1zIG9mIGdl
dHRpbmcgcmlkIG9mIHRoZSBQcm9wZXJ0eUVkaXRvciBzdHVmZiBmb3IgbXVsdGlwYXJ0IGZpbGVz
LiBJIHN0cm9uZ2x5IGJlbGlldmUgdGhhdCB0aGUgSmF2YUJlYW5zIFByb3BlcnR5RWRpdG9yIGlz
IG5vdCBhcHByb3ByaWF0ZSBmb3IgbXVsdGlwYXJ0IGZpbGVzIHRob3VnaCwgYXMgaXQgaXMgYWJv
dXQgY29udmVydGluZyAqU3RyaW5nKiBwYXJhbWV0ZXJzIHRvIG90aGVyIHR5cGVzLiBUaGlzIGlz
IGZpbmUgZm9yIHN0YW5kYXJkIFNlcnZsZXRSZXF1ZXN0IHBhcmFtZXRlcnMgdGhhdCBjb21lIGlu
IGFzIFN0cmluZyB2YWx1ZXMgYW5kIG5lZWQgdG8gYmUgYm91bmQgdG8gYXJiaXRyYXJ5IHByb3Bl
cnRpZXMgb2YgY29tbWFuZCBvYmplY3RzLiBNdWx0aXBhcnQgZmlsZXMgb24gdGhlIG90aGVyIGhh
bmQgYXJlIGJ5IHRoZWlyIHZlcnkgbmF0dXJlIGNvbXBsZXggb2JqZWN0czsgdGhleSBkbyBub3Qg
aGF2ZSBhIG5hdHVyYWwgU3RyaW5nIHJlcHJlc2VudGF0aW9uLg0KIA0KVGhlIHByZXZpb3VzIG1l
Y2hhbmlzbSBvZiBiaW5kaW5nIG11bHRpcGFydCBmaWxlcyB2aWEgUHJvcGVydHlFZGl0b3IgcmVx
dWlyZWQgTXVsdGlwYXJ0SHR0cFNlcnZsZXRSZXF1ZXN0J3MgZ2V0UGFyYW1ldGVyIG1ldGhvZCB0
byByZXR1cm4gdGhlIGZpZWxkIG5hbWUgYXMgdmFsdWUgYSBsYSBnZXRQYXJhbWV0ZXIoIm15Zmll
bGQiKSAtPiAibXlmaWVsZCIsIHNvIHRoYXQgYSBQcm9wZXJ0eUVkaXRvciB0aGF0IGNhbiBqdXN0
IHNlZSB0aGUgdmFsdWUgd291bGQgYmUgYWJsZSB0byBpZGVudGlmeSB0aGUgZmllbGQgbmFtZSBh
bmQgaW52b2tlIE11bHRpcGFydEh0dHBTZXJ2bGV0UmVxdWVzdCdzIGdldEZpbGUoIm15ZmllbGQi
KSB0byByZXR1cm4gdGhlIE11bHRpcGFydEZpbGUgaW5zdGFuY2UuIFRoaXMgKmlzKiBhIHdvcmth
cm91bmQsIGFzIGl0IGlzIG5vdCBhdCBhbGwgbmF0dXJhbCB0byBoYXZlIGdldFBhcmFtZXRlciBy
ZXR1cm4gdGhlIGZpZWxkIG5hbWUgYXMgdmFsdWUgaW4gY2FzZSBvZiBhIG11bHRpcGFydCBmaWxl
Lg0KIA0KU2VydmxldFJlcXVlc3REYXRhQmluZGVyIGlzIG5vdCBhIGJhZCBwbGFjZSBmb3IgYmlu
ZGluZyBtdWx0aXBhcnQgZmlsZXMsIGdpdmVuIHRoYXQgb3VyIE11bHRpcGFydEh0dHBTZXJ2bGV0
UmVxdWVzdCBpcyBhIGdlbmVyaWMgaW50ZXJmYWNlIHRoYXQgcmVzaWRlcyBpbiB0aGUgbm9uLURp
c3BhdGNoZXJTZXJ2bGV0LXNwZWNpZmljIHdlYi5tdWx0aXBhcnQgcGFja2FnZSBub3cuIEkgYWdy
ZWUgdGhhdCBpdCBpc24ndCBnZW5lcmFsbHkgcHJlZmVyYWJsZSB0byBoYXJkY29kZSBiaW5kaW5n
IG9wdGlvbnMsIGJ1dCBJJ3ZlIGluaXRpYWxseSBmZWx0IHRoYXQgdGhlcmUgYXJlbid0IGFueSBv
dGhlciBtZWFuaW5nZnVsIGNvbnZlcnNpb25zIHRoYW4gYSBNdWx0aXBhcnRGaWxlIGl0c2VsZiBv
ciBhIGJ5dGVbXSBhcyB2YWx1ZSBvZiBhIGNvbW1hbmQgYmVhbiBwcm9wZXJ0eS4gTm90ZSB0aGF0
IHlvdSBjYW4gYWx3YXlzIG92ZXJyaWRlIEJhc2VDb21tYW5kQ29udHJvbGxlcidzIG9uQmluZEFu
ZFZhbGlkYXRlIHRvIHBlcmZvcm0gKmN1c3RvbSogYmluZGluZy4NCiANCi0tLS0tDQogDQpPbiBz
ZWNvbmQgdGhvdWdodCwgSSBhZ3JlZSB0aGF0IGEgcGx1Z2dhYmxlIGNvbnZlcnNpb24gbWVjaGFu
aXNtIGlzIHByZWZlcmFibGUuIEkndmUganVzdCByZXdvcmtlZCB0aGUgbXVsdGlwYXJ0IGJpbmRp
bmcgaW50byBhIFByb3BlcnR5RWRpdG9yIG1lY2hhbmlzbSBhZ2FpbiwgYnV0IHdpdGggYSBkaWZm
ZXJlbnQgaW1wbGVtZW50YXRpb24gcGF0dGVybjogU2VydmxldFJlcXVlc3REYXRhQmluZGVyIHNp
bXBseSBiaW5kcyB0aGUgZmlsZSBtYXAgcmV0dXJuZWQgYnkgTXVsdGlwYXJ0SHR0cFNlcnZsZXRS
ZXF1ZXN0LmdldEZpbGVNYXAgYXMgcHJvcGVydHkgdmFsdWVzLiBUaGlzIG1lYW5zIHRoYXQgYmVh
biBwcm9wZXJ0aWVzIG9mIHR5cGUgTXVsdGlwYXJ0RmlsZSBjYW4gYmUgcG9wdWxhdGVkIGRpcmVj
dGx5LCB3aXRob3V0IGNvbnZlcnNpb24uIE90aGVyIHR5cGVzIGdvIHRocm91Z2ggdGhlIFByb3Bl
cnR5RWRpdG9yIG1lY2hhbmlzbSwgYnV0IHZpYSBjYWxsaW5nIHNldFZhbHVlKE9iamVjdCkgaW5z
dGVhZCBvZiBzZXRBc1RleHQoU3RyaW5nKS4NCiANCkJ5dGVBcnJheU11bHRpcGFydEZpbGVFZGl0
b3IgYW5kIFN0cmluZ011bHRpcGFydEZpbGVFZGl0b3IgaW1wbGVtZW50IHNldFZhbHVlIHRvIHRy
YW5zZm9ybSB0aGUgZ2l2ZW4gTXVsdGlwYXJ0RmlsZSBpbnN0YW5jZSBpbnRvIGVpdGhlciBhIGJ5
dGUgYXJyYXkgb3IgYSBTdHJpbmcsIHRoZSBsYXR0ZXIgd2l0aCBjb25maWd1cmFibGUgY2hhcnNl
dC4gTm90ZSB0aGFuIG5vbmUgb2YgdGhlc2UgbmVlZHMgYSBNdWx0aXBhcnRIdHRwU2VydmxldFJl
cXVlc3Q6IFRoZXkgcmVjZWl2ZSB0aGUgTXVsdGlwYXJ0RmlsZSBpbnN0YW5jZXMgYm91bmQgYXMg
cHJvcGVydHkgdmFsdWVzIGJ5IFNlcnZsZXRSZXF1ZXN0RGF0YUJpbmRlci4gVGhvc2UgdHdvIGN1
c3RvbSBlZGl0b3JzIG5lZWQgdG8gYmUgcmVnaXN0ZXJlZCB3aXRoIFNlcnZsZXRSZXF1ZXN0RGF0
YUJpbmRlciB2aWEgcmVnaXN0ZXJDdXN0b21FZGl0b3IsIHByZWZlcmFibHkgZm9yIHNwZWNpZmlj
IGZpZWxkcyB0byBhdm9pZCBjb25mbGljdHMgd2l0aCBvdGhlciBmaWVsZHMgb2YgdGhlIHR5cGUg
Ynl0ZSBhcnJheSBvciBTdHJpbmcuDQogDQpJIGNvbnNpZGVyIHRoaXMgYSBnb29kIHNvbHV0aW9u
LCBtb3JlIGZsZXhpYmxlIHRoYW4gdGhlIGhhcmRjb2RlZCBiaW5kaW5nLCBidXQgYWxzbyBjbGVh
bmVyIHRoYW4gdGhlIFByb3BlcnR5RWRpdG9yIGluZGlyZWN0aW9uIHdpdGggU3RyaW5nIHBhcmFt
ZXRlcnMuIFRoYW5rcyBmb3IgcG9pbnRpbmcgYXQgdGhlIGlzc3VlIGFnYWluISBPdmVycmlkaW5n
IFByb3BlcnR5RWRpdG9yJ3Mgc2V0VmFsdWUgaXMgZ2VuZXJhbGx5IGEgbmljZSB3YXkgdG8gY29u
dmVydCBmcm9tIG5vbi1TdHJpbmcgdmFsdWVzIHRvIHRoZSByZXF1aXJlZCB0eXBlOyBJIGRpZG4n
dCB0aGluayBvZiBpdCBhdCBmaXJzdCwgYW5kIEkgaGFkIHRvIHR3ZWFrIEJlYW5XcmFwcGVySW1w
bCBhIGJpdCB0byBhbGxvdyBmb3IgaXQuIEkgaG9wZSB5b3UgbGlrZSB0aGUgY3VycmVudCBzb2x1
dGlvbiB0b287IGRvZXMgaXQgZnVsZmlsIHlvdXIgcmVxdWlyZW1lbnRzIG5vdz8NCiANCkp1ZXJn
ZW4NCiANCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBU
cmV2b3IgQ29vayBbbWFpbHRvOnByaXNlMDNAc2VudGV4Lm5ldF0gDQoJR2VzZW5kZXQ6IE1vIDEz
LjEwLjIwMDMgMjI6MjIgDQoJQW46IGrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF07IFNwcmluZyBE
ZXZlbG9wZXJzIA0KCUNjOiANCglCZXRyZWZmOiBSRTogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9w
ZXJdIE11bHRpcGFydCBGaWxlIEhhbmRsaW5nDQoJDQoJDQoNCgk8anVlcmdlbj4NCglGdXJ0aGVy
bW9yZSwgSSd2ZSBkcm9wcGVkIHRoZSBwcmV2aW91cyBQcm9wZXJ0eUVkaXRvcnMgc3VwcG9ydCwg
YW5kIHRoZSBhc3NvY2lhdGVkIHJlcXVpcmVtZW50IGZvciBmaWxlIHBhcmFtZXRlcnMgaGF2aW5n
IHRvIGJlIGF2YWlsYWJsZSBhcyBub3JtYWwgcGFyYW1ldGVycyB3aXRoIHRoZSBmaWVsZCBuYW1l
IGFzIHZhbHVlLiBUaGF0IHNlZW1lZCBsaWtlIGEgd29ya2Fyb3VuZDsgaW5zdGVhZCwgSSd2ZSBh
ZGRlZCBleHBsaWNpdCBkZXRlY3Rpb24gdG8gU2VydmxldFJlcXVlc3REYXRhQmluZGVyLCB3aGlj
aCBpcyBub3cgYWJsZSB0byBiaW5kIGZpbGUgcGFyYW1ldGVycyBhcyBNdWx0aXBhcnRGaWxlIG9y
IGJ5dGVbXSwgZGVwZW5kaW5nIG9uIHRoZSB0eXBlIG9mIHRoZSB0YXJnZXQgYmVhbiBwcm9wZXJ0
eS4gSSd2ZSBub3QgcmVpbnRyb2R1Y2VkIGJpbmRpbmcgdGhlIG9yaWdpbmFsIGZpbGUgbmFtZSB0
byBhIFN0cmluZyBwcm9wZXJ0eSwgYXMgSSBjYW4ndCBzZWUgdGhlIHZhbHVlIG9mIHRoYXQgZmVh
dHVyZS4NCgk8L2p1ZXJnZW4+DQoJDQoJTm8gcHJvYmxlbSBkcm9wcGluZyB0aGUgU3RyaW5nIDw+
IGZpbGVuYW1lLCBJIHdhc24ndCBzdXJlIGlmIHRoYXQgd291bGQgYmUgdXNlZnVsIG9yIG5vdC4N
CgkNCglJIGRvIGhhdmUgYSBwcm9ibGVtIHdpdGggZHJvcHBpbmcgdGhlIFByb3BlcnR5RWRpdG9y
cyBzdXBwb3J0LCBzaW5jZSBpbiBteSBtaW5kIGl0IHJlbW92ZXMgZmxleGliaWxpdHkgYW5kIGNv
bnNpc3RlbmN5LiANCgkNCglUcmVhdGluZyBhbGwgdGhlIGRhdGEgKHNpbXBsZSB0ZXh0IGZpZWxk
cyBvciBmaWxlcykgYXMgcGFyYW1ldGVycyBzZWVtcyB0byBtYWtlIGEgbG90IG1vcmUgc2Vuc2Ug
dG8gbWUgc2luY2UgeW91IGNhbiB0aGVuIHRyZWF0IGV2ZXJ5IHBpZWNlIG9mIGRhdGEgdGhlIHNh
bWUgKGluc3RlYWQgb2YgaGF2aW5nIHRvIGhhbmRsZSBwYXJhbWV0ZXJzIGFuZCBmaWxlcyBzZXBl
cmF0ZWx5KS4gIElmIHRoZSBpbXBsZW1lbnRhdGlvbiB3YXMgYSBsaXR0bGUgY2x1bXN5IEkgYXBv
bG9naXplLCBidXQgdGhlIGNvbmNlcHQgd2FzIG5vdCBhIHdvcmthcm91bmQgYnV0IGEgZ29hbCB0
byBhbGxvdyB0aGUgdXNlciB0byBiZSBhYmxlIHRvIHRyZWF0IGFsbCBkYXRhIGluIHRoZSBzYW1l
IG1hbm5lci4NCgkNCglUaGUgaXNzdWUgb2YgZmxleGliaWxpdHkgaXMgZHVlIHRvIHRoZSAiZXhw
bGljaXQgZGV0ZWN0aW9uIHRvIFNlcnZsZXRSZXF1ZXN0RGF0YUJpbmRlciIuICBJbiB0aGUgcHJl
dmlvdXMgaW1wbGVtZW50YXRpb24gYW5kIHRoZSBjdXJyZW50IG9uZSwgZmlsZXMgd2VyZSBhdXRv
bWF0aWNhbGx5IGJvdW5kIHRvIGFuIG9iamVjdCBiYXNlZCBvbiB0aGUgdGFyZ2V0IHByb3BlcnRp
ZXMgdHlwZS4gIFRoZSBkaWZmZXJlbmNlIHdhcyB0aGF0IHlvdSBjb3VsZCBvdmVycmlkZSBpdCB3
aXRoIGEgY3VzdG9tIHByb3BlcnR5IGVkaXRvciAoaW4gdGhlIEJhc2VDb21tYW5kQ29udHJvbGxl
ciBpbml0QmluZGVyIG1ldGhvZCwgZm9yIGV4YW1wbGUpLiAgVW5kZXIgdGhlIGN1cnJlbnQgaW1w
bGVtZW50YXRpb24sIHRoZXJlIGlzIG5vIHdheSB0byBvdmVycmlkZSBob3cgdGhlIGZpbGUgaXMg
YXR0YWNoZWQgdG8gdGhlIGJlYW4uICBEbyB5b3UgKG9yIGFueWJvZHkgZWxzZSkgaGF2ZSBhbnkg
c3VnZ2VzdGlvbnMgb24gaG93IHRvIG92ZXJyaWRlIHRoZSBkZWZhdWx0IFNwcmluZyBoYW5kbGlu
ZyAoY3VycmVudGx5IGhhcmQtY29kZWQgaW4gU2VydmxldFJlcXVlc3REYXRhQmluZGVyKSwgb3Ig
YW55IGlkZWFzIG9mIGhvdyB0byBjaGFuZ2UgdGhlIGltcGxlbWVudGF0aW9uIHRvIGFsbG93IHRo
aXMgY3VzdG9tIGhhbmRsaW5nPyANCgkNCglUcmV2b3IgRC4gQ29vaw0KCQ0KCQ0KDQo=

RE: [Springframework-developer] Multipart File Handling

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

<juergen>
Furthermore, I've dropped the previous PropertyEditors support, and the =
associated requirement for file parameters having to be available as =
normal parameters with the field name as value. That seemed like a =
workaround; instead, I've added explicit detection to =
ServletRequestDataBinder, which is now able to bind file parameters as =
MultipartFile or byte[], depending on the type of the target bean =
property. I've not reintroduced binding the original file name to a =
String property, as I can't see the value of that feature.
</juergen>

No problem dropping the String <> filename, I wasn't sure if that would =
be useful or not.

I do have a problem with dropping the PropertyEditors support, since in =
my mind it removes flexibility and consistency. =20

Treating all the data (simple text fields or files) as parameters seems =
to make a lot more sense to me since you can then treat every piece of =
data the same (instead of having to handle parameters and files =
seperately).  If the implementation was a little clumsy I apologize, but =
the concept was not a workaround but a goal to allow the user to be able =
to treat all data in the same manner.

The issue of flexibility is due to the "explicit detection to =
ServletRequestDataBinder".  In the previous implementation and the =
current one, files were automatically bound to an object based on the =
target properties type.  The difference was that you could override it =
with a custom property editor (in the BaseCommandController initBinder =
method, for example).  Under the current implementation, there is no way =
to override how the file is attached to the bean.  Do you (or anybody =
else) have any suggestions on how to override the default Spring =
handling (currently hard-coded in ServletRequestDataBinder), or any =
ideas of how to change the implementation to allow this custom handling? =
=20

Trevor D. Cook

Re: [Springframework-developer] Testing

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

On Monday 13 October 2003 09:49, Rod Johnson wrote:

> Yes, I think we would need one or more volunteers to run the tests on their
> hardware. This also means we need to decide when to kick it off and how to
> report results (emails to all Spring developers, rather than the list?)

I'd be happy to run the tests on WebSphere 4.x and 5.x servers for you.  Can't 
help with Oracle, but can certainly do MySQL and possibly Sybase if db access 
tests become important later on.



> > > Also, a volunteer to take ownersip would be great, assuming we agree
> > > it's a good idea! This might be a good opportunity for someone who
> > > doesn't presently have CVS access but wants to be a Spring developer,
> > > as it wouldn't involve changing existing code. (Not that I want to
> > > discourage any present
> > > developer.)

if someone better qualified doesn't put their hand up, I'd also be pleased to 
try to take this on too.

Regards,

-- 

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

RE: [Springframework-developer] RE: [Springframework-user] Releas e plan for 1.0 M2 and beyond

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

Also I think it would be useful to have a "TODO" list (somewhere on =
WIKI?)

Regards,
Dmitriy.

-----Original Message-----
From: Alef Arendsen (JTeam) [mailto:al...@jt...]=20
Sent: Monday, October 13, 2003 4:38 AM
To: 'j=C3=BCrgen h=C3=B6ller [werk3AT]';
spr...@li...
Cc: spr...@li...
Subject: [Springframework-developer] RE: [Springframework-user] Release =
plan
for 1.0 M2 and beyond


Juergen,

Schedule looks good to me. Especially the emphasis on documentation.

I haven't had much time lately, but I really like to get into this =
further.

IS there a prioritized list of documents/tutorials/faqs somewhere that =
needs
to be addressed? If not, I think this would be a good idea.

Alef


-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens =
j=C3=BCrgen
h=C3=B6ller [werk3AT]
Verzonden: Friday, October 10, 2003 7:57 PM
Aan: spr...@li...
CC: spr...@li...
Onderwerp: [Springframework-user] Release plan for 1.0 M2 and beyond


Dear Spring associates and followers,
=20
We're approaching our second 1.0 milestone release, scheduled for mid
October. I would like to release it next weekend, around Sunday the =
19th, if
there aren't any obstacles or objections.
=20
We've quite a lot of new functionality, for example:
=20
- multipart handling aka file upload support, both for =
DispatcherServlet and
general use, with Commons FileUpload and COS implementations;
=20
- a MailSender API, with an optional extended JavaMailSender interface, =
plus
JavaMail and COS implementations;
=20
- PropertyOverrideConfigurer and PropertyPlaceholderConfigurer, =
allowing for
push and pull style merging of properties files into bean property =
values of
an application context;
=20
- the BeanPostProcessor hook, and reworked bean factory/application =
context
integration;=20
=20
- PicoContainer style dependency checking and autowire options for the =
bean
factory;
=20
- returning result sets from a stored procedure;
=20
- reworked Last-Modified support, Velocity support, remoting proxies, =
etc.
=20
(Details can be found in the current changelog.txt in CVS, and in the
Javadocs.)
=20
I'd like to encourage everybody to give the new features a try via a =
CVS
snapshot. Early feedback will help us to release M2 as stable as =
possible.
=20
-----
=20
Looking beyond M2, we do not have many planned 1.0 features left -- and =
all
of them are already in the works:
=20
- source-level metadata, especially for transaction attributes;
=20
- Glue support, both accessing SOAP web services and exposing them =
(that's
actually an original 1.1 goal that might make it into 1.0; 1.1 will =
probably
see Axis support);
=20
- a Spring/Hibernate sample app (by myself);
=20
- docs, docs, docs!
=20
The last ones are probably the most important: I consider our Javadocs =
as
mostly exemplary, they document almost all the subtle features -- but =
we
still need more tutorials and feature guides. There's such a lot of =
useful
stuff that's hard to find currently...
=20
If I have forgotten about one of our 1.0 goals, feel free to correct =
me. All
of the above should be ready for 1.0 M3 in early to mid November -- at =
least
in their first incarnation.
=20
The final way towards 1.0 should be about fine-tuning and proper
documentation. I'm not aware of any more planned features beyond the M3
ones; so we should not need another milestone but be ready to schedule =
1.0
final for early December.
=20
Feedback of any kind is very welcome!
=20
Regards,
Juergen
N=18HY=DE=B5=E9=9A=8AX'u=DE=BC=16w=1A+m=DE=A7$>  xZ+ =1A,/z=CA=BE M=0E  =
x -'=ED=9F=93=ED=B1=9E=17ze{=08h=1CB =
=105=12/=D7=9Bz^=DB=AE=C7=AB'=1E)brH^m=E8=B6=9Fq  =E8=AE=A7z
h=D7=ABiJ  jg. j)b	b=D4=A9)~=E0=B6=A6{
+=1EX=EB=AE=AC(=CB=BA=1E~zw=E0=AD=86i=DB=B3 l=CB=B2q  z l X)=DF=A3)) ~{
+=1E



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. =
SourceForge.net
hosts over 70,000 Open Source Projects. See the people who have HELPED =
US
provide better services: Click here: =
http://sourceforge.net/supporters.php
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Testing

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

> We have a mechanism like this in place here (for our automated build
> server) and it works perfectly. Currently we're running one project
> against a Jboss322RC4/MySQL combo and one against a Jboss/Oracle combo,
> both having automated install of the Jboss configuration (the
> [jboss]/server/[config]-dir which resides in the CVS).
>
> How do we plan on doing this? Of course a Jboss/HSQL combo is not that
> difficult, but if we also want to do WebLogic Oracle, automated installs
> and stuff won't be that easy I think. Do we let it run at one of our
> places or something?

I don't think that the database is that crucial as a variable. At least in
the first instance I would be more concerned about whether changes broke
usage of the MVC framework, AOP, tx management etc, rather than JDBC.

One issue with multiple app servers is that there need to be some
workarounds for individual products. E.g. servlet listeners work fine to
initialize the web application context in Tomcat et al, but don't work in
WebLogic, which runs load on startup servlets such as dispatchers before
listeners. Would we have customization for each server, or test the portable
way?

Yes, I think we would need one or more volunteers to run the tests on their
hardware. This also means we need to decide when to kick it off and how to
report results (emails to all Spring developers, rather than the list?)

Regards,
Rod


> Rod & All,
>
> I think automated integration testing is a great idea.  I would suggest
> that we start with a JBoss/HSQL combo - easy install and the db is
> integrated in the app server.  Later on we could add a WebLogic/Oracle
> combo.  Here we might not want to install the server software for each
> test, but we could create a WebLogic domain and an Oracle
> instance/database using scripts for each test.
>
> Speaking of tests - I have not been able to run the entire test suite
> lately.
> It keeps failing on the
> org.springframework.metadata.bcel.AttributeWriterTests.
>  I can run this test by itself OK under Eclipse, but not using the
> 'tests' target in the build script.  Has anybody else seen this?  Here
> is the error:
> Testsuite: org.springframework.metadata.bcel.AttributeWriterTests
> Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.771 sec
>
> Testcase: testAttributes took 0.771 sec
> FAILED
> Expected one custom class attribute expected:<1> but was:<0>
> junit.framework.AssertionFailedError: Expected one custom class
> attribute expected:<1> but was:<0>
> at
> org.springframework.metadata.bcel.AttributeWriterTests.testAttributes(At
> tributeWriterTests.java:74)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
> a:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> Impl.java:25)
>
> Testcase: testAttributes
>
> Not sure what is going on here.
>
> Thomas
>
> > Hi Guys,
> >
> > I've been thinking about how to improve our testing strategy further.
> >
> > Currently we have excellent--and continually improving--unit test
> > coverage. This is essential and, I believe, the most important form of
>
> > testing for a framework such as Spring.
> >
> > However it would also be good to have automated integration tests that
>
> > help to verify that code changes won't break user applications. This
> > is especially important before releases, but would be really useful
> > possibly as part of a nightly build process. (I don't see any point
> > running unit tests in a nightly build: developers shouldn't commit
> > without doing that.) I think it's important to move beyond ad hoc
> > testing, not just for unit testing.
> >
> > I recently had lunch with Patrick Linskey of SolarMetric (Kodo JDO).
> > He was telling me about their testing, which is impressive. They have
> > multiple machines devoted to continually testing Kodo on different
> > application servers and against different databases. They start from a
>
> > clean install of the app server, then install Kodo and their test
> > applications.
> >
> > Perhaps we could apply a similar approach as we move towards 1.0
> > final.
> >
> > The basic process would probably involve an additional Ant script, and
>
> > look something like this:
> >
> > - be able to do a checkout from a tag or the head
> > - compile and build deployment units
> > - take a clean application server (perhaps tarred) and deploy the
> > spring Jars (and dependencies) from CVS along with the target
> > application from CVS (one of our samples, at least to start with).
> > We'd also need a database set up similarly--probably HSQL or such an
> > embedded database, including create
> > - wait until deployment is complete, unless the target app server can
> tell
> > us
> > - run tests against the app. This might involve HTTP requests with
> something
> > like HTTPUnit. Or maybe there are better tools. If there are any EJB
> > endpoints in any app we could do RMI against them.
> > - clean up so that no temporary files would break the next run
> >
> > There are a number of challenges and a lot of work to get to this
> > point, but I think it would be worth it. I would love to get Spring a
> > reputation for stability and lack of bugs. Tasks would include:
> >
> > - Writing build script
> > - Deciding which app servers to target? I'd suggest Tomcat and JBoss
> > or WebLogic to start off with. Also, where do we keep the app server
> > tarballs? We can't check JBoss or WebLogic into CVS.
> > - Deciding where do these tests run? How often do they run? Who looks
> > at the results? Maybe email would be the best way to go.
> > - Writing test scripts for deployed apps, and deciding on the best
> > tool.
> >
> > Ideally the scripts would allow adding new app servers or sample
> > applications + test scripts, within a consistent framework.
> >
> > I'd like some views on this. Does anyone have experience of doing
> > something similar?
> >
> > Also, a volunteer to take ownersip would be great, assuming we agree
> > it's a good idea! This might be a good opportunity for someone who
> > doesn't presently have CVS access but wants to be a Spring developer,
> > as it wouldn't involve changing existing code. (Not that I want to
> > discourage any present
> > developer.)
> >
> > Regards,
> > Rod
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program.
> > SourceForge.net hosts over 70,000 Open Source Projects. See the people
>
> > who have HELPED US provide better services: Click here:
> > http://sourceforge.net/supporters.php
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects. See the people
> who have HELPED US provide better services: Click here:
> http://sourceforge.net/supporters.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

[Springframework-developer] RE: [Springframework-user] Release plan for 1.0 M2 and beyond

[Alef A. \(JTeam\) <al...@jt...>]

Juergen,

Schedule looks good to me. Especially the emphasis on documentation.

I haven't had much time lately, but I really like to get into this =
further.

IS there a prioritized list of documents/tutorials/faqs somewhere that =
needs to be addressed? If not, I think this would be a good idea.

Alef


-----Oorspronkelijk bericht-----
Van: spr...@li... =
[mailto:spr...@li...] Namens =
j=C3=BCrgen h=C3=B6ller [werk3AT]
Verzonden: Friday, October 10, 2003 7:57 PM
Aan: spr...@li...
CC: spr...@li...
Onderwerp: [Springframework-user] Release plan for 1.0 M2 and beyond


Dear Spring associates and followers,
=20
We're approaching our second 1.0 milestone release, scheduled for mid =
October. I would like to release it next weekend, around Sunday the =
19th, if there aren't any obstacles or objections.
=20
We've quite a lot of new functionality, for example:
=20
- multipart handling aka file upload support, both for DispatcherServlet =
and general use, with Commons FileUpload and COS implementations;
=20
- a MailSender API, with an optional extended JavaMailSender interface, =
plus JavaMail and COS implementations;
=20
- PropertyOverrideConfigurer and PropertyPlaceholderConfigurer, allowing =
for push and pull style merging of properties files into bean property =
values of an application context;
=20
- the BeanPostProcessor hook, and reworked bean factory/application =
context integration;=20
=20
- PicoContainer style dependency checking and autowire options for the =
bean factory;
=20
- returning result sets from a stored procedure;
=20
- reworked Last-Modified support, Velocity support, remoting proxies, =
etc.
=20
(Details can be found in the current changelog.txt in CVS, and in the =
Javadocs.)
=20
I'd like to encourage everybody to give the new features a try via a CVS =
snapshot. Early feedback will help us to release M2 as stable as =
possible.
=20
-----
=20
Looking beyond M2, we do not have many planned 1.0 features left -- and =
all of them are already in the works:
=20
- source-level metadata, especially for transaction attributes;
=20
- Glue support, both accessing SOAP web services and exposing them =
(that's actually an original 1.1 goal that might make it into 1.0; 1.1 =
will probably see Axis support);
=20
- a Spring/Hibernate sample app (by myself);
=20
- docs, docs, docs!
=20
The last ones are probably the most important: I consider our Javadocs =
as mostly exemplary, they document almost all the subtle features -- but =
we still need more tutorials and feature guides. There's such a lot of =
useful stuff that's hard to find currently...
=20
If I have forgotten about one of our 1.0 goals, feel free to correct me. =
All of the above should be ready for 1.0 M3 in early to mid November -- =
at least in their first incarnation.
=20
The final way towards 1.0 should be about fine-tuning and proper =
documentation. I'm not aware of any more planned features beyond the M3 =
ones; so we should not need another milestone but be ready to schedule =
1.0 final for early December.
=20
Feedback of any kind is very welcome!
=20
Regards,
Juergen
N=18HY=DE=B5=E9=9A=8AX'u=DE=BC=16w=1A+m=DE=A7$>  xZ+ =1A,/z=CA=BE M=0E  =
x -'=ED=9F=93=ED=B1=9E=17ze{=08h=1CB =
=105=12/=D7=9Bz^=DB=AE=C7=AB'=1E)brH^m=E8=B6=9Fq  =E8=AE=A7z h=D7=ABiJ  =
jg. j)b	b=D4=A9)~=E0=B6=A6{
+=1EX=EB=AE=AC(=CB=BA=1E~zw=E0=AD=86i=DB=B3 l=CB=B2q  z l X)=DF=A3)) ~{
+=1E

RE: [Springframework-developer] Testing

[Alef A. \(JTeam\) <al...@jt...>]

About the server install, if you're starting with Jboss, the only thing
you need basically is the server configuration (of course besides the
normal binaries).

We have a mechanism like this in place here (for our automated build
server) and it works perfectly. Currently we're running one project
against a Jboss322RC4/MySQL combo and one against a Jboss/Oracle combo,
both having automated install of the Jboss configuration (the
[jboss]/server/[config]-dir which resides in the CVS).

How do we plan on doing this? Of course a Jboss/HSQL combo is not that
difficult, but if we also want to do WebLogic Oracle, automated installs
and stuff won't be that easy I think. Do we let it run at one of our
places or something?

Alef

-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens
tri...@tr...
Verzonden: Saturday, October 11, 2003 11:21 PM
Aan: Rod Johnson
CC: spr...@li...
Onderwerp: Re: [Springframework-developer] Testing


Rod & All,

I think automated integration testing is a great idea.  I would suggest
that we start with a JBoss/HSQL combo - easy install and the db is
integrated in the app server.  Later on we could add a WebLogic/Oracle
combo.  Here we might not want to install the server software for each
test, but we could create a WebLogic domain and an Oracle
instance/database using scripts for each test.

Speaking of tests - I have not been able to run the entire test suite
lately. 
It keeps failing on the
org.springframework.metadata.bcel.AttributeWriterTests.
 I can run this test by itself OK under Eclipse, but not using the
'tests' target in the build script.  Has anybody else seen this?  Here
is the error:
Testsuite: org.springframework.metadata.bcel.AttributeWriterTests
Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.771 sec

Testcase: testAttributes took 0.771 sec
	FAILED
Expected one custom class attribute expected:<1> but was:<0>
junit.framework.AssertionFailedError: Expected one custom class
attribute expected:<1> but was:<0>
	at
org.springframework.metadata.bcel.AttributeWriterTests.testAttributes(At
tributeWriterTests.java:74)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)

Testcase: testAttributes

Not sure what is going on here.

Thomas

> Hi Guys,
> 
> I've been thinking about how to improve our testing strategy further.
> 
> Currently we have excellent--and continually improving--unit test 
> coverage. This is essential and, I believe, the most important form of

> testing for a framework such as Spring.
> 
> However it would also be good to have automated integration tests that

> help to verify that code changes won't break user applications. This 
> is especially important before releases, but would be really useful 
> possibly as part of a nightly build process. (I don't see any point 
> running unit tests in a nightly build: developers shouldn't commit 
> without doing that.) I think it's important to move beyond ad hoc 
> testing, not just for unit testing.
> 
> I recently had lunch with Patrick Linskey of SolarMetric (Kodo JDO). 
> He was telling me about their testing, which is impressive. They have 
> multiple machines devoted to continually testing Kodo on different 
> application servers and against different databases. They start from a

> clean install of the app server, then install Kodo and their test 
> applications.
> 
> Perhaps we could apply a similar approach as we move towards 1.0 
> final.
> 
> The basic process would probably involve an additional Ant script, and

> look something like this:
> 
> - be able to do a checkout from a tag or the head
> - compile and build deployment units
> - take a clean application server (perhaps tarred) and deploy the 
> spring Jars (and dependencies) from CVS along with the target 
> application from CVS (one of our samples, at least to start with). 
> We'd also need a database set up similarly--probably HSQL or such an 
> embedded database, including create
> - wait until deployment is complete, unless the target app server can
tell
> us
> - run tests against the app. This might involve HTTP requests with
something
> like HTTPUnit. Or maybe there are better tools. If there are any EJB
> endpoints in any app we could do RMI against them.
> - clean up so that no temporary files would break the next run
> 
> There are a number of challenges and a lot of work to get to this 
> point, but I think it would be worth it. I would love to get Spring a 
> reputation for stability and lack of bugs. Tasks would include:
> 
> - Writing build script
> - Deciding which app servers to target? I'd suggest Tomcat and JBoss 
> or WebLogic to start off with. Also, where do we keep the app server 
> tarballs? We can't check JBoss or WebLogic into CVS.
> - Deciding where do these tests run? How often do they run? Who looks 
> at the results? Maybe email would be the best way to go.
> - Writing test scripts for deployed apps, and deciding on the best 
> tool.
> 
> Ideally the scripts would allow adding new app servers or sample 
> applications + test scripts, within a consistent framework.
> 
> I'd like some views on this. Does anyone have experience of doing 
> something similar?
> 
> Also, a volunteer to take ownersip would be great, assuming we agree 
> it's a good idea! This might be a good opportunity for someone who 
> doesn't presently have CVS access but wants to be a Spring developer, 
> as it wouldn't involve changing existing code. (Not that I want to 
> discourage any present
> developer.)
> 
> Regards,
> Rod
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program. 
> SourceForge.net hosts over 70,000 Open Source Projects. See the people

> who have HELPED US provide better services: Click here: 
> http://sourceforge.net/supporters.php
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects. See the people
who have HELPED US provide better services: Click here:
http://sourceforge.net/supporters.php
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Re: Docs

[Raymond L. <alp...@ya...>]

Hi,

I've read from the list regarding the need of docs. It
is a good idea to encourage people using Spring to
share their experiences on the wiki, just like the
Hibernate and OpenSymphony people do.

As a start I'm giving out some of my little
experiences, though a bit dumb, about using Webwork1
with Spring-managed JavaBeans, on the wiki. :)

But for other features, sorry I didn't use them, but
as said from above, people used the other features
available from Spring can share their experiences on
the wiki.

If allows, I would also like to write something about
configuring Hibernate's SessionFactory within Spring;
just some docs had been around on Spring's web and
Hibernate's wiki...

cheers,
Raymond

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Re: [Springframework-developer] BeanFactoryPostProcessor

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

+1
----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>
To: "jürgen höller [werk3AT]" <jue...@we...>; "Rod Johnson"
<rod...@in...>
Cc: <spr...@li...>
Sent: Sunday, October 12, 2003 12:36 PM
Subject: Re: [Springframework-developer] BeanFactoryPostProcessor


> On second thought, I'm actually for making the BeanFactoryPostPrcessor
interface non-ApplicationContextAware and moving it to the
beans.factory.support, even if doesn't have to be known by any BeanFactory
implementation.
>
> Applications might want to use it to implement post-processing code that
they manually invoke on a BeanFactory after programmatically loading it,
just like an ApplicationContext does internally.
>
> Furthermore, it just seems more consistent to have
BeanFactoryPostProcessor in the same package as BeanPostProcessor, even if
there are conceptual differences between the two.
>
> I guess I'll apply that change promptly, tomorrow at the latest. Any
objections?
>
> Juergen
>
>
>
> -----Ursprüngliche Nachricht----- 
> Von: jürgen höller [werk3AT]
> Gesendet: Sa 11.10.2003 01:06
> An: Rod Johnson
> Cc: spr...@li...
> Betreff: [Springframework-developer] Re: BeanFactoryPostProcessor
>
>
>
> There isn't a strong reason for BeanFactoryPostProcessor being
ApplicationContextAware: It's just that almost all implementations will be,
as they need to load some resources that they take their additional
configuration like overridden property values from. Resource loading is a
major reason for an application context (ApplicationContext's
getResourceAsStream and getResourceBase methods), just like a message
source.
>
> The BeanFactoryPostProcessor interface could reside in the
beans.factory.support package, but IMO it conceptually belongs to the
context area. A bean factory itself does not know about being
post-processed: That's a concept added by an application context, applied to
its underlying bean factory. Bean factories can be programmatically
manipulated after loading their original definitions, but only application
contexts allow to do this via special beans that get auto-detected
(BeanFactoryPostProcessor in this case, but also BeanPostProcessor).
>
> As I've already mentioned in a previous mail, I've applied the principle
that bean factories should not need to detect special beans defined within
them that influence the factory behavior itself. Bean factories and their
behavior get configured programmatically; the FactoryBean interface is an
exception, as it's not really manipulating the factory implementation.
Application contexts on the other hand recognize numerous special beans:
MessageSource, ContextOptions, BeanFactoryPostProcessors,
BeanPostProcessors.
>
> Note that the bean factory implementation does have to know about
BeanPostProcessor in a programmatic fashion, as this influences its bean
creation behavior. It does not have to know about BeanFactoryPostProcessor
though: That can easily get managed from the outside, i.e. by an application
context for its underlying bean factory, as it's basically just about
various method calls to the bean factory instance after loading the original
bean definitions.
>
> Of course, we could still decide to make the BeanFactoryPostProcessor
interface non-ApplicationContextAware and move it to beans.factory.support:
It would just not get used by any bean factory implementation or helper
class, but rather only by application context implementations -- therefore
it doesn't *have* to reside in the beans package. As elaborated above,
BeanPostProcessor is significantly different in that respect.
>
> Juergen
>
>
>
>         -----Ursprüngliche Nachricht-----
>         Von: Rod Johnson [mailto:rod...@in...]
>         Gesendet: Fr 10.10.2003 22:21
>         An: jürgen höller [werk3AT]
>         Cc: spr...@li...
>         Betreff: BeanFactoryPostProcessor
>
>
>
>         Juergen,
>
>         Why is this in the context package and why is it ContextAware?
Shouldn't it
>         deal only in Beanfactory concepts?
>
>         Forgive my ignorance if there's a good reason--this is based on a
>         superficial look at stuff coming in from CVS, rather than deep
thought.
>
>         Regards,
>         Rod
>
>
>
>
> NHY޵隊X'uw+m$>
xZ+޶,/zMҢx-'ze{hB5/כz^ǫ')brH^mqz캚h׫iJjgzx%Rڙ(G^hlqzm?X(~zwXb?j
gz
>
>

Re: [Springframework-developer] BeanFactoryPostProcessor

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

T24gc2Vjb25kIHRob3VnaHQsIEknbSBhY3R1YWxseSBmb3IgbWFraW5nIHRoZSBCZWFuRmFjdG9y
eVBvc3RQcmNlc3NvciBpbnRlcmZhY2Ugbm9uLUFwcGxpY2F0aW9uQ29udGV4dEF3YXJlIGFuZCBt
b3ZpbmcgaXQgdG8gdGhlIGJlYW5zLmZhY3Rvcnkuc3VwcG9ydCwgZXZlbiBpZiBkb2Vzbid0IGhh
dmUgdG8gYmUga25vd24gYnkgYW55IEJlYW5GYWN0b3J5IGltcGxlbWVudGF0aW9uLg0KIA0KQXBw
bGljYXRpb25zIG1pZ2h0IHdhbnQgdG8gdXNlIGl0IHRvIGltcGxlbWVudCBwb3N0LXByb2Nlc3Np
bmcgY29kZSB0aGF0IHRoZXkgbWFudWFsbHkgaW52b2tlIG9uIGEgQmVhbkZhY3RvcnkgYWZ0ZXIg
cHJvZ3JhbW1hdGljYWxseSBsb2FkaW5nIGl0LCBqdXN0IGxpa2UgYW4gQXBwbGljYXRpb25Db250
ZXh0IGRvZXMgaW50ZXJuYWxseS4NCiANCkZ1cnRoZXJtb3JlLCBpdCBqdXN0IHNlZW1zIG1vcmUg
Y29uc2lzdGVudCB0byBoYXZlIEJlYW5GYWN0b3J5UG9zdFByb2Nlc3NvciBpbiB0aGUgc2FtZSBw
YWNrYWdlIGFzIEJlYW5Qb3N0UHJvY2Vzc29yLCBldmVuIGlmIHRoZXJlIGFyZSBjb25jZXB0dWFs
IGRpZmZlcmVuY2VzIGJldHdlZW4gdGhlIHR3by4NCiANCkkgZ3Vlc3MgSSdsbCBhcHBseSB0aGF0
IGNoYW5nZSBwcm9tcHRseSwgdG9tb3Jyb3cgYXQgdGhlIGxhdGVzdC4gQW55IG9iamVjdGlvbnM/
DQogDQpKdWVyZ2VuDQogDQogDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0t
IA0KCVZvbjogasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXSANCglHZXNlbmRldDogU2EgMTEuMTAu
MjAwMyAwMTowNiANCglBbjogUm9kIEpvaG5zb24gDQoJQ2M6IHNwcmluZ2ZyYW1ld29yay1kZXZl
bG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KCUJldHJlZmY6IFtTcHJpbmdmcmFtZXdvcmst
ZGV2ZWxvcGVyXSBSZTogQmVhbkZhY3RvcnlQb3N0UHJvY2Vzc29yDQoJDQoJDQoNCglUaGVyZSBp
c24ndCBhIHN0cm9uZyByZWFzb24gZm9yIEJlYW5GYWN0b3J5UG9zdFByb2Nlc3NvciBiZWluZyBB
cHBsaWNhdGlvbkNvbnRleHRBd2FyZTogSXQncyBqdXN0IHRoYXQgYWxtb3N0IGFsbCBpbXBsZW1l
bnRhdGlvbnMgd2lsbCBiZSwgYXMgdGhleSBuZWVkIHRvIGxvYWQgc29tZSByZXNvdXJjZXMgdGhh
dCB0aGV5IHRha2UgdGhlaXIgYWRkaXRpb25hbCBjb25maWd1cmF0aW9uIGxpa2Ugb3ZlcnJpZGRl
biBwcm9wZXJ0eSB2YWx1ZXMgZnJvbS4gUmVzb3VyY2UgbG9hZGluZyBpcyBhIG1ham9yIHJlYXNv
biBmb3IgYW4gYXBwbGljYXRpb24gY29udGV4dCAoQXBwbGljYXRpb25Db250ZXh0J3MgZ2V0UmVz
b3VyY2VBc1N0cmVhbSBhbmQgZ2V0UmVzb3VyY2VCYXNlIG1ldGhvZHMpLCBqdXN0IGxpa2UgYSBt
ZXNzYWdlIHNvdXJjZS4NCgkNCglUaGUgQmVhbkZhY3RvcnlQb3N0UHJvY2Vzc29yIGludGVyZmFj
ZSBjb3VsZCByZXNpZGUgaW4gdGhlIGJlYW5zLmZhY3Rvcnkuc3VwcG9ydCBwYWNrYWdlLCBidXQg
SU1PIGl0IGNvbmNlcHR1YWxseSBiZWxvbmdzIHRvIHRoZSBjb250ZXh0IGFyZWEuIEEgYmVhbiBm
YWN0b3J5IGl0c2VsZiBkb2VzIG5vdCBrbm93IGFib3V0IGJlaW5nIHBvc3QtcHJvY2Vzc2VkOiBU
aGF0J3MgYSBjb25jZXB0IGFkZGVkIGJ5IGFuIGFwcGxpY2F0aW9uIGNvbnRleHQsIGFwcGxpZWQg
dG8gaXRzIHVuZGVybHlpbmcgYmVhbiBmYWN0b3J5LiBCZWFuIGZhY3RvcmllcyBjYW4gYmUgcHJv
Z3JhbW1hdGljYWxseSBtYW5pcHVsYXRlZCBhZnRlciBsb2FkaW5nIHRoZWlyIG9yaWdpbmFsIGRl
ZmluaXRpb25zLCBidXQgb25seSBhcHBsaWNhdGlvbiBjb250ZXh0cyBhbGxvdyB0byBkbyB0aGlz
IHZpYSBzcGVjaWFsIGJlYW5zIHRoYXQgZ2V0IGF1dG8tZGV0ZWN0ZWQgKEJlYW5GYWN0b3J5UG9z
dFByb2Nlc3NvciBpbiB0aGlzIGNhc2UsIGJ1dCBhbHNvIEJlYW5Qb3N0UHJvY2Vzc29yKS4NCgkN
CglBcyBJJ3ZlIGFscmVhZHkgbWVudGlvbmVkIGluIGEgcHJldmlvdXMgbWFpbCwgSSd2ZSBhcHBs
aWVkIHRoZSBwcmluY2lwbGUgdGhhdCBiZWFuIGZhY3RvcmllcyBzaG91bGQgbm90IG5lZWQgdG8g
ZGV0ZWN0IHNwZWNpYWwgYmVhbnMgZGVmaW5lZCB3aXRoaW4gdGhlbSB0aGF0IGluZmx1ZW5jZSB0
aGUgZmFjdG9yeSBiZWhhdmlvciBpdHNlbGYuIEJlYW4gZmFjdG9yaWVzIGFuZCB0aGVpciBiZWhh
dmlvciBnZXQgY29uZmlndXJlZCBwcm9ncmFtbWF0aWNhbGx5OyB0aGUgRmFjdG9yeUJlYW4gaW50
ZXJmYWNlIGlzIGFuIGV4Y2VwdGlvbiwgYXMgaXQncyBub3QgcmVhbGx5IG1hbmlwdWxhdGluZyB0
aGUgZmFjdG9yeSBpbXBsZW1lbnRhdGlvbi4gQXBwbGljYXRpb24gY29udGV4dHMgb24gdGhlIG90
aGVyIGhhbmQgcmVjb2duaXplIG51bWVyb3VzIHNwZWNpYWwgYmVhbnM6IE1lc3NhZ2VTb3VyY2Us
IENvbnRleHRPcHRpb25zLCBCZWFuRmFjdG9yeVBvc3RQcm9jZXNzb3JzLCBCZWFuUG9zdFByb2Nl
c3NvcnMuDQoJDQoJTm90ZSB0aGF0IHRoZSBiZWFuIGZhY3RvcnkgaW1wbGVtZW50YXRpb24gZG9l
cyBoYXZlIHRvIGtub3cgYWJvdXQgQmVhblBvc3RQcm9jZXNzb3IgaW4gYSBwcm9ncmFtbWF0aWMg
ZmFzaGlvbiwgYXMgdGhpcyBpbmZsdWVuY2VzIGl0cyBiZWFuIGNyZWF0aW9uIGJlaGF2aW9yLiBJ
dCBkb2VzIG5vdCBoYXZlIHRvIGtub3cgYWJvdXQgQmVhbkZhY3RvcnlQb3N0UHJvY2Vzc29yIHRo
b3VnaDogVGhhdCBjYW4gZWFzaWx5IGdldCBtYW5hZ2VkIGZyb20gdGhlIG91dHNpZGUsIGkuZS4g
YnkgYW4gYXBwbGljYXRpb24gY29udGV4dCBmb3IgaXRzIHVuZGVybHlpbmcgYmVhbiBmYWN0b3J5
LCBhcyBpdCdzIGJhc2ljYWxseSBqdXN0IGFib3V0IHZhcmlvdXMgbWV0aG9kIGNhbGxzIHRvIHRo
ZSBiZWFuIGZhY3RvcnkgaW5zdGFuY2UgYWZ0ZXIgbG9hZGluZyB0aGUgb3JpZ2luYWwgYmVhbiBk
ZWZpbml0aW9ucy4NCgkNCglPZiBjb3Vyc2UsIHdlIGNvdWxkIHN0aWxsIGRlY2lkZSB0byBtYWtl
IHRoZSBCZWFuRmFjdG9yeVBvc3RQcm9jZXNzb3IgaW50ZXJmYWNlIG5vbi1BcHBsaWNhdGlvbkNv
bnRleHRBd2FyZSBhbmQgbW92ZSBpdCB0byBiZWFucy5mYWN0b3J5LnN1cHBvcnQ6IEl0IHdvdWxk
IGp1c3Qgbm90IGdldCB1c2VkIGJ5IGFueSBiZWFuIGZhY3RvcnkgaW1wbGVtZW50YXRpb24gb3Ig
aGVscGVyIGNsYXNzLCBidXQgcmF0aGVyIG9ubHkgYnkgYXBwbGljYXRpb24gY29udGV4dCBpbXBs
ZW1lbnRhdGlvbnMgLS0gdGhlcmVmb3JlIGl0IGRvZXNuJ3QgKmhhdmUqIHRvIHJlc2lkZSBpbiB0
aGUgYmVhbnMgcGFja2FnZS4gQXMgZWxhYm9yYXRlZCBhYm92ZSwgQmVhblBvc3RQcm9jZXNzb3Ig
aXMgc2lnbmlmaWNhbnRseSBkaWZmZXJlbnQgaW4gdGhhdCByZXNwZWN0Lg0KCQ0KCUp1ZXJnZW4N
CgkNCgkNCgkNCgkgICAgICAgIC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCgkg
ICAgICAgIFZvbjogUm9kIEpvaG5zb24gW21haWx0bzpyb2Quam9obnNvbkBpbnRlcmZhY2UyMS5j
b21dDQoJICAgICAgICBHZXNlbmRldDogRnIgMTAuMTAuMjAwMyAyMjoyMQ0KCSAgICAgICAgQW46
IGrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF0NCgkgICAgICAgIENjOiBzcHJpbmdmcmFtZXdvcmst
ZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KCSAgICAgICAgQmV0cmVmZjogQmVhbkZh
Y3RvcnlQb3N0UHJvY2Vzc29yDQoJICAgICAgIA0KCSAgICAgICANCgkNCgkgICAgICAgIEp1ZXJn
ZW4sDQoJICAgICAgIA0KCSAgICAgICAgV2h5IGlzIHRoaXMgaW4gdGhlIGNvbnRleHQgcGFja2Fn
ZSBhbmQgd2h5IGlzIGl0IENvbnRleHRBd2FyZT8gU2hvdWxkbid0IGl0DQoJICAgICAgICBkZWFs
IG9ubHkgaW4gQmVhbmZhY3RvcnkgY29uY2VwdHM/DQoJICAgICAgIA0KCSAgICAgICAgRm9yZ2l2
ZSBteSBpZ25vcmFuY2UgaWYgdGhlcmUncyBhIGdvb2QgcmVhc29uLS10aGlzIGlzIGJhc2VkIG9u
IGENCgkgICAgICAgIHN1cGVyZmljaWFsIGxvb2sgYXQgc3R1ZmYgY29taW5nIGluIGZyb20gQ1ZT
LCByYXRoZXIgdGhhbiBkZWVwIHRob3VnaHQuDQoJICAgICAgIA0KCSAgICAgICAgUmVnYXJkcywN
CgkgICAgICAgIFJvZA0KCSAgICAgICANCgkgICAgICAgDQoJICAgICAgIA0KCQ0KCU4YSFnetema
ilgndRZ3GittJD4geFor3rYaLC96TQ7SongtJxd6ZXsIaBxCEDUSL9ebel7HqyceKWJySF5tcQd6
7LqaaNeraUoHamcdenglUtqZKEdeaGxxB3ptP1goHn56d1hiPwdqZx16IA0KDQo=

Re: [Springframework-developer] Testing

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

PiBTcGVha2luZyBvZiB0ZXN0cyAtIEkgaGF2ZSBub3QgYmVlbiBhYmxlIHRvIHJ1biB0aGUgZW50
aXJlIHRlc3Qgc3VpdGUgbGF0ZWx5Lg0KSXQga2VlcHMgZmFpbGluZyBvbiB0aGUgb3JnLnNwcmlu
Z2ZyYW1ld29yay5tZXRhZGF0YS5iY2VsLkF0dHJpYnV0ZVdyaXRlclRlc3RzLg0KIEkgY2FuIHJ1
biB0aGlzIHRlc3QgYnkgaXRzZWxmIE9LIHVuZGVyIEVjbGlwc2UsIGJ1dCBub3QgdXNpbmcgdGhl
ICd0ZXN0cycNCnRhcmdldCBpbiB0aGUgYnVpbGQgc2NyaXB0LiAgSGFzIGFueWJvZHkgZWxzZSBz
ZWVuIHRoaXM/ICBIZXJlIGlzIHRoZSBlcnJvcjoNClRlc3RzdWl0ZTogb3JnLnNwcmluZ2ZyYW1l
d29yay5tZXRhZGF0YS5iY2VsLkF0dHJpYnV0ZVdyaXRlclRlc3RzDQpUZXN0cyBydW46IDEsIEZh
aWx1cmVzOiAxLCBFcnJvcnM6IDAsIFRpbWUgZWxhcHNlZDogMC43NzEgc2VjDQoNClRlc3RjYXNl
OiB0ZXN0QXR0cmlidXRlcyB0b29rIDAuNzcxIHNlYw0KICAgICAgICBGQUlMRUQNCkV4cGVjdGVk
IG9uZSBjdXN0b20gY2xhc3MgYXR0cmlidXRlIGV4cGVjdGVkOjwxPiBidXQgd2FzOjwwPg0KanVu
aXQuZnJhbWV3b3JrLkFzc2VydGlvbkZhaWxlZEVycm9yOiBFeHBlY3RlZCBvbmUgY3VzdG9tIGNs
YXNzIGF0dHJpYnV0ZQ0KZXhwZWN0ZWQ6PDE+IGJ1dCB3YXM6PDA+DQogICAgICAgIGF0DQpvcmcu
c3ByaW5nZnJhbWV3b3JrLm1ldGFkYXRhLmJjZWwuQXR0cmlidXRlV3JpdGVyVGVzdHMudGVzdEF0
dHJpYnV0ZXMoQXR0cmlidXRlV3JpdGVyVGVzdHMuamF2YTo3NCkNCiAgICAgICAgYXQgc3VuLnJl
ZmxlY3QuTmF0aXZlTWV0aG9kQWNjZXNzb3JJbXBsLmludm9rZTAoTmF0aXZlIE1ldGhvZCkNCiAg
ICAgICAgYXQgc3VuLnJlZmxlY3QuTmF0aXZlTWV0aG9kQWNjZXNzb3JJbXBsLmludm9rZShOYXRp
dmVNZXRob2RBY2Nlc3NvckltcGwuamF2YTozOSkNCiAgICAgICAgYXQNCnN1bi5yZWZsZWN0LkRl
bGVnYXRpbmdNZXRob2RBY2Nlc3NvckltcGwuaW52b2tlKERlbGVnYXRpbmdNZXRob2RBY2Nlc3Nv
ckltcGwuamF2YToyNSkNCg0KVGVzdGNhc2U6IHRlc3RBdHRyaWJ1dGVzDQoNCg0KSSd2ZSBoYWQg
dGhhdCBmb3IgYWJvdXQgYSB3ZWVrIG5vdywgYW5kIHRlbXBvcmFyaWx5IGV4Y2x1ZGVkIG9yZy5z
cHJpbmdmcmFtZXdvcmsubWV0YWRhdGEgZnJvbSB0ZXN0aW5nIHZpYSBidWlsZC5wcm9wZXJ0aWVz
IHRvIGJlIGFibGUgdG8gcnVuIHRoZSB0ZXN0IHN1aXRlIHByb3Blcmx5LiBNYXJrLCBhcyB5b3Un
cmUgdGhlIG9uZSByZXNwb25zaWJsZSBmb3IgdGhhdCBwYWNrYWdlLCBjb3VsZCB5b3UgZ2l2ZSB1
cyBhbiB1cGRhdGUgb24gaXRzIHN0YXR1cyBpbiBnZW5lcmFsIGFuZCB0aGlzIGVycm9yIGluIHBh
cnRpY3VsYXI/DQoNCkp1ZXJnZW4NCg0KIA0KDQo=

Re: [Springframework-developer] Testing

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

Rod & All,

I think automated integration testing is a great idea.  I would suggest that we
start with a JBoss/HSQL combo - easy install and the db is integrated in the app
server.  Later on we could add a WebLogic/Oracle combo.  Here we might not want
to install the server software for each test, but we could create a WebLogic
domain and an Oracle instance/database using scripts for each test.

Speaking of tests - I have not been able to run the entire test suite lately. 
It keeps failing on the org.springframework.metadata.bcel.AttributeWriterTests.
 I can run this test by itself OK under Eclipse, but not using the 'tests'
target in the build script.  Has anybody else seen this?  Here is the error:
Testsuite: org.springframework.metadata.bcel.AttributeWriterTests
Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.771 sec

Testcase: testAttributes took 0.771 sec
	FAILED
Expected one custom class attribute expected:<1> but was:<0>
junit.framework.AssertionFailedError: Expected one custom class attribute
expected:<1> but was:<0>
	at
org.springframework.metadata.bcel.AttributeWriterTests.testAttributes(AttributeWriterTests.java:74)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

Testcase: testAttributes

Not sure what is going on here.

Thomas

> Hi Guys,
> 
> I've been thinking about how to improve our testing strategy further.
> 
> Currently we have excellent--and continually improving--unit test coverage.
> This is essential and, I believe, the most important form of testing for a
> framework such as Spring.
> 
> However it would also be good to have automated integration tests that help
> to verify that code changes won't break user applications. This is
> especially important before releases, but would be really useful possibly as
> part of a nightly build process. (I don't see any point running unit tests
> in a nightly build: developers shouldn't commit without doing that.) I think
> it's important to move beyond ad hoc testing, not just for unit testing.
> 
> I recently had lunch with Patrick Linskey of SolarMetric (Kodo JDO). He was
> telling me about their testing, which is impressive. They have multiple
> machines devoted to continually testing Kodo on different application
> servers and against different databases. They start from a clean install of
> the app server, then install Kodo and their test applications.
> 
> Perhaps we could apply a similar approach as we move towards 1.0 final.
> 
> The basic process would probably involve an additional Ant script, and look
> something like this:
> 
> - be able to do a checkout from a tag or the head
> - compile and build deployment units
> - take a clean application server (perhaps tarred) and deploy the spring
> Jars (and dependencies) from CVS along with the target application from CVS
> (one of our samples, at least to start with). We'd also need a database set
> up similarly--probably HSQL or such an embedded database, including create
> - wait until deployment is complete, unless the target app server can tell
> us
> - run tests against the app. This might involve HTTP requests with something
> like HTTPUnit. Or maybe there are better tools. If there are any EJB
> endpoints in any app we could do RMI against them.
> - clean up so that no temporary files would break the next run
> 
> There are a number of challenges and a lot of work to get to this point, but
> I think it would be worth it. I would love to get Spring a reputation for
> stability and lack of bugs. Tasks would include:
> 
> - Writing build script
> - Deciding which app servers to target? I'd suggest Tomcat and JBoss or
> WebLogic to start off with. Also, where do we keep the app server tarballs?
> We can't check JBoss or WebLogic into CVS.
> - Deciding where do these tests run? How often do they run? Who looks at the
> results? Maybe email would be the best way to go.
> - Writing test scripts for deployed apps, and deciding on the best tool.
> 
> Ideally the scripts would allow adding new app servers or sample
> applications + test scripts, within a consistent framework.
> 
> I'd like some views on this. Does anyone have experience of doing something
> similar?
> 
> Also, a volunteer to take ownersip would be great, assuming we agree it's a
> good idea! This might be a good opportunity for someone who doesn't
> presently have CVS access but wants to be a Spring developer, as it wouldn't
> involve changing existing code. (Not that I want to discourage any present
> developer.)
> 
> Regards,
> Rod
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

[Springframework-developer] Testing

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

Hi Guys,

I've been thinking about how to improve our testing strategy further.

Currently we have excellent--and continually improving--unit test coverage.
This is essential and, I believe, the most important form of testing for a
framework such as Spring.

However it would also be good to have automated integration tests that help
to verify that code changes won't break user applications. This is
especially important before releases, but would be really useful possibly as
part of a nightly build process. (I don't see any point running unit tests
in a nightly build: developers shouldn't commit without doing that.) I think
it's important to move beyond ad hoc testing, not just for unit testing.

I recently had lunch with Patrick Linskey of SolarMetric (Kodo JDO). He was
telling me about their testing, which is impressive. They have multiple
machines devoted to continually testing Kodo on different application
servers and against different databases. They start from a clean install of
the app server, then install Kodo and their test applications.

Perhaps we could apply a similar approach as we move towards 1.0 final.

The basic process would probably involve an additional Ant script, and look
something like this:

- be able to do a checkout from a tag or the head
- compile and build deployment units
- take a clean application server (perhaps tarred) and deploy the spring
Jars (and dependencies) from CVS along with the target application from CVS
(one of our samples, at least to start with). We'd also need a database set
up similarly--probably HSQL or such an embedded database, including create
- wait until deployment is complete, unless the target app server can tell
us
- run tests against the app. This might involve HTTP requests with something
like HTTPUnit. Or maybe there are better tools. If there are any EJB
endpoints in any app we could do RMI against them.
- clean up so that no temporary files would break the next run

There are a number of challenges and a lot of work to get to this point, but
I think it would be worth it. I would love to get Spring a reputation for
stability and lack of bugs. Tasks would include:

- Writing build script
- Deciding which app servers to target? I'd suggest Tomcat and JBoss or
WebLogic to start off with. Also, where do we keep the app server tarballs?
We can't check JBoss or WebLogic into CVS.
- Deciding where do these tests run? How often do they run? Who looks at the
results? Maybe email would be the best way to go.
- Writing test scripts for deployed apps, and deciding on the best tool.

Ideally the scripts would allow adding new app servers or sample
applications + test scripts, within a consistent framework.

I'd like some views on this. Does anyone have experience of doing something
similar?

Also, a volunteer to take ownersip would be great, assuming we agree it's a
good idea! This might be a good opportunity for someone who doesn't
presently have CVS access but wants to be a Spring developer, as it wouldn't
involve changing existing code. (Not that I want to discourage any present
developer.)

Regards,
Rod

[Springframework-developer] Re: BeanFactoryPostProcessor

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

VGhlcmUgaXNuJ3QgYSBzdHJvbmcgcmVhc29uIGZvciBCZWFuRmFjdG9yeVBvc3RQcm9jZXNzb3Ig
YmVpbmcgQXBwbGljYXRpb25Db250ZXh0QXdhcmU6IEl0J3MganVzdCB0aGF0IGFsbW9zdCBhbGwg
aW1wbGVtZW50YXRpb25zIHdpbGwgYmUsIGFzIHRoZXkgbmVlZCB0byBsb2FkIHNvbWUgcmVzb3Vy
Y2VzIHRoYXQgdGhleSB0YWtlIHRoZWlyIGFkZGl0aW9uYWwgY29uZmlndXJhdGlvbiBsaWtlIG92
ZXJyaWRkZW4gcHJvcGVydHkgdmFsdWVzIGZyb20uIFJlc291cmNlIGxvYWRpbmcgaXMgYSBtYWpv
ciByZWFzb24gZm9yIGFuIGFwcGxpY2F0aW9uIGNvbnRleHQgKEFwcGxpY2F0aW9uQ29udGV4dCdz
IGdldFJlc291cmNlQXNTdHJlYW0gYW5kIGdldFJlc291cmNlQmFzZSBtZXRob2RzKSwganVzdCBs
aWtlIGEgbWVzc2FnZSBzb3VyY2UuDQogDQpUaGUgQmVhbkZhY3RvcnlQb3N0UHJvY2Vzc29yIGlu
dGVyZmFjZSBjb3VsZCByZXNpZGUgaW4gdGhlIGJlYW5zLmZhY3Rvcnkuc3VwcG9ydCBwYWNrYWdl
LCBidXQgSU1PIGl0IGNvbmNlcHR1YWxseSBiZWxvbmdzIHRvIHRoZSBjb250ZXh0IGFyZWEuIEEg
YmVhbiBmYWN0b3J5IGl0c2VsZiBkb2VzIG5vdCBrbm93IGFib3V0IGJlaW5nIHBvc3QtcHJvY2Vz
c2VkOiBUaGF0J3MgYSBjb25jZXB0IGFkZGVkIGJ5IGFuIGFwcGxpY2F0aW9uIGNvbnRleHQsIGFw
cGxpZWQgdG8gaXRzIHVuZGVybHlpbmcgYmVhbiBmYWN0b3J5LiBCZWFuIGZhY3RvcmllcyBjYW4g
YmUgcHJvZ3JhbW1hdGljYWxseSBtYW5pcHVsYXRlZCBhZnRlciBsb2FkaW5nIHRoZWlyIG9yaWdp
bmFsIGRlZmluaXRpb25zLCBidXQgb25seSBhcHBsaWNhdGlvbiBjb250ZXh0cyBhbGxvdyB0byBk
byB0aGlzIHZpYSBzcGVjaWFsIGJlYW5zIHRoYXQgZ2V0IGF1dG8tZGV0ZWN0ZWQgKEJlYW5GYWN0
b3J5UG9zdFByb2Nlc3NvciBpbiB0aGlzIGNhc2UsIGJ1dCBhbHNvIEJlYW5Qb3N0UHJvY2Vzc29y
KS4NCiANCkFzIEkndmUgYWxyZWFkeSBtZW50aW9uZWQgaW4gYSBwcmV2aW91cyBtYWlsLCBJJ3Zl
IGFwcGxpZWQgdGhlIHByaW5jaXBsZSB0aGF0IGJlYW4gZmFjdG9yaWVzIHNob3VsZCBub3QgbmVl
ZCB0byBkZXRlY3Qgc3BlY2lhbCBiZWFucyBkZWZpbmVkIHdpdGhpbiB0aGVtIHRoYXQgaW5mbHVl
bmNlIHRoZSBmYWN0b3J5IGJlaGF2aW9yIGl0c2VsZi4gQmVhbiBmYWN0b3JpZXMgYW5kIHRoZWly
IGJlaGF2aW9yIGdldCBjb25maWd1cmVkIHByb2dyYW1tYXRpY2FsbHk7IHRoZSBGYWN0b3J5QmVh
biBpbnRlcmZhY2UgaXMgYW4gZXhjZXB0aW9uLCBhcyBpdCdzIG5vdCByZWFsbHkgbWFuaXB1bGF0
aW5nIHRoZSBmYWN0b3J5IGltcGxlbWVudGF0aW9uLiBBcHBsaWNhdGlvbiBjb250ZXh0cyBvbiB0
aGUgb3RoZXIgaGFuZCByZWNvZ25pemUgbnVtZXJvdXMgc3BlY2lhbCBiZWFuczogTWVzc2FnZVNv
dXJjZSwgQ29udGV4dE9wdGlvbnMsIEJlYW5GYWN0b3J5UG9zdFByb2Nlc3NvcnMsIEJlYW5Qb3N0
UHJvY2Vzc29ycy4NCiANCk5vdGUgdGhhdCB0aGUgYmVhbiBmYWN0b3J5IGltcGxlbWVudGF0aW9u
IGRvZXMgaGF2ZSB0byBrbm93IGFib3V0IEJlYW5Qb3N0UHJvY2Vzc29yIGluIGEgcHJvZ3JhbW1h
dGljIGZhc2hpb24sIGFzIHRoaXMgaW5mbHVlbmNlcyBpdHMgYmVhbiBjcmVhdGlvbiBiZWhhdmlv
ci4gSXQgZG9lcyBub3QgaGF2ZSB0byBrbm93IGFib3V0IEJlYW5GYWN0b3J5UG9zdFByb2Nlc3Nv
ciB0aG91Z2g6IFRoYXQgY2FuIGVhc2lseSBnZXQgbWFuYWdlZCBmcm9tIHRoZSBvdXRzaWRlLCBp
LmUuIGJ5IGFuIGFwcGxpY2F0aW9uIGNvbnRleHQgZm9yIGl0cyB1bmRlcmx5aW5nIGJlYW4gZmFj
dG9yeSwgYXMgaXQncyBiYXNpY2FsbHkganVzdCBhYm91dCB2YXJpb3VzIG1ldGhvZCBjYWxscyB0
byB0aGUgYmVhbiBmYWN0b3J5IGluc3RhbmNlIGFmdGVyIGxvYWRpbmcgdGhlIG9yaWdpbmFsIGJl
YW4gZGVmaW5pdGlvbnMuDQogDQpPZiBjb3Vyc2UsIHdlIGNvdWxkIHN0aWxsIGRlY2lkZSB0byBt
YWtlIHRoZSBCZWFuRmFjdG9yeVBvc3RQcm9jZXNzb3IgaW50ZXJmYWNlIG5vbi1BcHBsaWNhdGlv
bkNvbnRleHRBd2FyZSBhbmQgbW92ZSBpdCB0byBiZWFucy5mYWN0b3J5LnN1cHBvcnQ6IEl0IHdv
dWxkIGp1c3Qgbm90IGdldCB1c2VkIGJ5IGFueSBiZWFuIGZhY3RvcnkgaW1wbGVtZW50YXRpb24g
b3IgaGVscGVyIGNsYXNzLCBidXQgcmF0aGVyIG9ubHkgYnkgYXBwbGljYXRpb24gY29udGV4dCBp
bXBsZW1lbnRhdGlvbnMgLS0gdGhlcmVmb3JlIGl0IGRvZXNuJ3QgKmhhdmUqIHRvIHJlc2lkZSBp
biB0aGUgYmVhbnMgcGFja2FnZS4gQXMgZWxhYm9yYXRlZCBhYm92ZSwgQmVhblBvc3RQcm9jZXNz
b3IgaXMgc2lnbmlmaWNhbnRseSBkaWZmZXJlbnQgaW4gdGhhdCByZXNwZWN0Lg0KIA0KSnVlcmdl
bg0KIA0KIA0KDQoJLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IFJv
ZCBKb2huc29uIFttYWlsdG86cm9kLmpvaG5zb25AaW50ZXJmYWNlMjEuY29tXSANCglHZXNlbmRl
dDogRnIgMTAuMTAuMjAwMyAyMjoyMSANCglBbjogasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXSAN
CglDYzogc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgDQoJ
QmV0cmVmZjogQmVhbkZhY3RvcnlQb3N0UHJvY2Vzc29yDQoJDQoJDQoNCglKdWVyZ2VuLA0KCQ0K
CVdoeSBpcyB0aGlzIGluIHRoZSBjb250ZXh0IHBhY2thZ2UgYW5kIHdoeSBpcyBpdCBDb250ZXh0
QXdhcmU/IFNob3VsZG4ndCBpdA0KCWRlYWwgb25seSBpbiBCZWFuZmFjdG9yeSBjb25jZXB0cz8N
CgkNCglGb3JnaXZlIG15IGlnbm9yYW5jZSBpZiB0aGVyZSdzIGEgZ29vZCByZWFzb24tLXRoaXMg
aXMgYmFzZWQgb24gYQ0KCXN1cGVyZmljaWFsIGxvb2sgYXQgc3R1ZmYgY29taW5nIGluIGZyb20g
Q1ZTLCByYXRoZXIgdGhhbiBkZWVwIHRob3VnaHQuDQoJDQoJUmVnYXJkcywNCglSb2QNCgkNCgkN
CgkNCg0K

Re: [Springframework-developer] Scheduler update

[Ivan R. <iv...@we...>]

> would it make sense to make SpringExecWrapper a bean, that is, expose its
> properties (i.e bean, event, methodName, args) so they could be configured
> through an application context and also make it implement
> ApplicationContextAware interface, so the ApplicationContext would be
> provided to it by the BeanFactory ?

I've made some changes, introducing the SpringBeanTask class for use
in the configuration file. Here is how you would use it:

-------------

<!-- the bean to be called at a schedule -->
<bean id="job1" class="SomeJob"/>
	
<!-- the scheduler instance -->
<bean id="scheduler" class="com.webkreator.chronos.CronScheduler"
       init-method="start" />

<!-- task #1, bean method call with arguments on the command line -->	
<bean id="job1task1" class="com.webkreator.chronos.SpringBeanTask">
     <property name="bean"><value>
         job1.test "testing 123"
     </value></property>

     <property name="schedule"><value>*/1</value></property>
     <property name="scheduler"><ref bean="scheduler"/></property>
</bean>		

<!-- task #2, method call with multiple arguments -->
<bean id="job1task2" class="com.webkreator.chronos.SpringBeanTask">
     <property name="bean"><value>job1.test</value></property>
     <property name="schedule"><value>*/1</value></property>
     <property name="scheduler"><ref bean="scheduler"/></property>
		
     <property name="arguments">
     <list>
         <value>arg1</value>
         <value>arg2</value>
     </list>
     </property>
</bean>	

-------------

I have also removed SpringExecWrapper since I haven't found it useful
at all (ExecWrapper works just as well) but left a part of its
functionality in the SpringEventWrapper (publishes events to
the application context at a given schedule).

The only thing that bothers me is the schedule resolution. Cron works
with minutes but that may be too long for some uses. Should seconds
and milliseconds be supported?

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [Springframework-developer] Release plan for 1.0 M2 and beyond

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

> I have an additional feature planned - maybe for M3.  It is a DataSource
wrapper
> with callbacks that would be called just before the getConnection()
returns the
> connection to the JDBCTemplate and before close() is called on the
connection.
> This would allow you to prepare and un-prepare the connection with custom
> database calls.  I would use this internally to pass in a web app login
user
> name and then have triggers use this name instead of the user name used
for the
> JDBC pool in audit logs and updated_by columns.

Yes, I've seen requirements for such functionality.

This could also be implemented via an AOP interceptor, and applied to any
DataSource defined as a bean. This would be slightly slower, but that
wouldn't matter with anything JDBC.

Regards,
Rod

[Springframework-developer] BeanFactoryPostProcessor

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

Juergen,

Why is this in the context package and why is it ContextAware? Shouldn't it
deal only in Beanfactory concepts?

Forgive my ignorance if there's a good reason--this is based on a
superficial look at stuff coming in from CVS, rather than deep thought.

Regards,
Rod

[Springframework-developer] Re: [Springframework-user] Release plan for 1.0 M2 and beyond

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

Juergen,

Release schedule looks good.

I have an additional feature planned - maybe for M3.  It is a DataSource wrapper
with callbacks that would be called just before the getConnection() returns the
connection to the JDBCTemplate and before close() is called on the connection. 
This would allow you to prepare and un-prepare the connection with custom
database calls.  I would use this internally to pass in a web app login user
name and then have triggers use this name instead of the user name used for the
JDBC pool in audit logs and updated_by columns.

>  
> - a Spring/Hibernate sample app (by myself);
>  

I'm looking forward to this - the Spring/Hibernate combo seems to generate a lot
of interest.

> - docs, docs, docs!
>  

Yes we need much more in this area.  I have started working on a basic Spring
JDBC tutorial.  Also thinking about creating a Spring/Hibernate extension to
the MVC Step-by-Step guide.

I think we minimally need tutorials in the following areas:
- Spring IoC - Beans, BeanFactories and ApplicationContexts
- Spring JDBC (I volunteer for this one)
- Spring AOP
- Spring MVC

Thomas

Re: [Springframework-developer] new bean factory and application context features

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

Kopylenko, Dmitry wrote:

>>AutoProxyCreator is not yet in CVS, but I can add it promptly. BTW, I'm
>>    
>>
>not really sure about the name -- do you have a better name for 
>  
>
>>such a bean that automatically wraps other beans with proxies?
>>    
>>
>
>Juergen,
>
>AutoProxyCreator is fine with me. What didn't you like about it? :-) Or how
>about AutoProxyManager then?
>
>  
>
The name sounds ok to me. It could also be AutoProxyCreatorBean I guess, 
although I prefer it without that ending since I don't see the need to 
advertise the fact that it's a bean. In fact, there are a few classes in 
Spring where I am not quite clear on why 'bEan' was tacked onto the 
name. Other cases are obvious, such as where the name exists with and 
without 'Bean', e.g. ProxyFactory and ProxyFactoryBean, HttpServlet and 
HttpServletBean, or 'Bean' was added to make it a noun...

Regards,
Colin

RE: [Springframework-developer] new bean factory and application context features

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

> AutoProxyCreator is not yet in CVS, but I can add it promptly. BTW, I'm
not really sure about the name -- do you have a better name for 
> such a bean that automatically wraps other beans with proxies?

Juergen,

AutoProxyCreator is fine with me. What didn't you like about it? :-) Or how
about AutoProxyManager then?

Regards,
Dmitriy.

Re: [Springframework-developer] new bean factory and application context features

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

Pj4gSXQncyBjdXJyZW50bHkgbm90IGF2YWlsYWJsZSBpbiBGaWxlU3lzdGVtWG1sQXBwbGljYXRp
b25Db250ZXh0IHRob3VnaCwgbWFpbmx5IHRvIG5vdCBwbGFjZSBhbnkgcmVzdHJpY3Rpb25zIG9u
IGZpbGUgbmFtZXMgaW4gdGVybXMgb2Ygc3BhY2VzIG9yIGNvbW1hcy4gRmlsZVN5c3RlbVhtbEFw
cGxpY2F0aW9uQ29udGV4dCBhbHJlYWR5IGhhcyBhIGNvbnN0cnVjdG9yIHdpdGggYSBTdHJpbmcg
YXJyYXksIGZvciBhdXRvbWF0aWNhbGx5IHNldHRpbmcgdXAgKm5lc3RlZCogY29udGV4dHMuIFdl
IGNvdWxkIHJlZGVmaW5lIHRoYXQgY29uc3RydWN0b3IgdG8gc3BlY2lmeSBtdWx0aXBsZSBmaWxl
cyB0aGF0IG1ha2UgdXAgYSAqc2luZ2xlKiBjb250ZXh0LCBhbmQgb2ZmZXIgYW4gb3ZlcmxvYWRl
ZCB2ZXJzaW9uIHRoYXQgdGFrZXMgYSBwYXJlbnQgQXBwbGljYXRpb25Db250ZXh0IHJlZmVyZW5j
ZS4gVGhhdCB3YXksIGJvdGggbXVsdGlwbGUgZmlsZXMgZm9yIGEgc2luZ2xlIGNvbnRleHQgYW5k
IG5lc3Rpbmcgd291bGQgYmUgcG9zc2libGUuDQo+DQo+IFRoYXQgc291bmRzIGdvb2QuIFRoZXJl
IGFyZSBjZXJ0YWluIGRlcGxveW1lbnQgc2NlbmFyaW9zIHdoZXJlIGNvbmZpZw0KZmlsZXMgcmVm
ZXJlbmNlcyB2aWEgZmlsZW5hbWVzIChhcyBvcHBvc2VkIHRvIGhhdmluZyB0byBiZSBvbiB0aGUN
CmNsYXNzcGF0aCkgYXJlIGEgbG90IG1vcmUgY29udmVuaWVudCwgYW5kIEkgdGhpbmsuIEkgYW0g
dHJ5aW5nIHRvIHRoaW5rDQppZiB0aGVyZSBhcmUgYW55IHVzZSBjYXNlcyB3aGVyZSBzb21lYm9k
eSB3b3VsZCBiZSBmZWVkaW5nIGluIGEgbGlzdCBvZg0KY29udGV4dHMgaW4gdGhlIGV4aXN0aW5n
IGltcGxlbWVudGF0aW9uLCBhbmQgd291bGQgYmUgd29yc3Qgb2ZmIGlmIHRoZXkNCndlcmUgbmVz
dGVkIGFzIG9wcG9zZWQgdG8gZmxhdHRlbmVkIGludG8gb25lIGFzIHlvdSBwcm9wb3NlLiBJIGNh
bid0DQpyZWFsbHkgdGhpbmsgb2YgYW55LiBJIHRoaW5rIHRoZSBuZXN0aW5nIGRvZXMgbWFrZSBh
IGxvdCBvZiBzZW5zZSB3aGVuDQp5b3UgYXJlIGFzc2VtYmxpbmcgdG9nZXRoZXIgY29udGV4dHMg
ZnJvbSBkaWZmZXJlbnQgbGF5ZXJzIHdoaWNoIG1heQ0KYWxyZWFkeSBleGlzdCAodGhhdCBpcywg
dGhlIGxvd2VyIGxheWVyKHMpIG1heSBhbHJlYWR5IGV4aXN0KSwgYXMgcGVyIG15DQptdWx0aS13
ZWJhcHAgdXNlY2FzZSwgYnV0IGluIHRoaXMgY2FzZSB5b3UgYXJlIGRvaW5nIGl0IGR5bmFtaWNh
bGx5DQphbnl3YXlzLCBhbmQgY2FuJ3QgZG8gaXQgYXMgYSBsaXN0Lg0KDQpJZiBldmVyeW9uZSBh
Z3JlZXMsIEknbGwgbWFrZSB0aGUgY2hhbmdlIHRoaXMgd2Vla2VuZCAtLSB0aGUgU3RyaW5nIGFy
cmF5IG9mIGxvY2F0aW9ucyBmZWQgaW50byBGaWxlU3lzdGVtWG1sQXBwbGljYXRpb25Db250ZXh0
IGFuZCBpdHMgc3ViY2xhc3MgQ2xhc3NQYXRoWG1sQXBwbGljYXRpb25Db250ZXh0IHdpbGwgdGhl
biBidWlsZCBhIHNpbmdsZSBjb250ZXh0IHRoYXQgaXMgZGVmaW5lZCBieSBwb3RlbnRpYWxseSBt
dWx0aXBsZSBYTUwgZmlsZXMuDQogDQo+PnB1YmxpYyBjbGFzcyBBdXRvUHJveHlDcmVhdG9yIGlt
cGxlbWVudHMgQmVhblBvc3RQcm9jZXNzb3Igew0KPj4gIHByaXZhdGUgTGlzdCBiZWFuTmFtZXM7
DQo+PiAgcHJpdmF0ZSBJbnRlcmNlcHRvcltdIGludGVyY2VwdG9yczsNCj4+DQo+PiAgcHVibGlj
IHZvaWQgc2V0QmVhbk5hbWVzKFN0cmluZ1tdIGJlYW5OYW1lcykgew0KPj4gICAgdGhpcy5iZWFu
TmFtZXMgPSBBcnJheXMuYXNMaXN0KGJlYW5OYW1lcyk7DQo+PiAgfQ0KPj4NCj4+ICBwdWJsaWMg
dm9pZCBzZXRJbnRlcmNlcHRvcnMoSW50ZXJjZXB0b3JbXSBpbnRlcmNlcHRvcnMpIHsNCj4+ICAg
IHRoaXMuaW50ZXJjZXB0b3JzID0gaW50ZXJjZXB0b3JzOw0KPj4gIH0NCj4+DQo+PiAgcHVibGlj
IE9iamVjdCBwb3N0UHJvY2Vzc0JlYW4oT2JqZWN0IGJlYW4sIFN0cmluZyBuYW1lLCBSb290QmVh
bkRlZmluaXRpb24gZGVmaW5pdGlvbikgew0KPj4gICAgaWYgKHRoaXMuYmVhbk5hbWVzICE9IG51
bGwgJiYgdGhpcy5iZWFuTmFtZXMuY29udGFpbnMobmFtZSkpIHsNCj4+ICAgICAgUHJveHlGYWN0
b3J5IHByb3h5RmFjdG9yeSA9IG5ldyBQcm94eUZhY3RvcnkoKTsNCj4+ICAgICAgZm9yIChpbnQg
aSA9IDA7IGkgPCB0aGlzLmludGVyY2VwdG9ycy5sZW5ndGg7IGkrKykgew0KPj4gICAgICAgIHBy
b3h5RmFjdG9yeS5hZGRJbnRlcmNlcHRvcih0aGlzLmludGVyY2VwdG9yc1tpXSk7DQo+PiAgICAg
IH0NCj4+ICAgICAgcHJveHlGYWN0b3J5LmFkZEludGVyY2VwdG9yKG5ldyBJbnZva2VySW50ZXJj
ZXB0b3IoYmVhbikpOw0KPj4gICAgICByZXR1cm4gcHJveHlGYWN0b3J5LmdldFByb3h5KCk7DQo+
PiAgICB9DQo+PiAgICBlbHNlIHsNCj4+ICAgICAgcmV0dXJuIGJlYW47DQo+PiAgICB9DQo+PiAg
fQ0KPj59DQo+Pg0KPiBJIHJlYWxseSBsaWtlIHRoaXMuIEl0IHdpbGwgcmVkdWNlIGJvaWxlcnBs
YXRlIHByb3h5IGRlZmluaXRpb25zIGZvciA4MCUNCm9mIHRoZSBjb2RlIHRoYXQgbmVlZHMgc2lt
cGxlIHdyYXBwaW5nIG9mIGV2ZXJ5dGhpbmcuLi4NCg0KQXV0b1Byb3h5Q3JlYXRvciBpcyBub3Qg
eWV0IGluIENWUywgYnV0IEkgY2FuIGFkZCBpdCBwcm9tcHRseS4gQlRXLCBJJ20gbm90IHJlYWxs
eSBzdXJlIGFib3V0IHRoZSBuYW1lIC0tIGRvIHlvdSBoYXZlIGEgYmV0dGVyIG5hbWUgZm9yIHN1
Y2ggYSBiZWFuIHRoYXQgYXV0b21hdGljYWxseSB3cmFwcyBvdGhlciBiZWFucyB3aXRoIHByb3hp
ZXM/DQogDQpKdWVyZ2VuDQo=

Re: [Springframework-developer] new bean factory and application context features

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

> What I'm most excited about is the BeanPostProcessor hook. I expect that
to be very powerful, as already indicated by the respective test case in
StaticApplicationContextSuite. Another example that I've prototyped is the
following (not yet in CVS):
> public class AutoProxyCreator implements BeanPostProcessor {
>   private List beanNames;
>   private Interceptor[] interceptors;
>
>   public void setBeanNames(String[] beanNames) {
>     this.beanNames = Arrays.asList(beanNames);
>   }
>
>   public void setInterceptors(Interceptor[] interceptors) {
>     this.interceptors = interceptors;
>   }
>
>   public Object postProcessBean(Object bean, String name,
RootBeanDefinition definition) {
>     if (this.beanNames != null && this.beanNames.contains(name)) {
>       ProxyFactory proxyFactory = new ProxyFactory();
>       for (int i = 0; i < this.interceptors.length; i++) {
>         proxyFactory.addInterceptor(this.interceptors[i]);
>       }
>       proxyFactory.addInterceptor(new InvokerInterceptor(bean));
>       return proxyFactory.getProxy();
>     }
>     else {
>       return bean;
>     }
>   }
> }
> Of course, source-level metadata would allow for just 1 BeanPostProcessor
plus the 10 target beans (11 beans in total), with the transaction
attributes being kept with the respective methods in the source code. This
would just get rid of 1 bean but of a pretty bloated one: the
TransactionInterceptor definition with its centralized transaction
attributes for the whole app.

This _is_ exciting.

Source-level metadata might also mean we wouldn't need to know the names of
the transactional beans. We sould simply need to install a BeanPostProcessor
that would look up metadata. It could work with arbitrary attributes,
depending on registered "attribute scanners".

Combined with good metadata support, I think we can match the ease of use of
.NET for enterprise services in M3. I have always seen this as the killer
application for Spring AOP.

Regards,
Rod

Re: [Springframework-developer] new bean factory and application context features

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

>I really like this. It will reduce boilerplate proxy definitions for 80%
of the code that needs simple wrapping of everything...

I think making common things trivially simple is tremendously important to
users (including me!). This is exactly what Microsoft do well, what Java
does well and what J2EE doesn't do so well out of the box.

We still have all the extensibility features in there for power users, but
I'd be happy not to have to use them most of the time.

Pareto Principle, anyone?