Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2003-09-28 10:57:05
|
SGkgVHJldm9yLA0KIA0KQSBNdWx0aXBhcnRSZXNvbHZlciBpbnRlcmZhY2Ugd2l0aCBpbXBsZW1l bnRhdGlvbnMgZm9yIENvbW1vbnMgRmlsZVVwbG9hZCBhbmQgQ09TIGlzIGZpbmUgd2l0aCBtZSAt IGl0IGp1c3QgaGFkbid0IGhpZ2ggcHJpb3JpdHkgc2luY2UgSSBwcm9wb3NlZCBpdCBoYWxmIGEg eWVhciBhZ28uIEFzIEkgc3RpbGwgaGF2ZSBhIHByZXR0eSBjbGVhciBwaWN0dXJlIG9mIHRoZSBp c3N1ZXMsIEknbGwgYmUgaGFwcHkgdG8gcmV2aWV3IHlvdXIgY29kZSBvbmNlIHlvdSd2ZSBjaGVj a2VkIGl0IGluLiBBcyB0aGlzIHNob3VsZCBiZSBwcmV0dHkgc3RyYWlnaHRmb3J3YXJkLCBsZXQn cyB0cnkgdG8gaW5jbHVkZSB0aGlzIGFscmVhZHkgaW4gMS4wIE0yIC0gYXQgbGVhc3Qgd2l0aCBh IENvbW1vbnMgRmlsZVVwbG9hZCBpbXBsZW1lbnRhdGlvbi4NCiANCkJUVywgaW4gY29udHJhc3Qg dG8gQ09TLCBDb21tb25zIEZpbGVVcGxvYWQgZG9lc24ndCBwcm92aWRlIGEgU2VydmxldCAyLjMg ZmlsdGVyIGFueXdheS4gVGhpcyBtZWFucyB0aGF0IHRoZXJlIHdvdWxkIGJlIHNvbWUgaW5mcmFz dHJ1Y3R1cmUgY29kZSB0byB3cml0ZSBmb3IgdGhhdCB1c2UgY2FzZSB0b28sIGV2ZW4gd2hlbiB1 c2luZyBzdGFuZGFyZCBmaWx0ZXJzLiBBIHNpbXBsZSBidXQgY29udmVuaWVudCBTcHJpbmcgc29s dXRpb24gd291bGQgZGVmaW5pdGVseSBiZSBhIGdvb2QgdGhpbmcuDQogDQpKdWVyZ2VuDQogDQog DQogDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjogVHJldm9y IENvb2sgW21haWx0bzpwcmlzZTAzQHNlbnRleC5uZXRdIA0KCUdlc2VuZGV0OiBTYSAyNy4wOS4y MDAzIDE5OjM1IA0KCUFuOiBTcHJpbmcgRGV2ZWxvcGVycyANCglDYzogDQoJQmV0cmVmZjogW1tX My1TUEFNXV0gLSBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gTXVsdGlwYXJ0IEZpbGUgSGFu ZGxpbmcgLSBFbWFpbCBmb3VuZCBpbiBzdWJqZWN0DQoJDQoJDQoNCglGaXJzdCBzb21lIGhpc3Rv cnk6DQoJaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9tYWlsYXJjaGl2ZS9tZXNzYWdlLnBocD9tc2df aWQ9Mzg5MTI3OQ0KCWh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvbWFpbGFyY2hpdmUvbWVzc2FnZS5w aHA/bXNnX2lkPTUxNzUyNzYNCglodHRwOi8vc291cmNlZm9yZ2UubmV0L21haWxhcmNoaXZlL2Zv cnVtLnBocD90aHJlYWRfaWQ9MzEyNTU2MSZmb3J1bV9pZD0zMDI4DQoJNw0KCWh0dHA6Ly9zb3Vy Y2Vmb3JnZS5uZXQvbWFpbGFyY2hpdmUvbWVzc2FnZS5waHA/bXNnX2lkPTYwNjIyODgNCgkNCglU byBhZGRyZXNzIGEgZmV3IHRoaW5ncyBKdWVyZ2VuIG1lbnRpb25lZCBwcmV2aW91c2x5Lg0KCQ0K CT4+IGEgbGVzcyBpbnRydXNpdmUgd2F5IHdvdWxkIGJlIHRvIHdyYXAgdGhlIEh0dHBTZXJ2bGV0 UmVxdWVzdCB2aWEgYSBmaWx0ZXINCglJIHBlcnNvbmFsbHkgZG9uJ3QgbGlrZSB0aGUgZmlsdGVy IGFwcHJvYWNoLCBhdCBsZWFzdCBmb3IgdGhlIGZyYW1ld29yay4gIEl0DQoJcmVxdWlyZXMgYWRk aXRpb25hbCBzZXR1cCBmb3IgdGhlIHVzZXIgKGluIHRoZSB3ZWIueG1sIGZpbGUpIGFuZCBtaWdo dCBiZQ0KCWxlc3MgdW5kZXJzdGFuZGFibGUgc2luY2Ugb3VyIG5vcm1hbCBzdHJhdGVneSBzbyBm YXIgaGFzIGJlZW4gd2l0aCByZXNvbHZlcnMNCglpbnNpZGUgdGhlIHNlcnZsZXQuDQoJDQoJPj53 ZSB3b3VsZCBuZWVkIHRvIGZpbmQgY29uY3JldGUgcmVxdWlyZW1lbnRzIGZvciB0aGlzDQoJV2Ug aGF2ZSBudW1lcm91cyB1c2VzIGZvciBmaWxlIHVwbG9hZCBoYW5kbGluZy4gIFdlIGhhdmUgYSBw dWJsaWMgcGhvdG8NCgljb250ZXN0IHdoZXJlIHVzZXJzIGNhbiB1cGxvYWQgZm90b3MuICBXZSBo YXZlIHNwZWNpYWwgYWNjZXNzIGZvciBzdXBwbGllcnMNCgl0byB1cGxvYWQgcHJvZHVjdCBmaWxl cyAoY3N2KSB3aGljaCB3ZSB0aGVuIGFkZCBpbiB0byBvdXIgb3JkZXJpbmcgc3lzdGVtLg0KCUZp bmFsbHksIHdlIGhhdmUgYSB3ZWIgYWRtaW5pc3RyYXRpb24gaW50ZXJmYWNlIHdoaWNoIGFsbG93 cyBvdXIgY2xpZW50IHRvDQoJdXBsb2FkIGZpbGVzIHRvIHRoZSB3ZWJzaXRlIHNvIHRoZXkgY2Fu IGJlIGRvd25sb2FkZWQuICBJIHRoaW5rIHRoYXQNCglpbmNsdWRpbmcgdGhpcyBzdXBwb3J0ICht dWx0aXBhcnQgaGFuZGxpbmcpIGlzIGEgbm8tYnJhaW5lci4NCgkNCglCYXNpY2FsbHksIEkgaGF2 ZSB1c2VkIENPUyBleGNsdXNpdmVseSBpbiBvdXIgcHJvamVjdHMsIGJ1dCBJIGRvbid0IHRoaW5r DQoJdGhhdCdzIGVhc3kgZm9yIFNwcmluZyB0byB1c2UgKGR1ZSB0byB0aGUgbGljZW5zaW5nKS4g IEkgd291bGQgc2ltcGx5IGNvZGUNCgl0aGlzIGFjY29yZGluZyB0byBTcHJpbmcgbm9ybXMgdXNp bmcgYW4gaW50ZXJmYWNlIGFuZCBhIGRlZmF1bHQgdmVyc2lvbg0KCXVzaW5nIENvbW1vbnMgRmls ZVVwbG9hZC4gIExhdGVyLCBpZiBzb21lYm9keSB3YW50cyB0byBjcmVhdGUgYSBjb3MgdmVyc2lv bg0KCXdlIGNhbiAoYnV0IHRvIGJlIGhvbmVzdCwgaWYgd2UgaGF2ZSBhIHdvcmtpbmcsIGludGVn cmF0ZWQgc29sdXRpb24gSSdtIG5vdA0KCXN1cmUgdGhhdCBpcyBuZWNlc3NhcnkgLSBhdCBsZWFz dCBub3QgaW4gdGhlIFNwcmluZyBmcmFtZXdvcmspLiAgQmFzaWNhbGx5LA0KCXByb3ZpZGUgaG9v a3MgYW5kIGEgZGVmYXVsdCBpbXBsZW1lbnRhdGlvbiwgYW5kIGFsbG93IHVzZXJzIHRvIGFkb3B0 IGFzDQoJbmVjZXNzYXJ5Lg0KCQ0KCUluIG91ciBwcm9qZWN0IHdlIGhhZCBtb2RpZmllZCB0aGUg QWJzdHJhY3RDb250cm9sbGVyIGFuZCBwdXQgdGhlIGNvZGUgaW50bw0KCWl0IHRvIGhhbmRsZSB0 aGUgbXVsdGlwYXJ0IHByb2Nlc3NpbmcsIHJldHVybmluZyBhIHdyYXBwZWQNCglIdHRwU2Vydmxl dFJlcXVlc3QgdGhyb3VnaCB0aGUgaGFuZGxlcnMuICBUaGlzIGlzIHZlcnkgc2ltaWxpYXIgdG8g SnVlcmdlbidzDQoJb3V0bGluZSAoaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9tYWlsYXJjaGl2ZS9t ZXNzYWdlLnBocD9tc2dfaWQ9Mzg5MTI3OSkuDQoJDQoJU2luY2Ugd2UgYXJlIG1pZ3JhdGluZyB0 byB0aGUgY3VycmVudCBTcHJpbmcgY29kZWJhc2UsIEkgbmVlZCB0byBtb3ZlIG91cg0KCW11bHRp cGFydCBoYW5kbGluZyBjb2RlLiAgVGhlIG1haW4gcXVlc3Rpb24gaXMgd2hldGhlciB3ZSBrZWVw IGl0DQoJaW50ZXJuYWxseSwgb3IgcGxhY2UgaXQgaW50byBTcHJpbmcuICBJIHByb3Bvc2UgbW9k aWZ5aW5nDQoJb3JnLnNwcmluZ2ZyYW1ld29yay53ZWIuc2VydmxldC5EaXNwYXRjaGVyU2Vydmxl dCB0byBoYXZlIGENCgkiTXVsdGlwYXJ0UmVzb2x2ZXIiLiAgSW4gdGhlIERpc3BhdGNoZXJTZXJ2 bGV0LCB0aGUgcmVzb2x2ZXIgd291bGQgYmUgY2FsbGVkDQoJdG8gd3JhcCB0aGUgcmVxdWVzdCBp biBkb1NlcnZpY2UgaW1tZWRpYXRlbHkgYmVmb3JlIGdldEhhbmRsZXIocmVxdWVzdCkgLQ0KCWN1 cnJlbnRseSBsaW5lIDM1MSwgYW5kIHRoZW4gY2FsbGVkIHRvIGRvIGFueSBjbGVhbnVwIGltbWVk aWF0ZWx5IGJlZm9yZQ0KCWV4aXRpbmcgdGhlIGRvU2VydmljZSBtZXRob2QuDQoJDQoJSSBoYXZl IGFib3V0IDIvMyBvZiB0aGUgY29kZSBhbHJlYWR5IHdyaXR0ZW4sIGFuZCBJIHdpbGwgYmUgd3Jp dGluZyB0aGUgcmVzdA0KCWJldHdlZW4gbm93IGFuZCBNb25kYXkuICBEb2VzIHRoaXMgc3RyYXRl Z3kgc291bmQgYXBwcm9wcmlhdGUgZm9yIFNwcmluZw0KCShtZWFuaW5nIHNob3VsZCBJIGNvbW1p dCBpdCB0byB0aGUgU3ByaW5nIGNvZGViYXNlKSB3aGVuIGl0J3MgZmluaXNoZWQ/DQoJDQoJVHJl dm9yIEQuIENvb2sNCglJbnRlcnByaXNlIFNvZnR3YXJlDQoJDQoJDQoJDQoJLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCVRoaXMgc2YubmV0 IGVtYWlsIGlzIHNwb25zb3JlZCBieTpUaGlua0dlZWsNCglXZWxjb21lIHRvIGdlZWsgaGVhdmVu Lg0KCWh0dHA6Ly90aGlua2dlZWsuY29tL3NmDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1haWxpbmcg bGlzdA0KCVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJ aHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3 b3JrLWRldmVsb3Blcg0KCQ0KDQo= |
|
From: <jue...@we...> - 2003-09-28 12:34:18
|
SGkgQWxlZiwNCiANCkEgUHJvcGVydHlFZGl0b3Igd2lsbCBhbHdheXMgc3RhcnQgd2l0aCBhIFN0 cmluZyBhbmQgY29udmVydCBpdCB0byBzb21lIG90aGVyIHR5cGUsIGluIHRoZSB3ZWIgY2FzZSBh cHBsaWVkIHRvIFNlcnZsZXRSZXF1ZXN0J3MgZ2V0UGFyYW1ldGVyIHZhbHVlcy4gSGVyZSB3ZSBn b3QgTXVsdGlwYXJ0RmlsZSBpbnN0YW5jZXMsIHJldHJpZXZhYmxlIHZpYSBNdWx0aXBhcnRTZXJ2 bGV0UmVxdWVzdCdzIGdldEZpbGUoU3RyaW5nIG5hbWUpIG1ldGhvZDogbm8gU3RyaW5ncyBpbiB0 aGUgZmlyc3QgcGxhY2UsIHRodXMgdGhlIFByb3BlcnR5RWRpdG9yIG1lY2hhbmlzbSBpcyBub3Qg YXBwbGljYWJsZS4NCiANCldlIGNvdWxkIHBvc3NpYmx5IGFkZCBhIHNwZWNpYWwgY2hlY2sgdG8g U2VydmxldFJlcXVlc3REYXRhQmluZGVyLCBiaW5kaW5nIE11bHRpcGFydEZpbGUgaW5zdGFuY2Vz IHRvIHJlc3BlY3RpdmUgY29tbWFuZCBiZWFuIGZpZWxkcyBvZiB0aGUgc2FtZSB0eXBlIGluIHRo ZSBjYXNlIG9mIGEgbXVsdGlwYXJ0IHJlcXVlc3QuIFRoYXQgd291bGQgd29yayB3aXRoIGFueSBN dWx0aXBhcnRSZXNvbHZlciBpbXBsZW1lbnRhdGlvbiwgYXMgaXQgY291bGQgdXNlIHRoZSBzYW1l IEFQSSBhcyBtYW51YWwgZmlsZSB1cGxvYWQgaGFuZGxpbmcgY29kZSB0aGF0IGNhc3RzIHRvIE11 bHRpcGFydFNlcnZsZXRSZXF1ZXN0Lg0KIA0KRGVmaW5pdGVseSBhIGZlYXR1cmUgd29ydGggY29u c2lkZXJpbmchDQogDQpKdWVyZ2VuDQogDQogDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hy aWNodC0tLS0tIA0KCVZvbjogQWxlZiBBcmVuZHNlbiAoSlRlYW0pIFttYWlsdG86YWxlZkBqdGVh bS5ubF0gDQoJR2VzZW5kZXQ6IFNvIDI4LjA5LjIwMDMgMTQ6MDQgDQoJQW46IGrDvHJnZW4gaMO2 bGxlciBbd2VyazNBVF07ICdUcmV2b3IgQ29vayc7ICdTcHJpbmcgRGV2ZWxvcGVycycgDQoJQ2M6 IA0KCUJldHJlZmY6IFJFOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gTXVsdGlwYXJ0IEZp bGUgSGFuZGxpbmcNCgkNCgkNCg0KCVdpbGwgdGhlcmUgYmUgYSB3YXkgLSB1c2luZyB0aGlzIHNv bHV0aW9uIC0gdG8gYmluZCB0aGUgZmlsZSB1c2luZyBhIHByb3BlcnR5ZWRpdG9yIChvciBzb21l dGhpbmcgZWxzZSBtYXliZSksIGp1c3QgYXMgYW55IG90aGVyIGNvbW1hbmQgb2JqZWN0IGlzIGZp bGxlZCB3aXRoIHBhcmFtZXRlcnMgZnJvbSB0aGUgcmVxdWVzdC4gRm9yIGNvbnNpc3RlbmN5LCBJ IHRoaW5rIHRoYXQncyBwcmV0dHkgaW1wb3J0YW50IHRvIGJlIGNvbnNpc3RlbnQuDQoJDQoJRnVy dGhlcm1vcmUgSSB0aGluayBpdCdzIHByZXR0eSBjb29sIGlmIHRoZSBmaWxldXBsb2FkIGNvdWxk IGJlIGZpeGVkIGJlZm9yZSB0aGUgMS4wIHJlbGVhc2UhIEdvb2QgdGhpbmchDQoJDQoJQWxlZg0K CQ0KCQ0KCS0tLS0tT29yc3Byb25rZWxpamsgYmVyaWNodC0tLS0tDQoJVmFuOiBzcHJpbmdmcmFt ZXdvcmstZGV2ZWxvcGVyLWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCBbbWFpbHRvOnNwcmlu Z2ZyYW1ld29yay1kZXZlbG9wZXItYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0XSBOYW1lbnMg asO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXQ0KCVZlcnpvbmRlbjogU3VuZGF5LCBTZXB0ZW1iZXIg MjgsIDIwMDMgMTI6MzMgUE0NCglBYW46IFRyZXZvciBDb29rOyBTcHJpbmcgRGV2ZWxvcGVycw0K CU9uZGVyd2VycDogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBNdWx0aXBhcnQgRmls ZSBIYW5kbGluZw0KCQ0KCQ0KCUhpIFRyZXZvciwNCgkNCglBIE11bHRpcGFydFJlc29sdmVyIGlu dGVyZmFjZSB3aXRoIGltcGxlbWVudGF0aW9ucyBmb3IgQ29tbW9ucyBGaWxlVXBsb2FkIGFuZCBD T1MgaXMgZmluZSB3aXRoIG1lIC0gaXQganVzdCBoYWRuJ3QgaGlnaCBwcmlvcml0eSBzaW5jZSBJ IHByb3Bvc2VkIGl0IGhhbGYgYSB5ZWFyIGFnby4gQXMgSSBzdGlsbCBoYXZlIGEgcHJldHR5IGNs ZWFyIHBpY3R1cmUgb2YgdGhlIGlzc3VlcywgSSdsbCBiZSBoYXBweSB0byByZXZpZXcgeW91ciBj b2RlIG9uY2UgeW91J3ZlIGNoZWNrZWQgaXQgaW4uIEFzIHRoaXMgc2hvdWxkIGJlIHByZXR0eSBz dHJhaWdodGZvcndhcmQsIGxldCdzIHRyeSB0byBpbmNsdWRlIHRoaXMgYWxyZWFkeSBpbiAxLjAg TTIgLSBhdCBsZWFzdCB3aXRoIGEgQ29tbW9ucyBGaWxlVXBsb2FkIGltcGxlbWVudGF0aW9uLg0K CQ0KCUJUVywgaW4gY29udHJhc3QgdG8gQ09TLCBDb21tb25zIEZpbGVVcGxvYWQgZG9lc24ndCBw cm92aWRlIGEgU2VydmxldCAyLjMgZmlsdGVyIGFueXdheS4gVGhpcyBtZWFucyB0aGF0IHRoZXJl IHdvdWxkIGJlIHNvbWUgaW5mcmFzdHJ1Y3R1cmUgY29kZSB0byB3cml0ZSBmb3IgdGhhdCB1c2Ug Y2FzZSB0b28sIGV2ZW4gd2hlbiB1c2luZyBzdGFuZGFyZCBmaWx0ZXJzLiBBIHNpbXBsZSBidXQg Y29udmVuaWVudCBTcHJpbmcgc29sdXRpb24gd291bGQgZGVmaW5pdGVseSBiZSBhIGdvb2QgdGhp bmcuDQoJDQoJSnVlcmdlbg0KCQ0KCQ0KCQ0KCQ0KCSAgICAgICAgLS0tLS1VcnNwcsO8bmdsaWNo ZSBOYWNocmljaHQtLS0tLQ0KCSAgICAgICAgVm9uOiBUcmV2b3IgQ29vayBbbWFpbHRvOnByaXNl MDNAc2VudGV4Lm5ldF0NCgkgICAgICAgIEdlc2VuZGV0OiBTYSAyNy4wOS4yMDAzIDE5OjM1DQoJ ICAgICAgICBBbjogU3ByaW5nIERldmVsb3BlcnMNCgkgICAgICAgIENjOg0KCSAgICAgICAgQmV0 cmVmZjogW1tXMy1TUEFNXV0gLSBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gTXVsdGlwYXJ0 IEZpbGUgSGFuZGxpbmcgLSBFbWFpbCBmb3VuZCBpbiBzdWJqZWN0DQoJICAgICAgIA0KCSAgICAg ICANCgkNCgkgICAgICAgIEZpcnN0IHNvbWUgaGlzdG9yeToNCgkgICAgICAgIGh0dHA6Ly9zb3Vy Y2Vmb3JnZS5uZXQvbWFpbGFyY2hpdmUvbWVzc2FnZS5waHA/bXNnX2lkPTM4OTEyNzkNCgkgICAg ICAgIGh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvbWFpbGFyY2hpdmUvbWVzc2FnZS5waHA/bXNnX2lk PTUxNzUyNzYNCgkgICAgICAgIGh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvbWFpbGFyY2hpdmUvZm9y dW0ucGhwP3RocmVhZF9pZD0zMTI1NTYxJmZvcnVtX2lkPTMwMjgNCgkgICAgICAgIDcNCgkgICAg ICAgIGh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvbWFpbGFyY2hpdmUvbWVzc2FnZS5waHA/bXNnX2lk PTYwNjIyODgNCgkgICAgICAgDQoJICAgICAgICBUbyBhZGRyZXNzIGEgZmV3IHRoaW5ncyBKdWVy Z2VuIG1lbnRpb25lZCBwcmV2aW91c2x5Lg0KCSAgICAgICANCgkgICAgICAgID4+IGEgbGVzcyBp bnRydXNpdmUgd2F5IHdvdWxkIGJlIHRvIHdyYXAgdGhlIEh0dHBTZXJ2bGV0UmVxdWVzdCB2aWEg YSBmaWx0ZXINCgkgICAgICAgIEkgcGVyc29uYWxseSBkb24ndCBsaWtlIHRoZSBmaWx0ZXIgYXBw cm9hY2gsIGF0IGxlYXN0IGZvciB0aGUgZnJhbWV3b3JrLiAgSXQNCgkgICAgICAgIHJlcXVpcmVz IGFkZGl0aW9uYWwgc2V0dXAgZm9yIHRoZSB1c2VyIChpbiB0aGUgd2ViLnhtbCBmaWxlKSBhbmQg bWlnaHQgYmUNCgkgICAgICAgIGxlc3MgdW5kZXJzdGFuZGFibGUgc2luY2Ugb3VyIG5vcm1hbCBz dHJhdGVneSBzbyBmYXIgaGFzIGJlZW4gd2l0aCByZXNvbHZlcnMNCgkgICAgICAgIGluc2lkZSB0 aGUgc2VydmxldC4NCgkgICAgICAgDQoJICAgICAgICA+PndlIHdvdWxkIG5lZWQgdG8gZmluZCBj b25jcmV0ZSByZXF1aXJlbWVudHMgZm9yIHRoaXMNCgkgICAgICAgIFdlIGhhdmUgbnVtZXJvdXMg dXNlcyBmb3IgZmlsZSB1cGxvYWQgaGFuZGxpbmcuICBXZSBoYXZlIGEgcHVibGljIHBob3RvDQoJ ICAgICAgICBjb250ZXN0IHdoZXJlIHVzZXJzIGNhbiB1cGxvYWQgZm90b3MuICBXZSBoYXZlIHNw ZWNpYWwgYWNjZXNzIGZvciBzdXBwbGllcnMNCgkgICAgICAgIHRvIHVwbG9hZCBwcm9kdWN0IGZp bGVzIChjc3YpIHdoaWNoIHdlIHRoZW4gYWRkIGluIHRvIG91ciBvcmRlcmluZyBzeXN0ZW0uDQoJ ICAgICAgICBGaW5hbGx5LCB3ZSBoYXZlIGEgd2ViIGFkbWluaXN0cmF0aW9uIGludGVyZmFjZSB3 aGljaCBhbGxvd3Mgb3VyIGNsaWVudCB0bw0KCSAgICAgICAgdXBsb2FkIGZpbGVzIHRvIHRoZSB3 ZWJzaXRlIHNvIHRoZXkgY2FuIGJlIGRvd25sb2FkZWQuICBJIHRoaW5rIHRoYXQNCgkgICAgICAg IGluY2x1ZGluZyB0aGlzIHN1cHBvcnQgKG11bHRpcGFydCBoYW5kbGluZykgaXMgYSBuby1icmFp bmVyLg0KCSAgICAgICANCgkgICAgICAgIEJhc2ljYWxseSwgSSBoYXZlIHVzZWQgQ09TIGV4Y2x1 c2l2ZWx5IGluIG91ciBwcm9qZWN0cywgYnV0IEkgZG9uJ3QgdGhpbmsNCgkgICAgICAgIHRoYXQn cyBlYXN5IGZvciBTcHJpbmcgdG8gdXNlIChkdWUgdG8gdGhlIGxpY2Vuc2luZykuICBJIHdvdWxk IHNpbXBseSBjb2RlDQoJICAgICAgICB0aGlzIGFjY29yZGluZyB0byBTcHJpbmcgbm9ybXMgdXNp bmcgYW4gaW50ZXJmYWNlIGFuZCBhIGRlZmF1bHQgdmVyc2lvbg0KCSAgICAgICAgdXNpbmcgQ29t bW9ucyBGaWxlVXBsb2FkLiAgTGF0ZXIsIGlmIHNvbWVib2R5IHdhbnRzIHRvIGNyZWF0ZSBhIGNv cyB2ZXJzaW9uDQoJICAgICAgICB3ZSBjYW4gKGJ1dCB0byBiZSBob25lc3QsIGlmIHdlIGhhdmUg YSB3b3JraW5nLCBpbnRlZ3JhdGVkIHNvbHV0aW9uIEknbSBub3QNCgkgICAgICAgIHN1cmUgdGhh dCBpcyBuZWNlc3NhcnkgLSBhdCBsZWFzdCBub3QgaW4gdGhlIFNwcmluZyBmcmFtZXdvcmspLiAg QmFzaWNhbGx5LA0KCSAgICAgICAgcHJvdmlkZSBob29rcyBhbmQgYSBkZWZhdWx0IGltcGxlbWVu dGF0aW9uLCBhbmQgYWxsb3cgdXNlcnMgdG8gYWRvcHQgYXMNCgkgICAgICAgIG5lY2Vzc2FyeS4N CgkgICAgICAgDQoJICAgICAgICBJbiBvdXIgcHJvamVjdCB3ZSBoYWQgbW9kaWZpZWQgdGhlIEFi c3RyYWN0Q29udHJvbGxlciBhbmQgcHV0IHRoZSBjb2RlIGludG8NCgkgICAgICAgIGl0IHRvIGhh bmRsZSB0aGUgbXVsdGlwYXJ0IHByb2Nlc3NpbmcsIHJldHVybmluZyBhIHdyYXBwZWQNCgkgICAg ICAgIEh0dHBTZXJ2bGV0UmVxdWVzdCB0aHJvdWdoIHRoZSBoYW5kbGVycy4gIFRoaXMgaXMgdmVy eSBzaW1pbGlhciB0byBKdWVyZ2VuJ3MNCgkgICAgICAgIG91dGxpbmUgKGh0dHA6Ly9zb3VyY2Vm b3JnZS5uZXQvbWFpbGFyY2hpdmUvbWVzc2FnZS5waHA/bXNnX2lkPTM4OTEyNzkpLg0KCSAgICAg ICANCgkgICAgICAgIFNpbmNlIHdlIGFyZSBtaWdyYXRpbmcgdG8gdGhlIGN1cnJlbnQgU3ByaW5n IGNvZGViYXNlLCBJIG5lZWQgdG8gbW92ZSBvdXINCgkgICAgICAgIG11bHRpcGFydCBoYW5kbGlu ZyBjb2RlLiAgVGhlIG1haW4gcXVlc3Rpb24gaXMgd2hldGhlciB3ZSBrZWVwIGl0DQoJICAgICAg ICBpbnRlcm5hbGx5LCBvciBwbGFjZSBpdCBpbnRvIFNwcmluZy4gIEkgcHJvcG9zZSBtb2RpZnlp bmcNCgkgICAgICAgIG9yZy5zcHJpbmdmcmFtZXdvcmsud2ViLnNlcnZsZXQuRGlzcGF0Y2hlclNl cnZsZXQgdG8gaGF2ZSBhDQoJICAgICAgICAiTXVsdGlwYXJ0UmVzb2x2ZXIiLiAgSW4gdGhlIERp c3BhdGNoZXJTZXJ2bGV0LCB0aGUgcmVzb2x2ZXIgd291bGQgYmUgY2FsbGVkDQoJICAgICAgICB0 byB3cmFwIHRoZSByZXF1ZXN0IGluIGRvU2VydmljZSBpbW1lZGlhdGVseSBiZWZvcmUgZ2V0SGFu ZGxlcihyZXF1ZXN0KSAtDQoJICAgICAgICBjdXJyZW50bHkgbGluZSAzNTEsIGFuZCB0aGVuIGNh bGxlZCB0byBkbyBhbnkgY2xlYW51cCBpbW1lZGlhdGVseSBiZWZvcmUNCgkgICAgICAgIGV4aXRp bmcgdGhlIGRvU2VydmljZSBtZXRob2QuDQoJICAgICAgIA0KCSAgICAgICAgSSBoYXZlIGFib3V0 IDIvMyBvZiB0aGUgY29kZSBhbHJlYWR5IHdyaXR0ZW4sIGFuZCBJIHdpbGwgYmUgd3JpdGluZyB0 aGUgcmVzdA0KCSAgICAgICAgYmV0d2VlbiBub3cgYW5kIE1vbmRheS4gIERvZXMgdGhpcyBzdHJh dGVneSBzb3VuZCBhcHByb3ByaWF0ZSBmb3IgU3ByaW5nDQoJICAgICAgICAobWVhbmluZyBzaG91 bGQgSSBjb21taXQgaXQgdG8gdGhlIFNwcmluZyBjb2RlYmFzZSkgd2hlbiBpdCdzIGZpbmlzaGVk Pw0KCSAgICAgICANCgkgICAgICAgIFRyZXZvciBELiBDb29rDQoJICAgICAgICBJbnRlcnByaXNl IFNvZnR3YXJlDQoJICAgICAgIA0KCSAgICAgICANCgkgICAgICAgDQoJICAgICAgICAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJICAgICAg ICBUaGlzIHNmLm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6VGhpbmtHZWVrDQoJICAgICAgICBX ZWxjb21lIHRvIGdlZWsgaGVhdmVuLg0KCSAgICAgICAgaHR0cDovL3RoaW5rZ2Vlay5jb20vc2YN CgkgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoJICAgICAgICBTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1haWxpbmcgbGlzdA0KCSAgICAg ICAgU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCgkgICAg ICAgIGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3NwcmluZ2Zy YW1ld29yay1kZXZlbG9wZXINCgkgICAgICAgDQoJDQoJThggWHUpGVkgZyAXICBIekdKIGpn7qK5 eu29ie23mXjLpiBHIMuycSB6IG0/WCAoHn56dyBYIGLLnT8gIGpn67CiHXrtvZbtspcNCgkNCgkN Cg0K |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-09-28 13:20:57
|
In one of my previous mails I mentioned doing something like that. It =
involved base64 encoding the byte[] to a String, after which the =
propertyeditor picked it up, decoded it again into a byte[] and set it =
on the object! Arghhh.... (as in wow that's ugly ;-).
I did this, because I rely completely on the mvc framework and 1) did =
not want to put in some MultiPart object in my object model, I just =
wanted a byte[] and 2) just didn't want to make compromises simply =
because of propertyeditors being only capable of handling Strings. Ok, =
the solution is nasty and definitely not up for adding, but I really =
think it should worked in such way that things stay consistent while on =
the other hand, not forcing a user at all to modify stuff in it's =
datamodel... May sound a bit harsh, sorry for that ;-)
Would it be possible to define a simple Spring-proprietary conversion =
interface/class which users can implement themselves capable of =
transforming multpartfile object (or whatever other type) to objects =
defined in a user's datamodel. Something like the following.
class FileUploadConvertor {
public Object convert(MultiPartFile);
}
Just some thoughts...
Alef
-----Oorspronkelijk bericht-----
Van: spr...@li... =
[mailto:spr...@li...] Namens =
j=C3=BCrgen h=C3=B6ller [werk3AT]
Verzonden: Sunday, September 28, 2003 2:31 PM
Aan: al...@jt...; Trevor Cook; Spring Developers
Onderwerp: Re: [Springframework-developer] Multipart File Handling
Hi Alef,
=20
A PropertyEditor will always start with a String and convert it to some =
other type, in the web case applied to ServletRequest's getParameter =
values. Here we got MultipartFile instances, retrievable via =
MultipartServletRequest's getFile(String name) method: no Strings in the =
first place, thus the PropertyEditor mechanism is not applicable.
=20
We could possibly add a special check to ServletRequestDataBinder, =
binding MultipartFile instances to respective command bean fields of the =
same type in the case of a multipart request. That would work with any =
MultipartResolver implementation, as it could use the same API as manual =
file upload handling code that casts to MultipartServletRequest.
=20
Definitely a feature worth considering!
=20
Juergen
=20
=20
-----Urspr=C3=BCngliche Nachricht-----=20
Von: Alef Arendsen (JTeam) [mailto:al...@jt...]=20
Gesendet: So 28.09.2003 14:04=20
An: j=C3=BCrgen h=C3=B6ller [werk3AT]; 'Trevor Cook'; 'Spring =
Developers'=20
Cc:=20
Betreff: RE: [Springframework-developer] Multipart File Handling
=09
=09
Will there be a way - using this solution - to bind the file using a =
propertyeditor (or something else maybe), just as any other command =
object is filled with parameters from the request. For consistency, I =
think that's pretty important to be consistent.
=09
Furthermore I think it's pretty cool if the fileupload could be fixed =
before the 1.0 release! Good thing!
=09
Alef
=09
=09
-----Oorspronkelijk bericht-----
Van: spr...@li... =
[mailto:spr...@li...] Namens =
j=C3=BCrgen h=C3=B6ller [werk3AT]
Verzonden: Sunday, September 28, 2003 12:33 PM
Aan: Trevor Cook; Spring Developers
Onderwerp: Re: [Springframework-developer] Multipart File Handling
=09
=09
Hi Trevor,
=09
A MultipartResolver interface with implementations for Commons =
FileUpload and COS is fine with me - it just hadn't high priority since =
I proposed it half a year ago. As I still have a pretty clear picture of =
the issues, I'll be happy to review your code once you've checked it in. =
As this should be pretty straightforward, let's try to include this =
already in 1.0 M2 - at least with a Commons FileUpload implementation.
=09
BTW, in contrast to COS, Commons FileUpload doesn't provide a Servlet =
2.3 filter anyway. This means that there would be some infrastructure =
code to write for that use case too, even when using standard filters. A =
simple but convenient Spring solution would definitely be a good thing.
=09
Juergen
=09
=09
=09
=09
-----Urspr=C3=BCngliche Nachricht-----
Von: Trevor Cook [mailto:pr...@se...]
Gesendet: Sa 27.09.2003 19:35
An: Spring Developers
Cc:
Betreff: [[W3-SPAM]] - [Springframework-developer] Multipart =
File Handling - Email found in subject
=20
=20
=09
First some history:
http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279
http://sourceforge.net/mailarchive/message.php?msg_id=3D5175276
=
http://sourceforge.net/mailarchive/forum.php?thread_id=3D3125561&forum_id=
=3D3028
7
http://sourceforge.net/mailarchive/message.php?msg_id=3D6062288
=20
To address a few things Juergen mentioned previously.
=20
>> a less intrusive way would be to wrap the HttpServletRequest =
via a filter
I personally don't like the filter approach, at least for the =
framework. It
requires additional setup for the user (in the web.xml file) =
and might be
less understandable since our normal strategy so far has been =
with resolvers
inside the servlet.
=20
>>we would need to find concrete requirements for this
We have numerous uses for file upload handling. We have a =
public photo
contest where users can upload fotos. We have special access =
for suppliers
to upload product files (csv) which we then add in to our =
ordering system.
Finally, we have a web administration interface which allows =
our client to
upload files to the website so they can be downloaded. I think =
that
including this support (multipart handling) is a no-brainer.
=20
Basically, I have used COS exclusively in our projects, but I =
don't think
that's easy for Spring to use (due to the licensing). I would =
simply code
this according to Spring norms using an interface and a default =
version
using Commons FileUpload. Later, if somebody wants to create a =
cos version
we can (but to be honest, if we have a working, integrated =
solution I'm not
sure that is necessary - at least not in the Spring framework). =
Basically,
provide hooks and a default implementation, and allow users to =
adopt as
necessary.
=20
In our project we had modified the AbstractController and put =
the code into
it to handle the multipart processing, returning a wrapped
HttpServletRequest through the handlers. This is very similiar =
to Juergen's
outline =
(http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279).
=20
Since we are migrating to the current Spring codebase, I need =
to move our
multipart handling code. The main question is whether we keep =
it
internally, or place it into Spring. I propose modifying
org.springframework.web.servlet.DispatcherServlet to have a
"MultipartResolver". In the DispatcherServlet, the resolver =
would be called
to wrap the request in doService immediately before =
getHandler(request) -
currently line 351, and then called to do any cleanup =
immediately before
exiting the doService method.
=20
I have about 2/3 of the code already written, and I will be =
writing the rest
between now and Monday. Does this strategy sound appropriate =
for Spring
(meaning should I commit it to the Spring codebase) when it's =
finished?
=20
Trevor D. Cook
Interprise Software
=20
=20
=20
-------------------------------------------------------
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
=20
=09
N=18 Xu)=19Y g =17 HzGJ jg=EE=A2=B9z=ED=BD=89=ED=B7=99x=CB=A6 G =
=CB=B2q z m?X (=1E~zw X b=CB=9D? jg=EB=B0=A2=1Dz=ED=BD=96=ED=B2=97
=09
=09
N=18 =E9=9A=8AX'u=DE=BC)=19 Y\g=E9=A2=AD =17 =7F b=D8=9EH=1EzG(=1FJ =
jg=EB=B0=A2=1Dz=ED=BD=96=ED=B2=97x%R=CB=A6 (G^=EC=AE=BDh lq zm=D8=B6?X =
(=1E~zw X b=CB=9D? jg=EB=B0=A2=1Dz=ED=BD=96=ED=B2=97
|
|
From: <jue...@we...> - 2003-09-28 14:23:16
|
QWxlZiwNCiANCkknbSBub3Qga2VlbiBvbiBpbnRyb2R1Y2luZyB5ZXQgYW5vdGhlciBjb252ZXJ0 ZXIgaW50ZXJmYWNlLCBlc3BlY2lhbGx5IGFzIHRoZXJlJ3MgaGFyZGx5IGFueSB2YXJpYXRpb24g cG9zc2libGUgaW4gdGVybXMgb2YgZmlsZSB1cGxvYWQgaGFuZGxpbmcuIEkgYWdyZWUgdGhvdWdo IHRoYXQgaGF2aW5nIE11bHRpcGFydEZpbGUgaW4gdGhlIG9iamVjdCBtb2RlbCBpc24ndCBkZXNp cmFibGUuDQogDQpXaGF0IGFib3V0IHdyaXRpbmcgdGhlIGF1dG9tYXRpYyBjaGVjayBpbiBTZXJ2 bGV0UmVxdWVzdERhdGFCaW5kZXIgc28gdGhhdCBpdCBhc3N1bWVzIGEgYnl0ZVtdIGZvciB0aGUg dXBsb2FkZWQgZmlsZT8gSSBjYW4ndCB0aGluayBvZiBhbnkgb3RoZXIgZ2VuZXJpYyB0eXBlIHN1 aXRhYmxlIGZvciB1cGxvYWRlZCBmaWxlcy4gamF2YS5pby5GaWxlIGlzIG5vIGNhbmRpZGF0ZSBh cyB3ZSB3b3VsZCBuZWVkIHRvIGRldGVybWluZSBhIHBhdGggdG8gc2F2ZSB0aGUgZmlsZSB0by4g SSBjb25zaWRlciBzdWNoIHBlcnNpc3RpbmcgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBhcHBs aWNhdGlvbiBjb2RlIGl0c2VsZiwgZXNwZWNpYWxseSBhcyB0aGUgdXBsb2FkZWQgc3R1ZmYgd2ls bCBvZnRlbiBiZSBzdG9yZWQgdG8gYSByZWxhdGlvbmFsIGRhdGFiYXNlLg0KIA0KRm9yIGFueXRo aW5nIGVsc2UgdGhhbiBieXRlW10gYXMgcHJvcGVydHkgdHlwZSBpbiBhIGNvbW1hbmQgb2JqZWN0 LCBldmVuIE11bHRpcGFydEZpbGUgaWYgZGVzaXJlZCwgb25lIGNhbiBhbHdheXMgb3ZlcnJpZGUg b25CaW5kQW5kVmFsaWRhdGUgYW5kIHBlcmZvcm0gbWFudWFsIGJpbmRpbmcuIFdvdWxkIHRoYXQg YmUgcG93ZXJmdWwgZW5vdWdoIGZvciB5b3VyIHVzZSBjYXNlcz8NCiANCkp1ZXJnZW4NCiANCiAN Cg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBBbGVmIEFyZW5k c2VuIChKVGVhbSkgW21haWx0bzphbGVmQGp0ZWFtLm5sXSANCglHZXNlbmRldDogU28gMjguMDku MjAwMyAxNTozMSANCglBbjogasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXTsgJ1RyZXZvciBDb29r JzsgJ1NwcmluZyBEZXZlbG9wZXJzJyANCglDYzogDQoJQmV0cmVmZjogUkU6IFtTcHJpbmdmcmFt ZXdvcmstZGV2ZWxvcGVyXSBNdWx0aXBhcnQgRmlsZSBIYW5kbGluZw0KCQ0KCQ0KDQoJSW4gb25l IG9mIG15IHByZXZpb3VzIG1haWxzIEkgbWVudGlvbmVkIGRvaW5nIHNvbWV0aGluZyBsaWtlIHRo YXQuIEl0IGludm9sdmVkIGJhc2U2NCBlbmNvZGluZyB0aGUgYnl0ZVtdIHRvIGEgU3RyaW5nLCBh ZnRlciB3aGljaCB0aGUgcHJvcGVydHllZGl0b3IgcGlja2VkIGl0IHVwLCBkZWNvZGVkIGl0IGFn YWluIGludG8gYSBieXRlW10gYW5kIHNldCBpdCBvbiB0aGUgb2JqZWN0ISBBcmdoaGguLi4uIChh cyBpbiB3b3cgdGhhdCdzIHVnbHkgOy0pLg0KCQ0KCUkgZGlkIHRoaXMsIGJlY2F1c2UgSSByZWx5 IGNvbXBsZXRlbHkgb24gdGhlIG12YyBmcmFtZXdvcmsgYW5kIDEpIGRpZCBub3Qgd2FudCB0byBw dXQgaW4gc29tZSBNdWx0aVBhcnQgb2JqZWN0IGluIG15IG9iamVjdCBtb2RlbCwgSSBqdXN0IHdh bnRlZCBhIGJ5dGVbXSBhbmQgMikganVzdCBkaWRuJ3Qgd2FudCB0byBtYWtlIGNvbXByb21pc2Vz IHNpbXBseSBiZWNhdXNlIG9mIHByb3BlcnR5ZWRpdG9ycyBiZWluZyBvbmx5IGNhcGFibGUgb2Yg aGFuZGxpbmcgU3RyaW5ncy4gT2ssIHRoZSBzb2x1dGlvbiBpcyBuYXN0eSBhbmQgZGVmaW5pdGVs eSBub3QgdXAgZm9yIGFkZGluZywgYnV0IEkgcmVhbGx5IHRoaW5rIGl0IHNob3VsZCB3b3JrZWQg aW4gc3VjaCB3YXkgdGhhdCB0aGluZ3Mgc3RheSBjb25zaXN0ZW50IHdoaWxlIG9uIHRoZSBvdGhl ciBoYW5kLCBub3QgZm9yY2luZyBhIHVzZXIgYXQgYWxsIHRvIG1vZGlmeSBzdHVmZiBpbiBpdCdz IGRhdGFtb2RlbC4uLiBNYXkgc291bmQgYSBiaXQgaGFyc2gsIHNvcnJ5IGZvciB0aGF0IDstKQ0K CQ0KCVdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGRlZmluZSBhIHNpbXBsZSBTcHJpbmctcHJvcHJp ZXRhcnkgY29udmVyc2lvbiBpbnRlcmZhY2UvY2xhc3Mgd2hpY2ggdXNlcnMgY2FuIGltcGxlbWVu dCB0aGVtc2VsdmVzIGNhcGFibGUgb2YgdHJhbnNmb3JtaW5nIG11bHRwYXJ0ZmlsZSBvYmplY3Qg KG9yIHdoYXRldmVyIG90aGVyIHR5cGUpIHRvIG9iamVjdHMgZGVmaW5lZCBpbiBhIHVzZXIncyBk YXRhbW9kZWwuIFNvbWV0aGluZyBsaWtlIHRoZSBmb2xsb3dpbmcuDQoJDQoJY2xhc3MgRmlsZVVw bG9hZENvbnZlcnRvciB7DQoJICAgICAgICBwdWJsaWMgT2JqZWN0IGNvbnZlcnQoTXVsdGlQYXJ0 RmlsZSk7DQoJfQ0KCQ0KCUp1c3Qgc29tZSB0aG91Z2h0cy4uLg0KCQ0KCUFsZWYNCgkNCgkNCgkt LS0tLU9vcnNwcm9ua2VsaWprIGJlcmljaHQtLS0tLQ0KCVZhbjogc3ByaW5nZnJhbWV3b3JrLWRl dmVsb3Blci1hZG1pbkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgW21haWx0bzpzcHJpbmdmcmFtZXdv cmstZGV2ZWxvcGVyLWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldF0gTmFtZW5zIGrDvHJnZW4g aMO2bGxlciBbd2VyazNBVF0NCglWZXJ6b25kZW46IFN1bmRheSwgU2VwdGVtYmVyIDI4LCAyMDAz IDI6MzEgUE0NCglBYW46IGFsZWZAanRlYW0ubmw7IFRyZXZvciBDb29rOyBTcHJpbmcgRGV2ZWxv cGVycw0KCU9uZGVyd2VycDogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBNdWx0aXBh cnQgRmlsZSBIYW5kbGluZw0KCQ0KCQ0KCUhpIEFsZWYsDQoJDQoJQSBQcm9wZXJ0eUVkaXRvciB3 aWxsIGFsd2F5cyBzdGFydCB3aXRoIGEgU3RyaW5nIGFuZCBjb252ZXJ0IGl0IHRvIHNvbWUgb3Ro ZXIgdHlwZSwgaW4gdGhlIHdlYiBjYXNlIGFwcGxpZWQgdG8gU2VydmxldFJlcXVlc3QncyBnZXRQ YXJhbWV0ZXIgdmFsdWVzLiBIZXJlIHdlIGdvdCBNdWx0aXBhcnRGaWxlIGluc3RhbmNlcywgcmV0 cmlldmFibGUgdmlhIE11bHRpcGFydFNlcnZsZXRSZXF1ZXN0J3MgZ2V0RmlsZShTdHJpbmcgbmFt ZSkgbWV0aG9kOiBubyBTdHJpbmdzIGluIHRoZSBmaXJzdCBwbGFjZSwgdGh1cyB0aGUgUHJvcGVy dHlFZGl0b3IgbWVjaGFuaXNtIGlzIG5vdCBhcHBsaWNhYmxlLg0KCQ0KCVdlIGNvdWxkIHBvc3Np Ymx5IGFkZCBhIHNwZWNpYWwgY2hlY2sgdG8gU2VydmxldFJlcXVlc3REYXRhQmluZGVyLCBiaW5k aW5nIE11bHRpcGFydEZpbGUgaW5zdGFuY2VzIHRvIHJlc3BlY3RpdmUgY29tbWFuZCBiZWFuIGZp ZWxkcyBvZiB0aGUgc2FtZSB0eXBlIGluIHRoZSBjYXNlIG9mIGEgbXVsdGlwYXJ0IHJlcXVlc3Qu IFRoYXQgd291bGQgd29yayB3aXRoIGFueSBNdWx0aXBhcnRSZXNvbHZlciBpbXBsZW1lbnRhdGlv biwgYXMgaXQgY291bGQgdXNlIHRoZSBzYW1lIEFQSSBhcyBtYW51YWwgZmlsZSB1cGxvYWQgaGFu ZGxpbmcgY29kZSB0aGF0IGNhc3RzIHRvIE11bHRpcGFydFNlcnZsZXRSZXF1ZXN0Lg0KCQ0KCURl ZmluaXRlbHkgYSBmZWF0dXJlIHdvcnRoIGNvbnNpZGVyaW5nIQ0KCQ0KCUp1ZXJnZW4NCgkNCgkN CgkNCgkgICAgICAgIC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCgkgICAgICAg IFZvbjogQWxlZiBBcmVuZHNlbiAoSlRlYW0pIFttYWlsdG86YWxlZkBqdGVhbS5ubF0NCgkgICAg ICAgIEdlc2VuZGV0OiBTbyAyOC4wOS4yMDAzIDE0OjA0DQoJICAgICAgICBBbjogasO8cmdlbiBo w7ZsbGVyIFt3ZXJrM0FUXTsgJ1RyZXZvciBDb29rJzsgJ1NwcmluZyBEZXZlbG9wZXJzJw0KCSAg ICAgICAgQ2M6DQoJICAgICAgICBCZXRyZWZmOiBSRTogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9w ZXJdIE11bHRpcGFydCBGaWxlIEhhbmRsaW5nDQoJICAgICAgIA0KCSAgICAgICANCgkNCgkgICAg ICAgIFdpbGwgdGhlcmUgYmUgYSB3YXkgLSB1c2luZyB0aGlzIHNvbHV0aW9uIC0gdG8gYmluZCB0 aGUgZmlsZSB1c2luZyBhIHByb3BlcnR5ZWRpdG9yIChvciBzb21ldGhpbmcgZWxzZSBtYXliZSks IGp1c3QgYXMgYW55IG90aGVyIGNvbW1hbmQgb2JqZWN0IGlzIGZpbGxlZCB3aXRoIHBhcmFtZXRl cnMgZnJvbSB0aGUgcmVxdWVzdC4gRm9yIGNvbnNpc3RlbmN5LCBJIHRoaW5rIHRoYXQncyBwcmV0 dHkgaW1wb3J0YW50IHRvIGJlIGNvbnNpc3RlbnQuDQoJICAgICAgIA0KCSAgICAgICAgRnVydGhl cm1vcmUgSSB0aGluayBpdCdzIHByZXR0eSBjb29sIGlmIHRoZSBmaWxldXBsb2FkIGNvdWxkIGJl IGZpeGVkIGJlZm9yZSB0aGUgMS4wIHJlbGVhc2UhIEdvb2QgdGhpbmchDQoJICAgICAgIA0KCSAg ICAgICAgQWxlZg0KCSAgICAgICANCgkgICAgICAgDQoJICAgICAgICAtLS0tLU9vcnNwcm9ua2Vs aWprIGJlcmljaHQtLS0tLQ0KCSAgICAgICAgVmFuOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVy LWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCBbbWFpbHRvOnNwcmluZ2ZyYW1ld29yay1kZXZl bG9wZXItYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0XSBOYW1lbnMgasO8cmdlbiBow7ZsbGVy IFt3ZXJrM0FUXQ0KCSAgICAgICAgVmVyem9uZGVuOiBTdW5kYXksIFNlcHRlbWJlciAyOCwgMjAw MyAxMjozMyBQTQ0KCSAgICAgICAgQWFuOiBUcmV2b3IgQ29vazsgU3ByaW5nIERldmVsb3BlcnMN CgkgICAgICAgIE9uZGVyd2VycDogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBNdWx0 aXBhcnQgRmlsZSBIYW5kbGluZw0KCSAgICAgICANCgkgICAgICAgDQoJICAgICAgICBIaSBUcmV2 b3IsDQoJICAgICAgIA0KCSAgICAgICAgQSBNdWx0aXBhcnRSZXNvbHZlciBpbnRlcmZhY2Ugd2l0 aCBpbXBsZW1lbnRhdGlvbnMgZm9yIENvbW1vbnMgRmlsZVVwbG9hZCBhbmQgQ09TIGlzIGZpbmUg d2l0aCBtZSAtIGl0IGp1c3QgaGFkbid0IGhpZ2ggcHJpb3JpdHkgc2luY2UgSSBwcm9wb3NlZCBp dCBoYWxmIGEgeWVhciBhZ28uIEFzIEkgc3RpbGwgaGF2ZSBhIHByZXR0eSBjbGVhciBwaWN0dXJl IG9mIHRoZSBpc3N1ZXMsIEknbGwgYmUgaGFwcHkgdG8gcmV2aWV3IHlvdXIgY29kZSBvbmNlIHlv dSd2ZSBjaGVja2VkIGl0IGluLiBBcyB0aGlzIHNob3VsZCBiZSBwcmV0dHkgc3RyYWlnaHRmb3J3 YXJkLCBsZXQncyB0cnkgdG8gaW5jbHVkZSB0aGlzIGFscmVhZHkgaW4gMS4wIE0yIC0gYXQgbGVh c3Qgd2l0aCBhIENvbW1vbnMgRmlsZVVwbG9hZCBpbXBsZW1lbnRhdGlvbi4NCgkgICAgICAgDQoJ ICAgICAgICBCVFcsIGluIGNvbnRyYXN0IHRvIENPUywgQ29tbW9ucyBGaWxlVXBsb2FkIGRvZXNu J3QgcHJvdmlkZSBhIFNlcnZsZXQgMi4zIGZpbHRlciBhbnl3YXkuIFRoaXMgbWVhbnMgdGhhdCB0 aGVyZSB3b3VsZCBiZSBzb21lIGluZnJhc3RydWN0dXJlIGNvZGUgdG8gd3JpdGUgZm9yIHRoYXQg dXNlIGNhc2UgdG9vLCBldmVuIHdoZW4gdXNpbmcgc3RhbmRhcmQgZmlsdGVycy4gQSBzaW1wbGUg YnV0IGNvbnZlbmllbnQgU3ByaW5nIHNvbHV0aW9uIHdvdWxkIGRlZmluaXRlbHkgYmUgYSBnb29k IHRoaW5nLg0KCSAgICAgICANCgkgICAgICAgIEp1ZXJnZW4NCgkgICAgICAgDQoJICAgICAgIA0K CSAgICAgICANCgkgICAgICAgDQoJICAgICAgICAgICAgICAgIC0tLS0tVXJzcHLDvG5nbGljaGUg TmFjaHJpY2h0LS0tLS0NCgkgICAgICAgICAgICAgICAgVm9uOiBUcmV2b3IgQ29vayBbbWFpbHRv OnByaXNlMDNAc2VudGV4Lm5ldF0NCgkgICAgICAgICAgICAgICAgR2VzZW5kZXQ6IFNhIDI3LjA5 LjIwMDMgMTk6MzUNCgkgICAgICAgICAgICAgICAgQW46IFNwcmluZyBEZXZlbG9wZXJzDQoJICAg ICAgICAgICAgICAgIENjOg0KCSAgICAgICAgICAgICAgICBCZXRyZWZmOiBbW1czLVNQQU1dXSAt IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBNdWx0aXBhcnQgRmlsZSBIYW5kbGluZyAtIEVt YWlsIGZvdW5kIGluIHN1YmplY3QNCgkgICAgICAgICAgICAgIA0KCSAgICAgICAgICAgICAgDQoJ ICAgICAgIA0KCSAgICAgICAgICAgICAgICBGaXJzdCBzb21lIGhpc3Rvcnk6DQoJICAgICAgICAg ICAgICAgIGh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvbWFpbGFyY2hpdmUvbWVzc2FnZS5waHA/bXNn X2lkPTM4OTEyNzkNCgkgICAgICAgICAgICAgICAgaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9tYWls YXJjaGl2ZS9tZXNzYWdlLnBocD9tc2dfaWQ9NTE3NTI3Ng0KCSAgICAgICAgICAgICAgICBodHRw Oi8vc291cmNlZm9yZ2UubmV0L21haWxhcmNoaXZlL2ZvcnVtLnBocD90aHJlYWRfaWQ9MzEyNTU2 MSZmb3J1bV9pZD0zMDI4DQoJICAgICAgICAgICAgICAgIDcNCgkgICAgICAgICAgICAgICAgaHR0 cDovL3NvdXJjZWZvcmdlLm5ldC9tYWlsYXJjaGl2ZS9tZXNzYWdlLnBocD9tc2dfaWQ9NjA2MjI4 OA0KCSAgICAgICAgICAgICAgDQoJICAgICAgICAgICAgICAgIFRvIGFkZHJlc3MgYSBmZXcgdGhp bmdzIEp1ZXJnZW4gbWVudGlvbmVkIHByZXZpb3VzbHkuDQoJICAgICAgICAgICAgICANCgkgICAg ICAgICAgICAgICAgPj4gYSBsZXNzIGludHJ1c2l2ZSB3YXkgd291bGQgYmUgdG8gd3JhcCB0aGUg SHR0cFNlcnZsZXRSZXF1ZXN0IHZpYSBhIGZpbHRlcg0KCSAgICAgICAgICAgICAgICBJIHBlcnNv bmFsbHkgZG9uJ3QgbGlrZSB0aGUgZmlsdGVyIGFwcHJvYWNoLCBhdCBsZWFzdCBmb3IgdGhlIGZy YW1ld29yay4gIEl0DQoJICAgICAgICAgICAgICAgIHJlcXVpcmVzIGFkZGl0aW9uYWwgc2V0dXAg Zm9yIHRoZSB1c2VyIChpbiB0aGUgd2ViLnhtbCBmaWxlKSBhbmQgbWlnaHQgYmUNCgkgICAgICAg ICAgICAgICAgbGVzcyB1bmRlcnN0YW5kYWJsZSBzaW5jZSBvdXIgbm9ybWFsIHN0cmF0ZWd5IHNv IGZhciBoYXMgYmVlbiB3aXRoIHJlc29sdmVycw0KCSAgICAgICAgICAgICAgICBpbnNpZGUgdGhl IHNlcnZsZXQuDQoJICAgICAgICAgICAgICANCgkgICAgICAgICAgICAgICAgPj53ZSB3b3VsZCBu ZWVkIHRvIGZpbmQgY29uY3JldGUgcmVxdWlyZW1lbnRzIGZvciB0aGlzDQoJICAgICAgICAgICAg ICAgIFdlIGhhdmUgbnVtZXJvdXMgdXNlcyBmb3IgZmlsZSB1cGxvYWQgaGFuZGxpbmcuICBXZSBo YXZlIGEgcHVibGljIHBob3RvDQoJICAgICAgICAgICAgICAgIGNvbnRlc3Qgd2hlcmUgdXNlcnMg Y2FuIHVwbG9hZCBmb3Rvcy4gIFdlIGhhdmUgc3BlY2lhbCBhY2Nlc3MgZm9yIHN1cHBsaWVycw0K CSAgICAgICAgICAgICAgICB0byB1cGxvYWQgcHJvZHVjdCBmaWxlcyAoY3N2KSB3aGljaCB3ZSB0 aGVuIGFkZCBpbiB0byBvdXIgb3JkZXJpbmcgc3lzdGVtLg0KCSAgICAgICAgICAgICAgICBGaW5h bGx5LCB3ZSBoYXZlIGEgd2ViIGFkbWluaXN0cmF0aW9uIGludGVyZmFjZSB3aGljaCBhbGxvd3Mg b3VyIGNsaWVudCB0bw0KCSAgICAgICAgICAgICAgICB1cGxvYWQgZmlsZXMgdG8gdGhlIHdlYnNp dGUgc28gdGhleSBjYW4gYmUgZG93bmxvYWRlZC4gIEkgdGhpbmsgdGhhdA0KCSAgICAgICAgICAg ICAgICBpbmNsdWRpbmcgdGhpcyBzdXBwb3J0IChtdWx0aXBhcnQgaGFuZGxpbmcpIGlzIGEgbm8t YnJhaW5lci4NCgkgICAgICAgICAgICAgIA0KCSAgICAgICAgICAgICAgICBCYXNpY2FsbHksIEkg aGF2ZSB1c2VkIENPUyBleGNsdXNpdmVseSBpbiBvdXIgcHJvamVjdHMsIGJ1dCBJIGRvbid0IHRo aW5rDQoJICAgICAgICAgICAgICAgIHRoYXQncyBlYXN5IGZvciBTcHJpbmcgdG8gdXNlIChkdWUg dG8gdGhlIGxpY2Vuc2luZykuICBJIHdvdWxkIHNpbXBseSBjb2RlDQoJICAgICAgICAgICAgICAg IHRoaXMgYWNjb3JkaW5nIHRvIFNwcmluZyBub3JtcyB1c2luZyBhbiBpbnRlcmZhY2UgYW5kIGEg ZGVmYXVsdCB2ZXJzaW9uDQoJICAgICAgICAgICAgICAgIHVzaW5nIENvbW1vbnMgRmlsZVVwbG9h ZC4gIExhdGVyLCBpZiBzb21lYm9keSB3YW50cyB0byBjcmVhdGUgYSBjb3MgdmVyc2lvbg0KCSAg ICAgICAgICAgICAgICB3ZSBjYW4gKGJ1dCB0byBiZSBob25lc3QsIGlmIHdlIGhhdmUgYSB3b3Jr aW5nLCBpbnRlZ3JhdGVkIHNvbHV0aW9uIEknbSBub3QNCgkgICAgICAgICAgICAgICAgc3VyZSB0 aGF0IGlzIG5lY2Vzc2FyeSAtIGF0IGxlYXN0IG5vdCBpbiB0aGUgU3ByaW5nIGZyYW1ld29yayku ICBCYXNpY2FsbHksDQoJICAgICAgICAgICAgICAgIHByb3ZpZGUgaG9va3MgYW5kIGEgZGVmYXVs dCBpbXBsZW1lbnRhdGlvbiwgYW5kIGFsbG93IHVzZXJzIHRvIGFkb3B0IGFzDQoJICAgICAgICAg ICAgICAgIG5lY2Vzc2FyeS4NCgkgICAgICAgICAgICAgIA0KCSAgICAgICAgICAgICAgICBJbiBv dXIgcHJvamVjdCB3ZSBoYWQgbW9kaWZpZWQgdGhlIEFic3RyYWN0Q29udHJvbGxlciBhbmQgcHV0 IHRoZSBjb2RlIGludG8NCgkgICAgICAgICAgICAgICAgaXQgdG8gaGFuZGxlIHRoZSBtdWx0aXBh cnQgcHJvY2Vzc2luZywgcmV0dXJuaW5nIGEgd3JhcHBlZA0KCSAgICAgICAgICAgICAgICBIdHRw U2VydmxldFJlcXVlc3QgdGhyb3VnaCB0aGUgaGFuZGxlcnMuICBUaGlzIGlzIHZlcnkgc2ltaWxp YXIgdG8gSnVlcmdlbidzDQoJICAgICAgICAgICAgICAgIG91dGxpbmUgKGh0dHA6Ly9zb3VyY2Vm b3JnZS5uZXQvbWFpbGFyY2hpdmUvbWVzc2FnZS5waHA/bXNnX2lkPTM4OTEyNzkpLg0KCSAgICAg ICAgICAgICAgDQoJICAgICAgICAgICAgICAgIFNpbmNlIHdlIGFyZSBtaWdyYXRpbmcgdG8gdGhl IGN1cnJlbnQgU3ByaW5nIGNvZGViYXNlLCBJIG5lZWQgdG8gbW92ZSBvdXINCgkgICAgICAgICAg ICAgICAgbXVsdGlwYXJ0IGhhbmRsaW5nIGNvZGUuICBUaGUgbWFpbiBxdWVzdGlvbiBpcyB3aGV0 aGVyIHdlIGtlZXAgaXQNCgkgICAgICAgICAgICAgICAgaW50ZXJuYWxseSwgb3IgcGxhY2UgaXQg aW50byBTcHJpbmcuICBJIHByb3Bvc2UgbW9kaWZ5aW5nDQoJICAgICAgICAgICAgICAgIG9yZy5z cHJpbmdmcmFtZXdvcmsud2ViLnNlcnZsZXQuRGlzcGF0Y2hlclNlcnZsZXQgdG8gaGF2ZSBhDQoJ ICAgICAgICAgICAgICAgICJNdWx0aXBhcnRSZXNvbHZlciIuICBJbiB0aGUgRGlzcGF0Y2hlclNl cnZsZXQsIHRoZSByZXNvbHZlciB3b3VsZCBiZSBjYWxsZWQNCgkgICAgICAgICAgICAgICAgdG8g d3JhcCB0aGUgcmVxdWVzdCBpbiBkb1NlcnZpY2UgaW1tZWRpYXRlbHkgYmVmb3JlIGdldEhhbmRs ZXIocmVxdWVzdCkgLQ0KCSAgICAgICAgICAgICAgICBjdXJyZW50bHkgbGluZSAzNTEsIGFuZCB0 aGVuIGNhbGxlZCB0byBkbyBhbnkgY2xlYW51cCBpbW1lZGlhdGVseSBiZWZvcmUNCgkgICAgICAg ICAgICAgICAgZXhpdGluZyB0aGUgZG9TZXJ2aWNlIG1ldGhvZC4NCgkgICAgICAgICAgICAgIA0K CSAgICAgICAgICAgICAgICBJIGhhdmUgYWJvdXQgMi8zIG9mIHRoZSBjb2RlIGFscmVhZHkgd3Jp dHRlbiwgYW5kIEkgd2lsbCBiZSB3cml0aW5nIHRoZSByZXN0DQoJICAgICAgICAgICAgICAgIGJl dHdlZW4gbm93IGFuZCBNb25kYXkuICBEb2VzIHRoaXMgc3RyYXRlZ3kgc291bmQgYXBwcm9wcmlh dGUgZm9yIFNwcmluZw0KCSAgICAgICAgICAgICAgICAobWVhbmluZyBzaG91bGQgSSBjb21taXQg aXQgdG8gdGhlIFNwcmluZyBjb2RlYmFzZSkgd2hlbiBpdCdzIGZpbmlzaGVkPw0KCSAgICAgICAg ICAgICAgDQoJICAgICAgICAgICAgICAgIFRyZXZvciBELiBDb29rDQoJICAgICAgICAgICAgICAg IEludGVycHJpc2UgU29mdHdhcmUNCgkgICAgICAgICAgICAgIA0KCSAgICAgICAgICAgICAgDQoJ ICAgICAgICAgICAgICANCgkgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCSAgICAgICAgICAgICAgICBUaGlzIHNm Lm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6VGhpbmtHZWVrDQoJICAgICAgICAgICAgICAgIFdl bGNvbWUgdG8gZ2VlayBoZWF2ZW4uDQoJICAgICAgICAgICAgICAgIGh0dHA6Ly90aGlua2dlZWsu Y29tL3NmDQoJICAgICAgICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoJICAgICAgICAgICAgICAgIFNwcmluZ2ZyYW1ld29yay1kZXZlbG9w ZXIgbWFpbGluZyBsaXN0DQoJICAgICAgICAgICAgICAgIFNwcmluZ2ZyYW1ld29yay1kZXZlbG9w ZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJICAgICAgICAgICAgICAgIGh0dHBzOi8vbGlzdHMu c291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIN CgkgICAgICAgICAgICAgIA0KCSAgICAgICANCgkgICAgICAgIE4YIFh1KRlZIGcgFyAgSHpHSiBq Z+6iuXrtvYntt5l4y6YgRyDLsnEgeiBtP1ggKB5+encgWCBiy50/ICBqZ+uwoh167b2W7bKXDQoJ ICAgICAgIA0KCSAgICAgICANCgkNCglOGCDpmopYJ3XevCkZIFlcZ+mirSAXIH8gYtieSB56Rygf SiAgamfrsKIdeu29lu2yl3glUsumIChHXuyuvWggIGxxICB6bdi2P1ggKB5+encgWCBiy50/ICBq Z+uwoh167b2W7bKXDQoJDQoJDQoNCg== |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-09-28 14:25:29
|
The conversion interface might indeed not be the perfect solution. A =
byte[] check is fine and fits the needs perfectly!
Alef
-----Oorspronkelijk bericht-----
Van: j=C3=BCrgen h=C3=B6ller [werk3AT] =
[mailto:jue...@we...]=20
Verzonden: Sunday, September 28, 2003 4:20 PM
Aan: al...@jt...; Trevor Cook; Spring Developers
Onderwerp: Re: [Springframework-developer] Multipart File Handling
Alef,
=20
I'm not keen on introducing yet another converter interface, especially =
as there's hardly any variation possible in terms of file upload =
handling. I agree though that having MultipartFile in the object model =
isn't desirable.
=20
What about writing the automatic check in ServletRequestDataBinder so =
that it assumes a byte[] for the uploaded file? I can't think of any =
other generic type suitable for uploaded files. java.io.File is no =
candidate as we would need to determine a path to save the file to. I =
consider such persisting the responsibility of the application code =
itself, especially as the uploaded stuff will often be stored to a =
relational database.
=20
For anything else than byte[] as property type in a command object, even =
MultipartFile if desired, one can always override onBindAndValidate and =
perform manual binding. Would that be powerful enough for your use =
cases?
=20
Juergen
=20
=20
-----Urspr=C3=BCngliche Nachricht-----=20
Von: Alef Arendsen (JTeam) [mailto:al...@jt...]=20
Gesendet: So 28.09.2003 15:31=20
An: j=C3=BCrgen h=C3=B6ller [werk3AT]; 'Trevor Cook'; 'Spring =
Developers'=20
Cc:=20
Betreff: RE: [Springframework-developer] Multipart File Handling
=09
=09
In one of my previous mails I mentioned doing something like that. It =
involved base64 encoding the byte[] to a String, after which the =
propertyeditor picked it up, decoded it again into a byte[] and set it =
on the object! Arghhh.... (as in wow that's ugly ;-).
=09
I did this, because I rely completely on the mvc framework and 1) did =
not want to put in some MultiPart object in my object model, I just =
wanted a byte[] and 2) just didn't want to make compromises simply =
because of propertyeditors being only capable of handling Strings. Ok, =
the solution is nasty and definitely not up for adding, but I really =
think it should worked in such way that things stay consistent while on =
the other hand, not forcing a user at all to modify stuff in it's =
datamodel... May sound a bit harsh, sorry for that ;-)
=09
Would it be possible to define a simple Spring-proprietary conversion =
interface/class which users can implement themselves capable of =
transforming multpartfile object (or whatever other type) to objects =
defined in a user's datamodel. Something like the following.
=09
class FileUploadConvertor {
public Object convert(MultiPartFile);
}
=09
Just some thoughts...
=09
Alef
=09
=09
-----Oorspronkelijk bericht-----
Van: spr...@li... =
[mailto:spr...@li...] Namens =
j=C3=BCrgen h=C3=B6ller [werk3AT]
Verzonden: Sunday, September 28, 2003 2:31 PM
Aan: al...@jt...; Trevor Cook; Spring Developers
Onderwerp: Re: [Springframework-developer] Multipart File Handling
=09
=09
Hi Alef,
=09
A PropertyEditor will always start with a String and convert it to some =
other type, in the web case applied to ServletRequest's getParameter =
values. Here we got MultipartFile instances, retrievable via =
MultipartServletRequest's getFile(String name) method: no Strings in the =
first place, thus the PropertyEditor mechanism is not applicable.
=09
We could possibly add a special check to ServletRequestDataBinder, =
binding MultipartFile instances to respective command bean fields of the =
same type in the case of a multipart request. That would work with any =
MultipartResolver implementation, as it could use the same API as manual =
file upload handling code that casts to MultipartServletRequest.
=09
Definitely a feature worth considering!
=09
Juergen
=09
=09
=09
-----Urspr=C3=BCngliche Nachricht-----
Von: Alef Arendsen (JTeam) [mailto:al...@jt...]
Gesendet: So 28.09.2003 14:04
An: j=C3=BCrgen h=C3=B6ller [werk3AT]; 'Trevor Cook'; 'Spring =
Developers'
Cc:
Betreff: RE: [Springframework-developer] Multipart File =
Handling
=20
=20
=09
Will there be a way - using this solution - to bind the file =
using a propertyeditor (or something else maybe), just as any other =
command object is filled with parameters from the request. For =
consistency, I think that's pretty important to be consistent.
=20
Furthermore I think it's pretty cool if the fileupload could be =
fixed before the 1.0 release! Good thing!
=20
Alef
=20
=20
-----Oorspronkelijk bericht-----
Van: spr...@li... =
[mailto:spr...@li...] Namens =
j=C3=BCrgen h=C3=B6ller [werk3AT]
Verzonden: Sunday, September 28, 2003 12:33 PM
Aan: Trevor Cook; Spring Developers
Onderwerp: Re: [Springframework-developer] Multipart File =
Handling
=20
=20
Hi Trevor,
=20
A MultipartResolver interface with implementations for Commons =
FileUpload and COS is fine with me - it just hadn't high priority since =
I proposed it half a year ago. As I still have a pretty clear picture of =
the issues, I'll be happy to review your code once you've checked it in. =
As this should be pretty straightforward, let's try to include this =
already in 1.0 M2 - at least with a Commons FileUpload implementation.
=20
BTW, in contrast to COS, Commons FileUpload doesn't provide a =
Servlet 2.3 filter anyway. This means that there would be some =
infrastructure code to write for that use case too, even when using =
standard filters. A simple but convenient Spring solution would =
definitely be a good thing.
=20
Juergen
=20
=20
=20
=20
-----Urspr=C3=BCngliche Nachricht-----
Von: Trevor Cook [mailto:pr...@se...]
Gesendet: Sa 27.09.2003 19:35
An: Spring Developers
Cc:
Betreff: [[W3-SPAM]] - [Springframework-developer] =
Multipart File Handling - Email found in subject
=20
=20
=20
First some history:
=
http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279
=
http://sourceforge.net/mailarchive/message.php?msg_id=3D5175276
=
http://sourceforge.net/mailarchive/forum.php?thread_id=3D3125561&forum_id=
=3D3028
7
=
http://sourceforge.net/mailarchive/message.php?msg_id=3D6062288
=20
To address a few things Juergen mentioned previously.
=20
>> a less intrusive way would be to wrap the =
HttpServletRequest via a filter
I personally don't like the filter approach, at least =
for the framework. It
requires additional setup for the user (in the web.xml =
file) and might be
less understandable since our normal strategy so far =
has been with resolvers
inside the servlet.
=20
>>we would need to find concrete requirements for this
We have numerous uses for file upload handling. We =
have a public photo
contest where users can upload fotos. We have special =
access for suppliers
to upload product files (csv) which we then add in to =
our ordering system.
Finally, we have a web administration interface which =
allows our client to
upload files to the website so they can be downloaded. =
I think that
including this support (multipart handling) is a =
no-brainer.
=20
Basically, I have used COS exclusively in our projects, =
but I don't think
that's easy for Spring to use (due to the licensing). =
I would simply code
this according to Spring norms using an interface and a =
default version
using Commons FileUpload. Later, if somebody wants to =
create a cos version
we can (but to be honest, if we have a working, =
integrated solution I'm not
sure that is necessary - at least not in the Spring =
framework). Basically,
provide hooks and a default implementation, and allow =
users to adopt as
necessary.
=20
In our project we had modified the AbstractController =
and put the code into
it to handle the multipart processing, returning a =
wrapped
HttpServletRequest through the handlers. This is very =
similiar to Juergen's
outline =
(http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279).
=20
Since we are migrating to the current Spring codebase, =
I need to move our
multipart handling code. The main question is whether =
we keep it
internally, or place it into Spring. I propose =
modifying
org.springframework.web.servlet.DispatcherServlet to =
have a
"MultipartResolver". In the DispatcherServlet, the =
resolver would be called
to wrap the request in doService immediately before =
getHandler(request) -
currently line 351, and then called to do any cleanup =
immediately before
exiting the doService method.
=20
I have about 2/3 of the code already written, and I =
will be writing the rest
between now and Monday. Does this strategy sound =
appropriate for Spring
(meaning should I commit it to the Spring codebase) =
when it's finished?
=20
Trevor D. Cook
Interprise Software
=20
=20
=20
-------------------------------------------------------
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
=20
=20
N=18 Xu)=19Y g =17 HzGJ jg=EE=A2=B9z=ED=BD=89=ED=B7=99x=CB=A6 =
G =CB=B2q z m?X (=1E~zw X b=CB=9D? jg=EB=B0=A2=1Dz=ED=BD=96=ED=B2=97
=20
=20
=09
N=18 =E9=9A=8AX'u=DE=BC)=19 Y\g=E9=A2=AD =17 =7F b=D8=9EH=1EzG(=1FJ =
jg=EB=B0=A2=1Dz=ED=BD=96=ED=B2=97x%R=CB=A6 (G^=EC=AE=BDh lq zm=D8=B6?X =
(=1E~zw X b=CB=9D? jg=EB=B0=A2=1Dz=ED=BD=96=ED=B2=97
=09
=09
|
|
From: Trevor C. <pr...@se...> - 2003-09-28 14:47:32
|
I think byte[] should work in most cases, and is simple enough to do. =
However, it does not provide certain features necessary if you are using =
"File" objects (such as size, etc.), and I don't think anyone want's the =
MultipartFile in their form beans.
I have some ideas floating around on how to handle this, but they're =
still a little fuzzy. Some code/test cycles should figure them out. =
I'll be working on it this afternoon, so I'll send out more info once I =
have some concrete suggestions.
Trevor
-----Original Message-----
From: j=C3=BCrgen h=C3=B6ller [werk3AT] =
[mailto:jue...@we...]
Sent: September 28, 2003 10:20 AM
To: al...@jt...; Trevor Cook; Spring Developers
Subject: Re: [Springframework-developer] Multipart File Handling
Alef,
=20
I'm not keen on introducing yet another converter interface, especially =
as there's hardly any variation possible in terms of file upload =
handling. I agree though that having MultipartFile in the object model =
isn't desirable.
=20
What about writing the automatic check in ServletRequestDataBinder so =
that it assumes a byte[] for the uploaded file? I can't think of any =
other generic type suitable for uploaded files. java.io.File is no =
candidate as we would need to determine a path to save the file to. I =
consider such persisting the responsibility of the application code =
itself, especially as the uploaded stuff will often be stored to a =
relational database.
=20
For anything else than byte[] as property type in a command object, even =
MultipartFile if desired, one can always override onBindAndValidate and =
perform manual binding. Would that be powerful enough for your use =
cases?
=20
Juergen
=20
=20
-----Ursprngliche Nachricht-----=20
Von: Alef Arendsen (JTeam) [mailto:al...@jt...]=20
Gesendet: So 28.09.2003 15:31=20
An: j rgen hller [werk3AT]; 'Trevor Cook'; 'Spring Developers'=20
Cc:=20
Betreff: RE: [Springframework-developer] Multipart File Handling
=09
=09
In one of my previous mails I mentioned doing something like that. It =
involved base64 encoding the byte[] to a String, after which the =
propertyeditor picked it up, decoded it again into a byte[] and set it =
on the object! Arghhh.... (as in wow that's ugly ;-).
=09
I did this, because I rely completely on the mvc framework and 1) did =
not want to put in some MultiPart object in my object model, I just =
wanted a byte[] and 2) just didn't want to make compromises simply =
because of propertyeditors being only capable of handling Strings. Ok, =
the solution is nasty and definitely not up for adding, but I really =
think it should worked in such way that things stay consistent while on =
the other hand, not forcing a user at all to modify stuff in it's =
datamodel... May sound a bit harsh, sorry for that ;-)
=09
Would it be possible to define a simple Spring-proprietary conversion =
interface/class which users can implement themselves capable of =
transforming multpartfile object (or whatever other type) to objects =
defined in a user's datamodel. Something like the following.
=09
class FileUploadConvertor {
public Object convert(MultiPartFile);
}
=09
Just some thoughts...
=09
Alef
=09
=09
-----Oorspronkelijk bericht-----
Van: spr...@li... =
[mailto:spr...@li...] Namens j =
rgen hller [werk3AT]
Verzonden: Sunday, September 28, 2003 2:31 PM
Aan: al...@jt...; Trevor Cook; Spring Developers
Onderwerp: Re: [Springframework-developer] Multipart File Handling
=09
=09
Hi Alef,
=09
A PropertyEditor will always start with a String and convert it to some =
other type, in the web case applied to ServletRequest's getParameter =
values. Here we got MultipartFile instances, retrievable via =
MultipartServletRequest's getFile(String name) method: no Strings in the =
first place, thus the PropertyEditor mechanism is not applicable.
=09
We could possibly add a special check to ServletRequestDataBinder, =
binding MultipartFile instances to respective command bean fields of the =
same type in the case of a multipart request. That would work with any =
MultipartResolver implementation, as it could use the same API as manual =
file upload handling code that casts to MultipartServletRequest.
=09
Definitely a feature worth considering!
=09
Juergen
=09
=09
=09
-----Urspr ngliche Nachricht-----
Von: Alef Arendsen (JTeam) [mailto:al...@jt...]
Gesendet: So 28.09.2003 14:04
An: jrgen h ller [werk3AT]; 'Trevor Cook'; 'Spring Developers'
Cc:
Betreff: RE: [Springframework-developer] Multipart File =
Handling
=20
=20
=09
Will there be a way - using this solution - to bind the file =
using a propertyeditor (or something else maybe), just as any other =
command object is filled with parameters from the request. For =
consistency, I think that's pretty important to be consistent.
=20
Furthermore I think it's pretty cool if the fileupload could be =
fixed before the 1.0 release! Good thing!
=20
Alef
=20
=20
-----Oorspronkelijk bericht-----
Van: spr...@li... =
[mailto:spr...@li...] Namens =
jrgen h ller [werk3AT]
Verzonden: Sunday, September 28, 2003 12:33 PM
Aan: Trevor Cook; Spring Developers
Onderwerp: Re: [Springframework-developer] Multipart File =
Handling
=20
=20
Hi Trevor,
=20
A MultipartResolver interface with implementations for Commons =
FileUpload and COS is fine with me - it just hadn't high priority since =
I proposed it half a year ago. As I still have a pretty clear picture of =
the issues, I'll be happy to review your code once you've checked it in. =
As this should be pretty straightforward, let's try to include this =
already in 1.0 M2 - at least with a Commons FileUpload implementation.
=20
BTW, in contrast to COS, Commons FileUpload doesn't provide a =
Servlet 2.3 filter anyway. This means that there would be some =
infrastructure code to write for that use case too, even when using =
standard filters. A simple but convenient Spring solution would =
definitely be a good thing.
=20
Juergen
=20
=20
=20
=20
-----Ursprngliche Nachricht-----
Von: Trevor Cook [mailto:pr...@se...]
Gesendet: Sa 27.09.2003 19:35
An: Spring Developers
Cc:
Betreff: [[W3-SPAM]] - [Springframework-developer] =
Multipart File Handling - Email found in subject
=20
=20
=20
First some history:
=
http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279
=
http://sourceforge.net/mailarchive/message.php?msg_id=3D5175276
=
http://sourceforge.net/mailarchive/forum.php?thread_id=3D3125561&forum_id=
=3D3028
7
=
http://sourceforge.net/mailarchive/message.php?msg_id=3D6062288
=20
To address a few things Juergen mentioned previously.
=20
>> a less intrusive way would be to wrap the =
HttpServletRequest via a filter
I personally don't like the filter approach, at least =
for the framework. It
requires additional setup for the user (in the web.xml =
file) and might be
less understandable since our normal strategy so far =
has been with resolvers
inside the servlet.
=20
>>we would need to find concrete requirements for this
We have numerous uses for file upload handling. We =
have a public photo
contest where users can upload fotos. We have special =
access for suppliers
to upload product files (csv) which we then add in to =
our ordering system.
Finally, we have a web administration interface which =
allows our client to
upload files to the website so they can be downloaded. =
I think that
including this support (multipart handling) is a =
no-brainer.
=20
Basically, I have used COS exclusively in our projects, =
but I don't think
that's easy for Spring to use (due to the licensing). =
I would simply code
this according to Spring norms using an interface and a =
default version
using Commons FileUpload. Later, if somebody wants to =
create a cos version
we can (but to be honest, if we have a working, =
integrated solution I'm not
sure that is necessary - at least not in the Spring =
framework). Basically,
provide hooks and a default implementation, and allow =
users to adopt as
necessary.
=20
In our project we had modified the AbstractController =
and put the code into
it to handle the multipart processing, returning a =
wrapped
HttpServletRequest through the handlers. This is very =
similiar to Juergen's
outline =
(http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279).
=20
Since we are migrating to the current Spring codebase, =
I need to move our
multipart handling code. The main question is whether =
we keep it
internally, or place it into Spring. I propose =
modifying
org.springframework.web.servlet.DispatcherServlet to =
have a
"MultipartResolver". In the DispatcherServlet, the =
resolver would be called
to wrap the request in doService immediately before =
getHandler(request) -
currently line 351, and then called to do any cleanup =
immediately before
exiting the doService method.
=20
I have about 2/3 of the code already written, and I =
will be writing the rest
between now and Monday. Does this strategy sound =
appropriate for Spring
(meaning should I commit it to the Spring codebase) =
when it's finished?
=20
Trevor D. Cook
Interprise Software
=20
=20
=20
-------------------------------------------------------
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
=20
=20
N=18 Xu)=19Y g =17 HzGJ jg?z??x? G ?q z m?X (=1E~zw X b?? =
jg?=1Dz??
=20
=20
=09
N=18 ?X'u?)=19 Y\g? =17 =7F b?H=1EzG(=1FJ jg?=1Dz??x%R? (G^?h lq =
zm??X (=1E~zw X b?? jg?=1Dz??
=09
=09
|
|
From: Colin S. <col...@ex...> - 2003-09-28 19:50:09
|
I'm sort of clued-out here (not knowing most of the context), but can
you guys clarify that this will still be able to handle file uploads
where the entier file doesn't have to reside entirely in memory? I
consider this critical for scalability and being able to handle DOS
attacks...
Regards,
Colin
Trevor Cook wrote:
>I think byte[] should work in most cases, and is simple enough to do. However, it does not provide certain features necessary if you are using "File" objects (such as size, etc.), and I don't think anyone want's the MultipartFile in their form beans.
>
>I have some ideas floating around on how to handle this, but they're still a little fuzzy. Some code/test cycles should figure them out. I'll be working on it this afternoon, so I'll send out more info once I have some concrete suggestions.
>
>Trevor
>
>
>-----Original Message-----
>From: jürgen höller [werk3AT] [mailto:jue...@we...]
>Sent: September 28, 2003 10:20 AM
>To: al...@jt...; Trevor Cook; Spring Developers
>Subject: Re: [Springframework-developer] Multipart File Handling
>
>
>Alef,
>
>I'm not keen on introducing yet another converter interface, especially as there's hardly any variation possible in terms of file upload handling. I agree though that having MultipartFile in the object model isn't desirable.
>
>What about writing the automatic check in ServletRequestDataBinder so that it assumes a byte[] for the uploaded file? I can't think of any other generic type suitable for uploaded files. java.io.File is no candidate as we would need to determine a path to save the file to. I consider such persisting the responsibility of the application code itself, especially as the uploaded stuff will often be stored to a relational database.
>
>For anything else than byte[] as property type in a command object, even MultipartFile if desired, one can always override onBindAndValidate and perform manual binding. Would that be powerful enough for your use cases?
>
>Juergen
>
>
>
> -----Ursprngliche Nachricht-----
> Von: Alef Arendsen (JTeam) [mailto:al...@jt...]
> Gesendet: So 28.09.2003 15:31
> An: j rgen hller [werk3AT]; 'Trevor Cook'; 'Spring Developers'
> Cc:
> Betreff: RE: [Springframework-developer] Multipart File Handling
>
>
>
> In one of my previous mails I mentioned doing something like that. It involved base64 encoding the byte[] to a String, after which the propertyeditor picked it up, decoded it again into a byte[] and set it on the object! Arghhh.... (as in wow that's ugly ;-).
>
> I did this, because I rely completely on the mvc framework and 1) did not want to put in some MultiPart object in my object model, I just wanted a byte[] and 2) just didn't want to make compromises simply because of propertyeditors being only capable of handling Strings. Ok, the solution is nasty and definitely not up for adding, but I really think it should worked in such way that things stay consistent while on the other hand, not forcing a user at all to modify stuff in it's datamodel... May sound a bit harsh, sorry for that ;-)
>
> Would it be possible to define a simple Spring-proprietary conversion interface/class which users can implement themselves capable of transforming multpartfile object (or whatever other type) to objects defined in a user's datamodel. Something like the following.
>
> class FileUploadConvertor {
> public Object convert(MultiPartFile);
> }
>
> Just some thoughts...
>
> Alef
>
>
> -----Oorspronkelijk bericht-----
> Van: spr...@li... [mailto:spr...@li...] Namens j rgen hller [werk3AT]
> Verzonden: Sunday, September 28, 2003 2:31 PM
> Aan: al...@jt...; Trevor Cook; Spring Developers
> Onderwerp: Re: [Springframework-developer] Multipart File Handling
>
>
> Hi Alef,
>
> A PropertyEditor will always start with a String and convert it to some other type, in the web case applied to ServletRequest's getParameter values. Here we got MultipartFile instances, retrievable via MultipartServletRequest's getFile(String name) method: no Strings in the first place, thus the PropertyEditor mechanism is not applicable.
>
> We could possibly add a special check to ServletRequestDataBinder, binding MultipartFile instances to respective command bean fields of the same type in the case of a multipart request. That would work with any MultipartResolver implementation, as it could use the same API as manual file upload handling code that casts to MultipartServletRequest.
>
> Definitely a feature worth considering!
>
> Juergen
>
>
>
> -----Urspr ngliche Nachricht-----
> Von: Alef Arendsen (JTeam) [mailto:al...@jt...]
> Gesendet: So 28.09.2003 14:04
> An: jrgen h ller [werk3AT]; 'Trevor Cook'; 'Spring Developers'
> Cc:
> Betreff: RE: [Springframework-developer] Multipart File Handling
>
>
>
> Will there be a way - using this solution - to bind the file using a propertyeditor (or something else maybe), just as any other command object is filled with parameters from the request. For consistency, I think that's pretty important to be consistent.
>
> Furthermore I think it's pretty cool if the fileupload could be fixed before the 1.0 release! Good thing!
>
> Alef
>
>
> -----Oorspronkelijk bericht-----
> Van: spr...@li... [mailto:spr...@li...] Namens jrgen h ller [werk3AT]
> Verzonden: Sunday, September 28, 2003 12:33 PM
> Aan: Trevor Cook; Spring Developers
> Onderwerp: Re: [Springframework-developer] Multipart File Handling
>
>
> Hi Trevor,
>
> A MultipartResolver interface with implementations for Commons FileUpload and COS is fine with me - it just hadn't high priority since I proposed it half a year ago. As I still have a pretty clear picture of the issues, I'll be happy to review your code once you've checked it in. As this should be pretty straightforward, let's try to include this already in 1.0 M2 - at least with a Commons FileUpload implementation.
>
> BTW, in contrast to COS, Commons FileUpload doesn't provide a Servlet 2.3 filter anyway. This means that there would be some infrastructure code to write for that use case too, even when using standard filters. A simple but convenient Spring solution would definitely be a good thing.
>
> Juergen
>
>
>
>
> -----Ursprngliche Nachricht-----
> Von: Trevor Cook [mailto:pr...@se...]
> Gesendet: Sa 27.09.2003 19:35
> An: Spring Developers
> Cc:
> Betreff: [[W3-SPAM]] - [Springframework-developer] Multipart File Handling - Email found in subject
>
>
>
> First some history:
> http://sourceforge.net/mailarchive/message.php?msg_id=3891279
> http://sourceforge.net/mailarchive/message.php?msg_id=5175276
> http://sourceforge.net/mailarchive/forum.php?thread_id=3125561&forum_id=3028
> 7
> http://sourceforge.net/mailarchive/message.php?msg_id=6062288
>
> To address a few things Juergen mentioned previously.
>
> >> a less intrusive way would be to wrap the HttpServletRequest via a filter
> I personally don't like the filter approach, at least for the framework. It
> requires additional setup for the user (in the web.xml file) and might be
> less understandable since our normal strategy so far has been with resolvers
> inside the servlet.
>
> >>we would need to find concrete requirements for this
> We have numerous uses for file upload handling. We have a public photo
> contest where users can upload fotos. We have special access for suppliers
> to upload product files (csv) which we then add in to our ordering system.
> Finally, we have a web administration interface which allows our client to
> upload files to the website so they can be downloaded. I think that
> including this support (multipart handling) is a no-brainer.
>
> Basically, I have used COS exclusively in our projects, but I don't think
> that's easy for Spring to use (due to the licensing). I would simply code
> this according to Spring norms using an interface and a default version
> using Commons FileUpload. Later, if somebody wants to create a cos version
> we can (but to be honest, if we have a working, integrated solution I'm not
> sure that is necessary - at least not in the Spring framework). Basically,
> provide hooks and a default implementation, and allow users to adopt as
> necessary.
>
> In our project we had modified the AbstractController and put the code into
> it to handle the multipart processing, returning a wrapped
> HttpServletRequest through the handlers. This is very similiar to Juergen's
> outline (http://sourceforge.net/mailarchive/message.php?msg_id=3891279).
>
> Since we are migrating to the current Spring codebase, I need to move our
> multipart handling code. The main question is whether we keep it
> internally, or place it into Spring. I propose modifying
> org.springframework.web.servlet.DispatcherServlet to have a
> "MultipartResolver". In the DispatcherServlet, the resolver would be called
> to wrap the request in doService immediately before getHandler(request) -
> currently line 351, and then called to do any cleanup immediately before
> exiting the doService method.
>
> I have about 2/3 of the code already written, and I will be writing the rest
> between now and Monday. Does this strategy sound appropriate for Spring
> (meaning should I commit it to the Spring codebase) when it's finished?
>
> Trevor D. Cook
> Interprise Software
>
>
|
|
From: Trevor C. <pr...@se...> - 2003-09-28 20:10:15
|
You will have complete control over how this is handled. With the =
default implementation (which is using commons fileupload) you can =
specify the maximum amount to store in memory, and the maximum to write =
to the file (which is the fallback method). Basically, by setting =
in-memory low (or to 0), you can avoid using it. With COS (which we =
will add support for later), there is no in-memory support currently. =
However configuration options for various "MultipartResolver"'s will =
obviously be different.
As far as a DOS/DDOS attack goes, I'm not sure how much this buys you =
though. But the configuration options will be there.
Trevor
-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...]
Sent: September 28, 2003 3:49 PM
To: Trevor Cook
Cc: j=C3=BCrgen h=C3=B6ller [werk3AT]; al...@jt...; Spring Developers
Subject: Re: [Springframework-developer] Multipart File Handling
I'm sort of clued-out here (not knowing most of the context), but can=20
you guys clarify that this will still be able to handle file uploads=20
where the entier file doesn't have to reside entirely in memory? I=20
consider this critical for scalability and being able to handle DOS=20
attacks...
Regards,
Colin
Trevor Cook wrote:
>I think byte[] should work in most cases, and is simple enough to do. =
However, it does not provide certain features necessary if you are using =
"File" objects (such as size, etc.), and I don't think anyone want's the =
MultipartFile in their form beans.
>
>I have some ideas floating around on how to handle this, but they're =
still a little fuzzy. Some code/test cycles should figure them out. =
I'll be working on it this afternoon, so I'll send out more info once I =
have some concrete suggestions.
>
>Trevor
>
>
>-----Original Message-----
>From: j=C3=BCrgen h=C3=B6ller [werk3AT] =
[mailto:jue...@we...]
>Sent: September 28, 2003 10:20 AM
>To: al...@jt...; Trevor Cook; Spring Developers
>Subject: Re: [Springframework-developer] Multipart File Handling
>
>
>Alef,
>=20
>I'm not keen on introducing yet another converter interface, especially =
as there's hardly any variation possible in terms of file upload =
handling. I agree though that having MultipartFile in the object model =
isn't desirable.
>=20
>What about writing the automatic check in ServletRequestDataBinder so =
that it assumes a byte[] for the uploaded file? I can't think of any =
other generic type suitable for uploaded files. java.io.File is no =
candidate as we would need to determine a path to save the file to. I =
consider such persisting the responsibility of the application code =
itself, especially as the uploaded stuff will often be stored to a =
relational database.
>=20
>For anything else than byte[] as property type in a command object, =
even MultipartFile if desired, one can always override onBindAndValidate =
and perform manual binding. Would that be powerful enough for your use =
cases?
>=20
>Juergen
>=20
>=20
>
> -----Ursprngliche Nachricht-----=20
> Von: Alef Arendsen (JTeam) [mailto:al...@jt...]=20
> Gesendet: So 28.09.2003 15:31=20
> An: j rgen hller [werk3AT]; 'Trevor Cook'; 'Spring Developers'=20
> Cc:=20
> Betreff: RE: [Springframework-developer] Multipart File Handling
>=09
>=09
>
> In one of my previous mails I mentioned doing something like that. It =
involved base64 encoding the byte[] to a String, after which the =
propertyeditor picked it up, decoded it again into a byte[] and set it =
on the object! Arghhh.... (as in wow that's ugly ;-).
>=09
> I did this, because I rely completely on the mvc framework and 1) did =
not want to put in some MultiPart object in my object model, I just =
wanted a byte[] and 2) just didn't want to make compromises simply =
because of propertyeditors being only capable of handling Strings. Ok, =
the solution is nasty and definitely not up for adding, but I really =
think it should worked in such way that things stay consistent while on =
the other hand, not forcing a user at all to modify stuff in it's =
datamodel... May sound a bit harsh, sorry for that ;-)
>=09
> Would it be possible to define a simple Spring-proprietary conversion =
interface/class which users can implement themselves capable of =
transforming multpartfile object (or whatever other type) to objects =
defined in a user's datamodel. Something like the following.
>=09
> class FileUploadConvertor {
> public Object convert(MultiPartFile);
> }
>=09
> Just some thoughts...
>=09
> Alef
>=09
>=09
> -----Oorspronkelijk bericht-----
> Van: spr...@li... =
[mailto:spr...@li...] Namens j =
rgen hller [werk3AT]
> Verzonden: Sunday, September 28, 2003 2:31 PM
> Aan: al...@jt...; Trevor Cook; Spring Developers
> Onderwerp: Re: [Springframework-developer] Multipart File Handling
>=09
>=09
> Hi Alef,
>=09
> A PropertyEditor will always start with a String and convert it to =
some other type, in the web case applied to ServletRequest's =
getParameter values. Here we got MultipartFile instances, retrievable =
via MultipartServletRequest's getFile(String name) method: no Strings in =
the first place, thus the PropertyEditor mechanism is not applicable.
>=09
> We could possibly add a special check to ServletRequestDataBinder, =
binding MultipartFile instances to respective command bean fields of the =
same type in the case of a multipart request. That would work with any =
MultipartResolver implementation, as it could use the same API as manual =
file upload handling code that casts to MultipartServletRequest.
>=09
> Definitely a feature worth considering!
>=09
> Juergen
>=09
>=09
>=09
> -----Urspr ngliche Nachricht-----
> Von: Alef Arendsen (JTeam) [mailto:al...@jt...]
> Gesendet: So 28.09.2003 14:04
> An: jrgen h ller [werk3AT]; 'Trevor Cook'; 'Spring Developers'
> Cc:
> Betreff: RE: [Springframework-developer] Multipart File =
Handling
> =20
> =20
>=09
> Will there be a way - using this solution - to bind the file =
using a propertyeditor (or something else maybe), just as any other =
command object is filled with parameters from the request. For =
consistency, I think that's pretty important to be consistent.
> =20
> Furthermore I think it's pretty cool if the fileupload could =
be fixed before the 1.0 release! Good thing!
> =20
> Alef
> =20
> =20
> -----Oorspronkelijk bericht-----
> Van: spr...@li... =
[mailto:spr...@li...] Namens =
jrgen h ller [werk3AT]
> Verzonden: Sunday, September 28, 2003 12:33 PM
> Aan: Trevor Cook; Spring Developers
> Onderwerp: Re: [Springframework-developer] Multipart File =
Handling
> =20
> =20
> Hi Trevor,
> =20
> A MultipartResolver interface with implementations for Commons =
FileUpload and COS is fine with me - it just hadn't high priority since =
I proposed it half a year ago. As I still have a pretty clear picture of =
the issues, I'll be happy to review your code once you've checked it in. =
As this should be pretty straightforward, let's try to include this =
already in 1.0 M2 - at least with a Commons FileUpload implementation.
> =20
> BTW, in contrast to COS, Commons FileUpload doesn't provide a =
Servlet 2.3 filter anyway. This means that there would be some =
infrastructure code to write for that use case too, even when using =
standard filters. A simple but convenient Spring solution would =
definitely be a good thing.
> =20
> Juergen
> =20
> =20
> =20
> =20
> -----Ursprngliche Nachricht-----
> Von: Trevor Cook [mailto:pr...@se...]
> Gesendet: Sa 27.09.2003 19:35
> An: Spring Developers
> Cc:
> Betreff: [[W3-SPAM]] - [Springframework-developer] =
Multipart File Handling - Email found in subject
> =20
> =20
> =20
> First some history:
> =
http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279
> =
http://sourceforge.net/mailarchive/message.php?msg_id=3D5175276
> =
http://sourceforge.net/mailarchive/forum.php?thread_id=3D3125561&forum_id=
=3D3028
> 7
> =
http://sourceforge.net/mailarchive/message.php?msg_id=3D6062288
> =20
> To address a few things Juergen mentioned previously.
> =20
> >> a less intrusive way would be to wrap the =
HttpServletRequest via a filter
> I personally don't like the filter approach, at least =
for the framework. It
> requires additional setup for the user (in the web.xml =
file) and might be
> less understandable since our normal strategy so far =
has been with resolvers
> inside the servlet.
> =20
> >>we would need to find concrete requirements for this
> We have numerous uses for file upload handling. We =
have a public photo
> contest where users can upload fotos. We have special =
access for suppliers
> to upload product files (csv) which we then add in to =
our ordering system.
> Finally, we have a web administration interface which =
allows our client to
> upload files to the website so they can be downloaded. =
I think that
> including this support (multipart handling) is a =
no-brainer.
> =20
> Basically, I have used COS exclusively in our =
projects, but I don't think
> that's easy for Spring to use (due to the licensing). =
I would simply code
> this according to Spring norms using an interface and =
a default version
> using Commons FileUpload. Later, if somebody wants to =
create a cos version
> we can (but to be honest, if we have a working, =
integrated solution I'm not
> sure that is necessary - at least not in the Spring =
framework). Basically,
> provide hooks and a default implementation, and allow =
users to adopt as
> necessary.
> =20
> In our project we had modified the AbstractController =
and put the code into
> it to handle the multipart processing, returning a =
wrapped
> HttpServletRequest through the handlers. This is very =
similiar to Juergen's
> outline =
(http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279).
> =20
> Since we are migrating to the current Spring codebase, =
I need to move our
> multipart handling code. The main question is whether =
we keep it
> internally, or place it into Spring. I propose =
modifying
> org.springframework.web.servlet.DispatcherServlet to =
have a
> "MultipartResolver". In the DispatcherServlet, the =
resolver would be called
> to wrap the request in doService immediately before =
getHandler(request) -
> currently line 351, and then called to do any cleanup =
immediately before
> exiting the doService method.
> =20
> I have about 2/3 of the code already written, and I =
will be writing the rest
> between now and Monday. Does this strategy sound =
appropriate for Spring
> (meaning should I commit it to the Spring codebase) =
when it's finished?
> =20
> Trevor D. Cook
> Interprise Software
> =20
>
|
|
From: <jue...@we...> - 2003-09-28 15:05:35
|
QmFjayBmcm9tIHZhY2F0aW9uLCBmaW5hbGx5ISBBZnRlciBzbGVlcGluZyBmb3IgdGhlIHdob2xl IGFmdGVybm9vbiB5ZXN0ZXJkYXkgYW5kIHN0YXlpbmcgdXAgYWxsIG5pZ2h0ICh3ZSBhbGwgbG92 ZSBqZXQgbGFnLCBkb24ndCB3ZT8pLCBJJ20gdHJ5aW5nIHRvIGFwcHJvYWNoIG5vcm1hbCBFdXJv cGVhbiBkYXkvbmlnaHQgcmh5dGhtIG5vdyA7LSkNCiANClJlZ2FyZGluZyBhIGZpbHRlcjogSWYg Q29tbW9ucyBGaWxlVXBsb2FkIHdhbnQgYSBmaWx0ZXIsIHRoZXkgc2hvdWxkIGRldmVsb3Agb25l LiBJZiB3ZSBwcm92aWRlIG91ciBvd24gbXVsdGlwYXJ0IHBhcnNpbmcgaG9va3MsIEkgZG8gbm90 IGNvbnNpZGVyIHN1Y2ggYSBTZXJ2bGV0IDIuMyBmaWx0ZXIgYXMgb3VyIHJlcG9uc2liaWxpdHku DQogDQpBcyB3ZSBoYXZlIGZpbGUgdXBsb2FkIHJlcXVpcmVtZW50cyBpbiBhbGwgd2VyazNBVCBw cm9kdWN0cywgSSdsbCByZXZpZXcgeW91ciBzb2x1dGlvbiBwcm9tcHRseSBhbmQgYWRhcHQgb3Vy IHByb2R1Y3RzIHRvIHRoZW0gYXMgc29vbiBhcyBwb3NzaWJsZS4gQ3VycmVudGx5LCBvbmUgdXNl cyBtYW51YWwgQ09TIGhhbmRsaW5nIGNvZGUgYW5kIHRoZSBvdGhlciB0d28gbWFudWFsIENvbW1v bnMgRmlsZVVwbG9hZCB3aXRoaW4gYSBjdXN0b20gU3ByaW5nIGNvbnRyb2xsZXIgaW1wbGVtZW50 YXRpb24uDQogDQpKdWVyZ2VuDQogDQogDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNo dC0tLS0tIA0KCVZvbjogVHJldm9yIENvb2sgW21haWx0bzpwcmlzZTAzQHNlbnRleC5uZXRdIA0K CUdlc2VuZGV0OiBTbyAyOC4wOS4yMDAzIDE2OjQwIA0KCUFuOiBqw7xyZ2VuIGjDtmxsZXIgW3dl cmszQVRdOyBTcHJpbmcgRGV2ZWxvcGVycyANCglDYzogDQoJQmV0cmVmZjogUkU6IFtTcHJpbmdm cmFtZXdvcmstZGV2ZWxvcGVyXSBNdWx0aXBhcnQgRmlsZSBIYW5kbGluZw0KCQ0KCQ0KDQoJSnVl cmdlbiAtIEdsYWQgdGhhdCB5b3UnbGwgbG9vayBhdCBpdC4gIEJhc2VkIG9uIHRoZSBwcmV2aW91 cyBlbWFpbHMgeW91IHNlZW0gdG8gaGF2ZSBhIHByZXR0eSBnb29kIGhhbmRsZSBvbiB0aGlzLCBh bmQgbXkgaWRlYXMgYXJlIGZhaXJseSBjbG9zZSB0byB5b3Vycy4gIEFyZSB5b3UgYmFjayBmcm9t IHZhY2F0aW9uIG5vdywgb3Igc3RpbGwgY2hlY2tpbmcgcmVtb3RlbHk/DQoJDQoJQXMgZmFyIGFz IHRoZSBmaWx0ZXIgZ29lcywgdGhhdCBpcyBkZWZpbmF0ZWx5IGEgcG9zc2libGl0eSB0byBhZGQg bGF0ZXIgKHBvc3NpYmx5IGV2ZW4gZm9yIDEuMCkgYnV0IG5vdCBzb21ldGhpbmcgSSdsbCBiZSBh YmxlIHRvIGxvb2sgYXQgcmlnaHQgYXdheS4gIEhvd2V2ZXIsIGl0IGNvdWxkIHVzZSB0aGUgc2Ft ZSBjb2RlLCBzbyBpdCBzaG91bGRuJ3QgYmUgdG9vIGRpZmZpY3VsdC4NCgkNCglUcmV2b3INCgkN CgkNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCUZyb206IGrDvHJnZW4gaMO2bGxlciBb d2VyazNBVF0gW21haWx0bzpqdWVyZ2VuLmhvZWxsZXJAd2VyazNhdC5jb21dDQoJU2VudDogU2Vw dGVtYmVyIDI4LCAyMDAzIDY6MzMgQU0NCglUbzogVHJldm9yIENvb2s7IFNwcmluZyBEZXZlbG9w ZXJzDQoJU3ViamVjdDogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBNdWx0aXBhcnQg RmlsZSBIYW5kbGluZw0KCQ0KCQ0KCUhpIFRyZXZvciwNCgkNCglBIE11bHRpcGFydFJlc29sdmVy IGludGVyZmFjZSB3aXRoIGltcGxlbWVudGF0aW9ucyBmb3IgQ29tbW9ucyBGaWxlVXBsb2FkIGFu ZCBDT1MgaXMgZmluZSB3aXRoIG1lIC0gaXQganVzdCBoYWRuJ3QgaGlnaCBwcmlvcml0eSBzaW5j ZSBJIHByb3Bvc2VkIGl0IGhhbGYgYSB5ZWFyIGFnby4gQXMgSSBzdGlsbCBoYXZlIGEgcHJldHR5 IGNsZWFyIHBpY3R1cmUgb2YgdGhlIGlzc3VlcywgSSdsbCBiZSBoYXBweSB0byByZXZpZXcgeW91 ciBjb2RlIG9uY2UgeW91J3ZlIGNoZWNrZWQgaXQgaW4uIEFzIHRoaXMgc2hvdWxkIGJlIHByZXR0 eSBzdHJhaWdodGZvcndhcmQsIGxldCdzIHRyeSB0byBpbmNsdWRlIHRoaXMgYWxyZWFkeSBpbiAx LjAgTTIgLSBhdCBsZWFzdCB3aXRoIGEgQ29tbW9ucyBGaWxlVXBsb2FkIGltcGxlbWVudGF0aW9u Lg0KCQ0KCUJUVywgaW4gY29udHJhc3QgdG8gQ09TLCBDb21tb25zIEZpbGVVcGxvYWQgZG9lc24n dCBwcm92aWRlIGEgU2VydmxldCAyLjMgZmlsdGVyIGFueXdheS4gVGhpcyBtZWFucyB0aGF0IHRo ZXJlIHdvdWxkIGJlIHNvbWUgaW5mcmFzdHJ1Y3R1cmUgY29kZSB0byB3cml0ZSBmb3IgdGhhdCB1 c2UgY2FzZSB0b28sIGV2ZW4gd2hlbiB1c2luZyBzdGFuZGFyZCBmaWx0ZXJzLiBBIHNpbXBsZSBi dXQgY29udmVuaWVudCBTcHJpbmcgc29sdXRpb24gd291bGQgZGVmaW5pdGVseSBiZSBhIGdvb2Qg dGhpbmcuDQoJDQoJSnVlcmdlbg0KCQ0KCQ0KCQ0KCQ0KCSAgICAgICAgLS0tLS1VcnNwcm5nbGlj aGUgTmFjaHJpY2h0LS0tLS0NCgkgICAgICAgIFZvbjogVHJldm9yIENvb2sgW21haWx0bzpwcmlz ZTAzQHNlbnRleC5uZXRdDQoJICAgICAgICBHZXNlbmRldDogU2EgMjcuMDkuMjAwMyAxOTozNQ0K CSAgICAgICAgQW46IFNwcmluZyBEZXZlbG9wZXJzDQoJICAgICAgICBDYzoNCgkgICAgICAgIEJl dHJlZmY6IFtbVzMtU1BBTV1dIC0gW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIE11bHRpcGFy dCBGaWxlIEhhbmRsaW5nIC0gRW1haWwgZm91bmQgaW4gc3ViamVjdA0KCSAgICAgICANCgkgICAg ICAgDQoJDQoJICAgICAgICBGaXJzdCBzb21lIGhpc3Rvcnk6DQoJICAgICAgICBodHRwOi8vc291 cmNlZm9yZ2UubmV0L21haWxhcmNoaXZlL21lc3NhZ2UucGhwP21zZ19pZD0zODkxMjc5DQoJICAg ICAgICBodHRwOi8vc291cmNlZm9yZ2UubmV0L21haWxhcmNoaXZlL21lc3NhZ2UucGhwP21zZ19p ZD01MTc1Mjc2DQoJICAgICAgICBodHRwOi8vc291cmNlZm9yZ2UubmV0L21haWxhcmNoaXZlL2Zv cnVtLnBocD90aHJlYWRfaWQ9MzEyNTU2MSZmb3J1bV9pZD0zMDI4DQoJICAgICAgICA3DQoJICAg ICAgICBodHRwOi8vc291cmNlZm9yZ2UubmV0L21haWxhcmNoaXZlL21lc3NhZ2UucGhwP21zZ19p ZD02MDYyMjg4DQoJICAgICAgIA0KCSAgICAgICAgVG8gYWRkcmVzcyBhIGZldyB0aGluZ3MgSnVl cmdlbiBtZW50aW9uZWQgcHJldmlvdXNseS4NCgkgICAgICAgDQoJICAgICAgICA+PiBhIGxlc3Mg aW50cnVzaXZlIHdheSB3b3VsZCBiZSB0byB3cmFwIHRoZSBIdHRwU2VydmxldFJlcXVlc3Qgdmlh IGEgZmlsdGVyDQoJICAgICAgICBJIHBlcnNvbmFsbHkgZG9uJ3QgbGlrZSB0aGUgZmlsdGVyIGFw cHJvYWNoLCBhdCBsZWFzdCBmb3IgdGhlIGZyYW1ld29yay4gIEl0DQoJICAgICAgICByZXF1aXJl cyBhZGRpdGlvbmFsIHNldHVwIGZvciB0aGUgdXNlciAoaW4gdGhlIHdlYi54bWwgZmlsZSkgYW5k IG1pZ2h0IGJlDQoJICAgICAgICBsZXNzIHVuZGVyc3RhbmRhYmxlIHNpbmNlIG91ciBub3JtYWwg c3RyYXRlZ3kgc28gZmFyIGhhcyBiZWVuIHdpdGggcmVzb2x2ZXJzDQoJICAgICAgICBpbnNpZGUg dGhlIHNlcnZsZXQuDQoJICAgICAgIA0KCSAgICAgICAgPj53ZSB3b3VsZCBuZWVkIHRvIGZpbmQg Y29uY3JldGUgcmVxdWlyZW1lbnRzIGZvciB0aGlzDQoJICAgICAgICBXZSBoYXZlIG51bWVyb3Vz IHVzZXMgZm9yIGZpbGUgdXBsb2FkIGhhbmRsaW5nLiAgV2UgaGF2ZSBhIHB1YmxpYyBwaG90bw0K CSAgICAgICAgY29udGVzdCB3aGVyZSB1c2VycyBjYW4gdXBsb2FkIGZvdG9zLiAgV2UgaGF2ZSBz cGVjaWFsIGFjY2VzcyBmb3Igc3VwcGxpZXJzDQoJICAgICAgICB0byB1cGxvYWQgcHJvZHVjdCBm aWxlcyAoY3N2KSB3aGljaCB3ZSB0aGVuIGFkZCBpbiB0byBvdXIgb3JkZXJpbmcgc3lzdGVtLg0K CSAgICAgICAgRmluYWxseSwgd2UgaGF2ZSBhIHdlYiBhZG1pbmlzdHJhdGlvbiBpbnRlcmZhY2Ug d2hpY2ggYWxsb3dzIG91ciBjbGllbnQgdG8NCgkgICAgICAgIHVwbG9hZCBmaWxlcyB0byB0aGUg d2Vic2l0ZSBzbyB0aGV5IGNhbiBiZSBkb3dubG9hZGVkLiAgSSB0aGluayB0aGF0DQoJICAgICAg ICBpbmNsdWRpbmcgdGhpcyBzdXBwb3J0IChtdWx0aXBhcnQgaGFuZGxpbmcpIGlzIGEgbm8tYnJh aW5lci4NCgkgICAgICAgDQoJICAgICAgICBCYXNpY2FsbHksIEkgaGF2ZSB1c2VkIENPUyBleGNs dXNpdmVseSBpbiBvdXIgcHJvamVjdHMsIGJ1dCBJIGRvbid0IHRoaW5rDQoJICAgICAgICB0aGF0 J3MgZWFzeSBmb3IgU3ByaW5nIHRvIHVzZSAoZHVlIHRvIHRoZSBsaWNlbnNpbmcpLiAgSSB3b3Vs ZCBzaW1wbHkgY29kZQ0KCSAgICAgICAgdGhpcyBhY2NvcmRpbmcgdG8gU3ByaW5nIG5vcm1zIHVz aW5nIGFuIGludGVyZmFjZSBhbmQgYSBkZWZhdWx0IHZlcnNpb24NCgkgICAgICAgIHVzaW5nIENv bW1vbnMgRmlsZVVwbG9hZC4gIExhdGVyLCBpZiBzb21lYm9keSB3YW50cyB0byBjcmVhdGUgYSBj b3MgdmVyc2lvbg0KCSAgICAgICAgd2UgY2FuIChidXQgdG8gYmUgaG9uZXN0LCBpZiB3ZSBoYXZl IGEgd29ya2luZywgaW50ZWdyYXRlZCBzb2x1dGlvbiBJJ20gbm90DQoJICAgICAgICBzdXJlIHRo YXQgaXMgbmVjZXNzYXJ5IC0gYXQgbGVhc3Qgbm90IGluIHRoZSBTcHJpbmcgZnJhbWV3b3JrKS4g IEJhc2ljYWxseSwNCgkgICAgICAgIHByb3ZpZGUgaG9va3MgYW5kIGEgZGVmYXVsdCBpbXBsZW1l bnRhdGlvbiwgYW5kIGFsbG93IHVzZXJzIHRvIGFkb3B0IGFzDQoJICAgICAgICBuZWNlc3Nhcnku DQoJICAgICAgIA0KCSAgICAgICAgSW4gb3VyIHByb2plY3Qgd2UgaGFkIG1vZGlmaWVkIHRoZSBB YnN0cmFjdENvbnRyb2xsZXIgYW5kIHB1dCB0aGUgY29kZSBpbnRvDQoJICAgICAgICBpdCB0byBo YW5kbGUgdGhlIG11bHRpcGFydCBwcm9jZXNzaW5nLCByZXR1cm5pbmcgYSB3cmFwcGVkDQoJICAg ICAgICBIdHRwU2VydmxldFJlcXVlc3QgdGhyb3VnaCB0aGUgaGFuZGxlcnMuICBUaGlzIGlzIHZl cnkgc2ltaWxpYXIgdG8gSnVlcmdlbidzDQoJICAgICAgICBvdXRsaW5lIChodHRwOi8vc291cmNl Zm9yZ2UubmV0L21haWxhcmNoaXZlL21lc3NhZ2UucGhwP21zZ19pZD0zODkxMjc5KS4NCgkgICAg ICAgDQoJICAgICAgICBTaW5jZSB3ZSBhcmUgbWlncmF0aW5nIHRvIHRoZSBjdXJyZW50IFNwcmlu ZyBjb2RlYmFzZSwgSSBuZWVkIHRvIG1vdmUgb3VyDQoJICAgICAgICBtdWx0aXBhcnQgaGFuZGxp bmcgY29kZS4gIFRoZSBtYWluIHF1ZXN0aW9uIGlzIHdoZXRoZXIgd2Uga2VlcCBpdA0KCSAgICAg ICAgaW50ZXJuYWxseSwgb3IgcGxhY2UgaXQgaW50byBTcHJpbmcuICBJIHByb3Bvc2UgbW9kaWZ5 aW5nDQoJICAgICAgICBvcmcuc3ByaW5nZnJhbWV3b3JrLndlYi5zZXJ2bGV0LkRpc3BhdGNoZXJT ZXJ2bGV0IHRvIGhhdmUgYQ0KCSAgICAgICAgIk11bHRpcGFydFJlc29sdmVyIi4gIEluIHRoZSBE aXNwYXRjaGVyU2VydmxldCwgdGhlIHJlc29sdmVyIHdvdWxkIGJlIGNhbGxlZA0KCSAgICAgICAg dG8gd3JhcCB0aGUgcmVxdWVzdCBpbiBkb1NlcnZpY2UgaW1tZWRpYXRlbHkgYmVmb3JlIGdldEhh bmRsZXIocmVxdWVzdCkgLQ0KCSAgICAgICAgY3VycmVudGx5IGxpbmUgMzUxLCBhbmQgdGhlbiBj YWxsZWQgdG8gZG8gYW55IGNsZWFudXAgaW1tZWRpYXRlbHkgYmVmb3JlDQoJICAgICAgICBleGl0 aW5nIHRoZSBkb1NlcnZpY2UgbWV0aG9kLg0KCSAgICAgICANCgkgICAgICAgIEkgaGF2ZSBhYm91 dCAyLzMgb2YgdGhlIGNvZGUgYWxyZWFkeSB3cml0dGVuLCBhbmQgSSB3aWxsIGJlIHdyaXRpbmcg dGhlIHJlc3QNCgkgICAgICAgIGJldHdlZW4gbm93IGFuZCBNb25kYXkuICBEb2VzIHRoaXMgc3Ry YXRlZ3kgc291bmQgYXBwcm9wcmlhdGUgZm9yIFNwcmluZw0KCSAgICAgICAgKG1lYW5pbmcgc2hv dWxkIEkgY29tbWl0IGl0IHRvIHRoZSBTcHJpbmcgY29kZWJhc2UpIHdoZW4gaXQncyBmaW5pc2hl ZD8NCgkgICAgICAgDQoJICAgICAgICBUcmV2b3IgRC4gQ29vaw0KCSAgICAgICAgSW50ZXJwcmlz ZSBTb2Z0d2FyZQ0KCSAgICAgICANCgkgICAgICAgDQoJICAgICAgIA0KCSAgICAgICAgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCSAgICAg ICAgVGhpcyBzZi5uZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5OlRoaW5rR2Vlaw0KCSAgICAgICAg V2VsY29tZSB0byBnZWVrIGhlYXZlbi4NCgkgICAgICAgIGh0dHA6Ly90aGlua2dlZWsuY29tL3Nm DQoJICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KCSAgICAgICAgU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciBtYWlsaW5nIGxpc3QNCgkgICAg ICAgIFNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJICAg ICAgICBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdm cmFtZXdvcmstZGV2ZWxvcGVyDQoJICAgICAgIA0KCQ0KCQ0KCQ0KDQo= |
|
From: <jue...@we...> - 2003-10-08 17:31:58
|
SGkgVHJldm9yLCBldmVyeWJvZHksDQoNCkkndmUgY29tbWl0dGVkIGEgc2VyaW91cyByZXZpc2lv biBvZiBvdXIgbXVsdGlwYXJ0IHN1cHBvcnQgdG9kYXksIGJvdGggaW4gdGVybXMgb2YgQVBJIGFu ZCBpbXBsZW1lbnRhdGlvbi4gSXQgbm93IHJlc2lkZXMgaW4gb3JnLnNwcmluZ2ZyYW1ld29yay53 ZWIubXVsdGlwYXJ0IGluc3RlYWQgb2Ygd2ViLnNlcnZsZXQubXVsdGlwYXJ0LCB0byByZWZsZWN0 IGl0cyBtb3JlIGdlbmVyaWMgbmF0dXJlOiBJdCdzIG5vdCBib3VuZCB0byBEaXNwYXRjaGVyU2Vy dmxldCBpdCBhbnkgd2F5OyB0aGUgbGF0dGVyIGp1c3QgaGFzIHN1cHBvcnQgdG8gZGV0ZWN0IGEg Im11bHRpcGFydFJlc29sdmVyIiBiZWFuIGFuZCBhdXRvbWF0aWNhbGx5IGFwcGx5IGl0Lg0KDQpP dXIgbXVsdGlwYXJ0IGluZnJhc3RydWN0dXJlIGNhbiBhbHNvIGJlIHVzZWQgcHJvZ3JhbW1hdGlj YWxseSwgYnkgZGlyZWN0IE11bHRpcGFydFJlc29sdmVyIGNhbGxzLCBvciB2aWEgdGhlIG5ldyBN dWx0aXBhcnRGaWx0ZXI6IFRoZSBmaWx0ZXIgZGV0ZWN0cyB0aGUgcmVzb2x2ZXIgaW4gYSByb290 IHdlYiBhcHBsaWNhdGlvbiBjb250ZXh0IGFuZCBhcHBsaWVzIGl0OyBpdCBjYW4gYWxzbyBiZSBv dmVycmlkZGVuIHRvIHVzZSBhIGN1c3RvbSBNdWx0aXBhcnRSZXNvbHZlciBpbnN0YW5jZSBjb21w bGV0ZWx5IHdpdGhvdXQgYSBTcHJpbmcgYXBwbGljYXRpb24gY29udGV4dC4gVGhlIGZpbHRlciBp cyBtYWlubHkgaW50ZW5kZWQgZm9yIGFwcGxpY2F0aW9ucyB0aGF0IGRvIG5vdCB1c2UgU3ByaW5n J3Mgd2ViIE1WQywgZS5nLiBpbiB0aGUgY2FzZSBvZiBjdXN0b20gd2ViIHZpZXdzIG9yIFN0cnV0 cyBhY3Rpb25zLg0KDQpJJ3ZlIGFsc28gaW50cm9kdWNlZCBhIENPUyBpbXBsZW1lbnRhdGlvbiBv ZiBNdWx0aXBhcnRSZXNvbHZlciwgYW5kIGFkZGVkIGEgZnVsbC1ibG93biB0ZXN0IHN1aXRlIGZv ciBDb21tb25zTXVsdGlwYXJ0UmVzb2x2ZXIuIFVuZm9ydHVuYXRlbHksIENPUyBpcyBoYXJkIHRv IG1vY2s7IHRoZXJlZm9yZSwgdGhlIENvc011bHRpcGFydFJlc29sdmVyIHRlc3Qgc3VpdGUgaXMg c3RpbGwgcmF0aGVyIGxpbWl0ZWQuDQoNCkZ1cnRoZXJtb3JlLCBJJ3ZlIGRyb3BwZWQgdGhlIHBy ZXZpb3VzIFByb3BlcnR5RWRpdG9ycyBzdXBwb3J0LCBhbmQgdGhlIGFzc29jaWF0ZWQgcmVxdWly ZW1lbnQgZm9yIGZpbGUgcGFyYW1ldGVycyBoYXZpbmcgdG8gYmUgYXZhaWxhYmxlIGFzIG5vcm1h bCBwYXJhbWV0ZXJzIHdpdGggdGhlIGZpZWxkIG5hbWUgYXMgdmFsdWUuIFRoYXQgc2VlbWVkIGxp a2UgYSB3b3JrYXJvdW5kOyBpbnN0ZWFkLCBJJ3ZlIGFkZGVkIGV4cGxpY2l0IGRldGVjdGlvbiB0 byBTZXJ2bGV0UmVxdWVzdERhdGFCaW5kZXIsIHdoaWNoIGlzIG5vdyBhYmxlIHRvIGJpbmQgZmls ZSBwYXJhbWV0ZXJzIGFzIE11bHRpcGFydEZpbGUgb3IgYnl0ZVtdLCBkZXBlbmRpbmcgb24gdGhl IHR5cGUgb2YgdGhlIHRhcmdldCBiZWFuIHByb3BlcnR5LiBJJ3ZlIG5vdCByZWludHJvZHVjZWQg YmluZGluZyB0aGUgb3JpZ2luYWwgZmlsZSBuYW1lIHRvIGEgU3RyaW5nIHByb3BlcnR5LCBhcyBJ IGNhbid0IHNlZSB0aGUgdmFsdWUgb2YgdGhhdCBmZWF0dXJlLg0KDQpJIGhvcGUgZXZlcnlib2R5 J3MgaGFwcHkgd2l0aCB0aGUgY3VycmVudCBzdGF0ZS4gUGxlYXNlIGdpdmUgaXQgYSB0cnk6IEl0 J3MgcHJldHR5IHNpbXBsZSB0byBzZXR1cCwganVzdCBwdXQNCg0KICA8YmVhbiBpZD0ibXVsdGlw YXJ0UmVzb2x2ZXIiIGNsYXNzPSJvcmcuc3ByaW5nZnJhbWV3b3JrLndlYi5tdWx0aXBhcnQuY29t bW9ucy5Db21tb25zTXVsdGlwYXJ0UmVzb2x2ZXIiLz4NCg0Kb3INCg0KICA8YmVhbiBpZD0ibXVs dGlwYXJ0UmVzb2x2ZXIiIGNsYXNzPSJvcmcuc3ByaW5nZnJhbWV3b3JrLndlYi5tdWx0aXBhcnQu Y29zLkNvc011bHRpcGFydFJlc29sdmVyIi8+DQoNCmluIHlvdXIgRGlzcGF0Y2hlclNlcnZsZXQg YXBwbGljYXRpb24gY29udGV4dHMsIGFuZCBkcm9wIHRoZSBDb21tb25zIEZpbGVVcGxvYWQgb3Ig Q09TIGphcnMgaW4geW91ciBXRUItSU5GL2xpYi4gVGhlbiBjYXN0IHRoZSByZXF1ZXN0IHRvIE11 bHRpcGFydEh0dHBTZXJ2bGV0UmVxdWVzdCBpbiB5b3VyIGNvbnRyb2xsZXIocyksIGNoZWNraW5n IGZvciB1cGxvYWRlZCBmaWxlcy4gQW4gdXBsb2FkIGNvbnRyb2xsZXIgY2FuIGJlIGRyaXZlbiB3 aXRoIGFuIEhUTUwgZm9ybSBhcyBzaW1wbGUgYXM6DQoNCiAgPGZvcm0gYWN0aW9uPSIvdGVzdC91 cGxvYWQiIG1ldGhvZD0icG9zdCIgZW5jdHlwZT0ibXVsdGlwYXJ0L2Zvcm0tZGF0YSI+DQogICAg PGlucHV0IG5hbWU9Im15ZmlsZSIgdHlwZT0iZmlsZSI+DQogICAgPGlucHV0IHR5cGU9InN1Ym1p dCI+DQogIDwvZm9ybT4NCg0KUmVnYXJkcywNCkp1ZXJnZW4NCg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBUcmV2b3IgQ29vayBbbWFpbHRvOnByaXNlMDNAc2VudGV4Lm5l dF0NClNlbnQ6IFN1bmRheSwgU2VwdGVtYmVyIDI4LCAyMDAzIDQ6NDAgUE0NClRvOiBqw7xyZ2Vu IGjDtmxsZXIgW3dlcmszQVRdOyBTcHJpbmcgRGV2ZWxvcGVycw0KU3ViamVjdDogUkU6IFtTcHJp bmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBNdWx0aXBhcnQgRmlsZSBIYW5kbGluZw0KDQoNCkp1ZXJn ZW4gLSBHbGFkIHRoYXQgeW91J2xsIGxvb2sgYXQgaXQuICBCYXNlZCBvbiB0aGUgcHJldmlvdXMg ZW1haWxzIHlvdSBzZWVtIHRvIGhhdmUgYSBwcmV0dHkgZ29vZCBoYW5kbGUgb24gdGhpcywgYW5k IG15IGlkZWFzIGFyZSBmYWlybHkgY2xvc2UgdG8geW91cnMuICBBcmUgeW91IGJhY2sgZnJvbSB2 YWNhdGlvbiBub3csIG9yIHN0aWxsIGNoZWNraW5nIHJlbW90ZWx5Pw0KDQpBcyBmYXIgYXMgdGhl IGZpbHRlciBnb2VzLCB0aGF0IGlzIGRlZmluYXRlbHkgYSBwb3NzaWJsaXR5IHRvIGFkZCBsYXRl ciAocG9zc2libHkgZXZlbiBmb3IgMS4wKSBidXQgbm90IHNvbWV0aGluZyBJJ2xsIGJlIGFibGUg dG8gbG9vayBhdCByaWdodCBhd2F5LiAgSG93ZXZlciwgaXQgY291bGQgdXNlIHRoZSBzYW1lIGNv ZGUsIHNvIGl0IHNob3VsZG4ndCBiZSB0b28gZGlmZmljdWx0Lg0KDQpUcmV2b3INCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXSBb bWFpbHRvOmp1ZXJnZW4uaG9lbGxlckB3ZXJrM2F0LmNvbV0NClNlbnQ6IFNlcHRlbWJlciAyOCwg MjAwMyA2OjMzIEFNDQpUbzogVHJldm9yIENvb2s7IFNwcmluZyBEZXZlbG9wZXJzDQpTdWJqZWN0 OiBSZTogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIE11bHRpcGFydCBGaWxlIEhhbmRsaW5n DQoNCg0KSGkgVHJldm9yLA0KIA0KQSBNdWx0aXBhcnRSZXNvbHZlciBpbnRlcmZhY2Ugd2l0aCBp bXBsZW1lbnRhdGlvbnMgZm9yIENvbW1vbnMgRmlsZVVwbG9hZCBhbmQgQ09TIGlzIGZpbmUgd2l0 aCBtZSAtIGl0IGp1c3QgaGFkbid0IGhpZ2ggcHJpb3JpdHkgc2luY2UgSSBwcm9wb3NlZCBpdCBo YWxmIGEgeWVhciBhZ28uIEFzIEkgc3RpbGwgaGF2ZSBhIHByZXR0eSBjbGVhciBwaWN0dXJlIG9m IHRoZSBpc3N1ZXMsIEknbGwgYmUgaGFwcHkgdG8gcmV2aWV3IHlvdXIgY29kZSBvbmNlIHlvdSd2 ZSBjaGVja2VkIGl0IGluLiBBcyB0aGlzIHNob3VsZCBiZSBwcmV0dHkgc3RyYWlnaHRmb3J3YXJk LCBsZXQncyB0cnkgdG8gaW5jbHVkZSB0aGlzIGFscmVhZHkgaW4gMS4wIE0yIC0gYXQgbGVhc3Qg d2l0aCBhIENvbW1vbnMgRmlsZVVwbG9hZCBpbXBsZW1lbnRhdGlvbi4NCiANCkJUVywgaW4gY29u dHJhc3QgdG8gQ09TLCBDb21tb25zIEZpbGVVcGxvYWQgZG9lc24ndCBwcm92aWRlIGEgU2Vydmxl dCAyLjMgZmlsdGVyIGFueXdheS4gVGhpcyBtZWFucyB0aGF0IHRoZXJlIHdvdWxkIGJlIHNvbWUg aW5mcmFzdHJ1Y3R1cmUgY29kZSB0byB3cml0ZSBmb3IgdGhhdCB1c2UgY2FzZSB0b28sIGV2ZW4g d2hlbiB1c2luZyBzdGFuZGFyZCBmaWx0ZXJzLiBBIHNpbXBsZSBidXQgY29udmVuaWVudCBTcHJp bmcgc29sdXRpb24gd291bGQgZGVmaW5pdGVseSBiZSBhIGdvb2QgdGhpbmcuDQogDQpKdWVyZ2Vu DQogDQogDQogDQoNCgktLS0tLVVyc3BybmdsaWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IFRy ZXZvciBDb29rIFttYWlsdG86cHJpc2UwM0BzZW50ZXgubmV0XSANCglHZXNlbmRldDogU2EgMjcu MDkuMjAwMyAxOTozNSANCglBbjogU3ByaW5nIERldmVsb3BlcnMgDQoJQ2M6IA0KCUJldHJlZmY6 IFtbVzMtU1BBTV1dIC0gW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIE11bHRpcGFydCBGaWxl IEhhbmRsaW5nIC0gRW1haWwgZm91bmQgaW4gc3ViamVjdA0KCQ0KCQ0KDQoJRmlyc3Qgc29tZSBo aXN0b3J5Og0KCWh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvbWFpbGFyY2hpdmUvbWVzc2FnZS5waHA/ bXNnX2lkPTM4OTEyNzkNCglodHRwOi8vc291cmNlZm9yZ2UubmV0L21haWxhcmNoaXZlL21lc3Nh Z2UucGhwP21zZ19pZD01MTc1Mjc2DQoJaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9tYWlsYXJjaGl2 ZS9mb3J1bS5waHA/dGhyZWFkX2lkPTMxMjU1NjEmZm9ydW1faWQ9MzAyOA0KCTcNCglodHRwOi8v c291cmNlZm9yZ2UubmV0L21haWxhcmNoaXZlL21lc3NhZ2UucGhwP21zZ19pZD02MDYyMjg4DQoJ DQoJVG8gYWRkcmVzcyBhIGZldyB0aGluZ3MgSnVlcmdlbiBtZW50aW9uZWQgcHJldmlvdXNseS4N CgkNCgk+PiBhIGxlc3MgaW50cnVzaXZlIHdheSB3b3VsZCBiZSB0byB3cmFwIHRoZSBIdHRwU2Vy dmxldFJlcXVlc3QgdmlhIGEgZmlsdGVyDQoJSSBwZXJzb25hbGx5IGRvbid0IGxpa2UgdGhlIGZp bHRlciBhcHByb2FjaCwgYXQgbGVhc3QgZm9yIHRoZSBmcmFtZXdvcmsuICBJdA0KCXJlcXVpcmVz IGFkZGl0aW9uYWwgc2V0dXAgZm9yIHRoZSB1c2VyIChpbiB0aGUgd2ViLnhtbCBmaWxlKSBhbmQg bWlnaHQgYmUNCglsZXNzIHVuZGVyc3RhbmRhYmxlIHNpbmNlIG91ciBub3JtYWwgc3RyYXRlZ3kg c28gZmFyIGhhcyBiZWVuIHdpdGggcmVzb2x2ZXJzDQoJaW5zaWRlIHRoZSBzZXJ2bGV0Lg0KCQ0K CT4+d2Ugd291bGQgbmVlZCB0byBmaW5kIGNvbmNyZXRlIHJlcXVpcmVtZW50cyBmb3IgdGhpcw0K CVdlIGhhdmUgbnVtZXJvdXMgdXNlcyBmb3IgZmlsZSB1cGxvYWQgaGFuZGxpbmcuICBXZSBoYXZl IGEgcHVibGljIHBob3RvDQoJY29udGVzdCB3aGVyZSB1c2VycyBjYW4gdXBsb2FkIGZvdG9zLiAg V2UgaGF2ZSBzcGVjaWFsIGFjY2VzcyBmb3Igc3VwcGxpZXJzDQoJdG8gdXBsb2FkIHByb2R1Y3Qg ZmlsZXMgKGNzdikgd2hpY2ggd2UgdGhlbiBhZGQgaW4gdG8gb3VyIG9yZGVyaW5nIHN5c3RlbS4N CglGaW5hbGx5LCB3ZSBoYXZlIGEgd2ViIGFkbWluaXN0cmF0aW9uIGludGVyZmFjZSB3aGljaCBh bGxvd3Mgb3VyIGNsaWVudCB0bw0KCXVwbG9hZCBmaWxlcyB0byB0aGUgd2Vic2l0ZSBzbyB0aGV5 IGNhbiBiZSBkb3dubG9hZGVkLiAgSSB0aGluayB0aGF0DQoJaW5jbHVkaW5nIHRoaXMgc3VwcG9y dCAobXVsdGlwYXJ0IGhhbmRsaW5nKSBpcyBhIG5vLWJyYWluZXIuDQoJDQoJQmFzaWNhbGx5LCBJ IGhhdmUgdXNlZCBDT1MgZXhjbHVzaXZlbHkgaW4gb3VyIHByb2plY3RzLCBidXQgSSBkb24ndCB0 aGluaw0KCXRoYXQncyBlYXN5IGZvciBTcHJpbmcgdG8gdXNlIChkdWUgdG8gdGhlIGxpY2Vuc2lu ZykuICBJIHdvdWxkIHNpbXBseSBjb2RlDQoJdGhpcyBhY2NvcmRpbmcgdG8gU3ByaW5nIG5vcm1z IHVzaW5nIGFuIGludGVyZmFjZSBhbmQgYSBkZWZhdWx0IHZlcnNpb24NCgl1c2luZyBDb21tb25z IEZpbGVVcGxvYWQuICBMYXRlciwgaWYgc29tZWJvZHkgd2FudHMgdG8gY3JlYXRlIGEgY29zIHZl cnNpb24NCgl3ZSBjYW4gKGJ1dCB0byBiZSBob25lc3QsIGlmIHdlIGhhdmUgYSB3b3JraW5nLCBp bnRlZ3JhdGVkIHNvbHV0aW9uIEknbSBub3QNCglzdXJlIHRoYXQgaXMgbmVjZXNzYXJ5IC0gYXQg bGVhc3Qgbm90IGluIHRoZSBTcHJpbmcgZnJhbWV3b3JrKS4gIEJhc2ljYWxseSwNCglwcm92aWRl IGhvb2tzIGFuZCBhIGRlZmF1bHQgaW1wbGVtZW50YXRpb24sIGFuZCBhbGxvdyB1c2VycyB0byBh ZG9wdCBhcw0KCW5lY2Vzc2FyeS4NCgkNCglJbiBvdXIgcHJvamVjdCB3ZSBoYWQgbW9kaWZpZWQg dGhlIEFic3RyYWN0Q29udHJvbGxlciBhbmQgcHV0IHRoZSBjb2RlIGludG8NCglpdCB0byBoYW5k bGUgdGhlIG11bHRpcGFydCBwcm9jZXNzaW5nLCByZXR1cm5pbmcgYSB3cmFwcGVkDQoJSHR0cFNl cnZsZXRSZXF1ZXN0IHRocm91Z2ggdGhlIGhhbmRsZXJzLiAgVGhpcyBpcyB2ZXJ5IHNpbWlsaWFy IHRvIEp1ZXJnZW4ncw0KCW91dGxpbmUgKGh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvbWFpbGFyY2hp dmUvbWVzc2FnZS5waHA/bXNnX2lkPTM4OTEyNzkpLg0KCQ0KCVNpbmNlIHdlIGFyZSBtaWdyYXRp bmcgdG8gdGhlIGN1cnJlbnQgU3ByaW5nIGNvZGViYXNlLCBJIG5lZWQgdG8gbW92ZSBvdXINCglt dWx0aXBhcnQgaGFuZGxpbmcgY29kZS4gIFRoZSBtYWluIHF1ZXN0aW9uIGlzIHdoZXRoZXIgd2Ug a2VlcCBpdA0KCWludGVybmFsbHksIG9yIHBsYWNlIGl0IGludG8gU3ByaW5nLiAgSSBwcm9wb3Nl IG1vZGlmeWluZw0KCW9yZy5zcHJpbmdmcmFtZXdvcmsud2ViLnNlcnZsZXQuRGlzcGF0Y2hlclNl cnZsZXQgdG8gaGF2ZSBhDQoJIk11bHRpcGFydFJlc29sdmVyIi4gIEluIHRoZSBEaXNwYXRjaGVy U2VydmxldCwgdGhlIHJlc29sdmVyIHdvdWxkIGJlIGNhbGxlZA0KCXRvIHdyYXAgdGhlIHJlcXVl c3QgaW4gZG9TZXJ2aWNlIGltbWVkaWF0ZWx5IGJlZm9yZSBnZXRIYW5kbGVyKHJlcXVlc3QpIC0N CgljdXJyZW50bHkgbGluZSAzNTEsIGFuZCB0aGVuIGNhbGxlZCB0byBkbyBhbnkgY2xlYW51cCBp bW1lZGlhdGVseSBiZWZvcmUNCglleGl0aW5nIHRoZSBkb1NlcnZpY2UgbWV0aG9kLg0KCQ0KCUkg aGF2ZSBhYm91dCAyLzMgb2YgdGhlIGNvZGUgYWxyZWFkeSB3cml0dGVuLCBhbmQgSSB3aWxsIGJl IHdyaXRpbmcgdGhlIHJlc3QNCgliZXR3ZWVuIG5vdyBhbmQgTW9uZGF5LiAgRG9lcyB0aGlzIHN0 cmF0ZWd5IHNvdW5kIGFwcHJvcHJpYXRlIGZvciBTcHJpbmcNCgkobWVhbmluZyBzaG91bGQgSSBj b21taXQgaXQgdG8gdGhlIFNwcmluZyBjb2RlYmFzZSkgd2hlbiBpdCdzIGZpbmlzaGVkPw0KCQ0K CVRyZXZvciBELiBDb29rDQoJSW50ZXJwcmlzZSBTb2Z0d2FyZQ0KCQ0KCQ0KCQ0KCS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCglUaGlzIHNm Lm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6VGhpbmtHZWVrDQoJV2VsY29tZSB0byBnZWVrIGhl YXZlbi4NCglodHRwOi8vdGhpbmtnZWVrLmNvbS9zZg0KCV9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoJU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciBtYWls aW5nIGxpc3QNCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5l dA0KCWh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3NwcmluZ2Zy YW1ld29yay1kZXZlbG9wZXINCgkNCg0KDQo= |
|
From: Trevor C. <pr...@se...> - 2003-10-13 20:23:00
|
<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 |
|
From: <jue...@we...> - 2003-10-13 23:28:31
|
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= |
|
From: <jue...@we...> - 2003-10-14 05:14:50
|
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= |
|
From: Trevor C. <pr...@se...> - 2003-10-14 13:06:09
|
It is interesting seeing your arguments flip 180 degrees in a few =
paragraphs, but you're not alone there. I find the same thing, that =
talking helps me find my own solutions.
As far as the implementation goes, the changes are perfect. It's a lot =
cleaner than my original version (no coupling with DispatcherServlet or =
property editors), but we still have the benefit of custom property =
handling.
I've migrated our project from the original multipart to the new =
version, and everything works great. My code uses "standard" handling =
(byte[] and MultipartFile) as well as the custom property editors. I've =
also subclassed the CommonsMultipartResolver to provide some additional =
functionality in our app, and that works perfect as well.
I think we have a winner :)
Trevor D. Cook
-----Original Message-----
From: j=C3=BCrgen h=C3=B6ller [werk3AT] =
[mailto:jue...@we...]
Sent: October 14, 2003 1:13 AM
To: j=C3=BCrgen h=C3=B6ller [werk3AT]; Trevor Cook; Spring Developers
Subject: Re: [Springframework-developer] Multipart File Handling
P.S.: Funny how the direction of an own argument can change in the =
course of a single email ;-) Of course, I was talking about =
PropertyEditor's setAsText (and the indirection with String values that =
match field names) in the first paragraph, and haven't had realized at =
that time that there was the completely different setValue option too...
=20
Juergen
=20
-----Ursprngliche Nachricht-----=20
Von: j rgen hller [werk3AT]=20
Gesendet: Di 14.10.2003 01:26=20
An: Trevor Cook; Spring Developers=20
Cc:=20
Betreff: Re: [Springframework-developer] Multipart File Handling
=09
=09
Trevor,
=09
Sorry if I've been a bit eager in terms of getting rid of the =
PropertyEditor stuff for multipart files. I strongly believe that the =
JavaBeans PropertyEditor is not appropriate for multipart files though, =
as it is about converting *String* parameters to other types. This is =
fine for standard ServletRequest parameters that come in as String =
values and need to be bound to arbitrary properties of command objects. =
Multipart files on the other hand are by their very nature complex =
objects; they do not have a natural String representation.
=09
The previous mechanism of binding multipart files via PropertyEditor =
required MultipartHttpServletRequest's getParameter method to return the =
field name as value a la getParameter("myfield") -> "myfield", so that a =
PropertyEditor that can just see the value would be able to identify the =
field name and invoke MultipartHttpServletRequest's getFile("myfield") =
to return the MultipartFile instance. This *is* a workaround, as it is =
not at all natural to have getParameter return the field name as value =
in case of a multipart file.
=09
ServletRequestDataBinder is not a bad place for binding multipart =
files, given that our MultipartHttpServletRequest is a generic interface =
that resides in the non-DispatcherServlet-specific web.multipart package =
now. I agree that it isn't generally preferable to hardcode binding =
options, but I've initially felt that there aren't any other meaningful =
conversions than a MultipartFile itself or a byte[] as value of a =
command bean property. Note that you can always override =
BaseCommandController's onBindAndValidate to perform *custom* binding.
=09
-----
=09
On second thought, I agree that a pluggable conversion mechanism is =
preferable. I've just reworked the multipart binding into a =
PropertyEditor mechanism again, but with a different implementation =
pattern: ServletRequestDataBinder simply binds the file map returned by =
MultipartHttpServletRequest.getFileMap as property values. This means =
that bean properties of type MultipartFile can be populated directly, =
without conversion. Other types go through the PropertyEditor mechanism, =
but via calling setValue(Object) instead of setAsText(String).
=09
ByteArrayMultipartFileEditor and StringMultipartFileEditor implement =
setValue to transform the given MultipartFile instance into either a =
byte array or a String, the latter with configurable charset. Note than =
none of these needs a MultipartHttpServletRequest: They receive the =
MultipartFile instances bound as property values by =
ServletRequestDataBinder. Those two custom editors need to be registered =
with ServletRequestDataBinder via registerCustomEditor, preferably for =
specific fields to avoid conflicts with other fields of the type byte =
array or String.
=09
I consider this a good solution, more flexible than the hardcoded =
binding, but also cleaner than the PropertyEditor indirection with =
String parameters. Thanks for pointing at the issue again! Overriding =
PropertyEditor's setValue is generally a nice way to convert from =
non-String values to the required type; I didn't think of it at first, =
and I had to tweak BeanWrapperImpl a bit to allow for it. I hope you =
like the current solution too; does it fulfil your requirements now?
=09
Juergen
=09
=09
=09
-----Urspr ngliche Nachricht-----
Von: Trevor Cook [mailto:pr...@se...]
Gesendet: Mo 13.10.2003 22:22
An: jrgen h ller [werk3AT]; Spring Developers
Cc:
Betreff: RE: [Springframework-developer] Multipart File =
Handling
=20
=20
=09
<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>
=20
No problem dropping the String <> filename, I wasn't sure if =
that would be useful or not.
=20
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.
=20
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
=20
=20
=09
=
N=18HYXu=16w=1A+m>xZ=1AzMx'=17z{=08=1CB=105z??')rH?q=07z??J=07jgzx?G?q=07=
z?X?~zwX??=07jgz=20
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.525 / Virus Database: 322 - Release Date: 09/10/2003
|
|
From: <jue...@we...> - 2003-10-14 13:15:55
|
VGhlIHNlcGFyYXRpbmcgbGluZSBpbiBteSBvcmlnaW5hbCBtYWlsIGFjdHVhbGx5IG1lYW5zIGFi b3V0IDIgaG91cnMgaW5iZXR3ZWVuLi4uIGVub3VnaCB0aW1lIHRvIGRvIGludGVuc2UgY29kZSBj aGVja3MgYW5kIHNvbWUgc2VyaW91cyByZWNvbnNpZGVyYXRpb24uIEkgc3RpbGwgaGF2ZSB0byBz bWlsZSBteXNlbGYgd2hlbiBJIGxvb2sgYXQgdGhhdCBhZ2FpbiA7LSkNCg0KVGhlIGFyZ3VtZW50 cyBkaWRuJ3QgZmxpcCBjb21wbGV0ZWx5IEJUVywganVzdCBpbiB0ZXJtcyBvZiBkaXNtaXNzaW5n IFByb3BlcnR5RWRpdG9yIGFzIGEgd2hvbGU6IFdlIGRvbid0IHVzZSBpbnRlcm1lZGlhdGUgU3Ry aW5nIHJlcHJlc2VudGF0aW9ucyB2aWEgcmVxdWVzdC5nZXRQYXJhbWV0ZXIgYW55bW9yZSwgd2hp Y2ggd2FzIG15IG1haW4gaW50ZW50Lg0KDQpJJ20gZ2xhZCB0aGF0IHlvdSdyZSBoYXBweSB3aXRo IGl0IG5vdy4gSSdtIHRvbywgYWN0dWFsbHkhIFRoYXQncyB0aGUgZ3JlYXQgdGhpbmcgYWJvdXQg d29ya2luZyBpbiBhIHRlYW0sIGV2ZW4gaWYgImp1c3QiIGEgZGlzdHJpYnV0ZWQgb25lOiBNdWx0 aXBsZSBwb2ludHMgb2YgdmlldyBjYW4gY3JlYXRlIG11Y2ggYmV0dGVyIHNvbHV0aW9ucyB0aGFu IGEgc2luZ2xlIG1pbmQgZXZlciBjb3VsZC4NCg0KSnVzdCBvdXQgb2YgY3VyaW9zaXR5OiBXaGF0 IGFkZGl0aW9uYWwgZnVuY3Rpb25hbGl0eSBkaWQgeW91IGFkZCB0byBDb21tb25zTXVsdGlwYXJ0 UmVzb2x2ZXI/DQoNCkp1ZXJnZW4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogVHJldm9yIENvb2sgW21haWx0bzpwcmlzZTAzQHNlbnRleC5uZXRdDQpTZW50OiBUdWVzZGF5 LCBPY3RvYmVyIDE0LCAyMDAzIDM6MDYgUE0NClRvOiBqw7xyZ2VuIGjDtmxsZXIgW3dlcmszQVRd OyBTcHJpbmcgRGV2ZWxvcGVycw0KU3ViamVjdDogUkU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxv cGVyXSBNdWx0aXBhcnQgRmlsZSBIYW5kbGluZw0KDQoNCkl0IGlzIGludGVyZXN0aW5nIHNlZWlu ZyB5b3VyIGFyZ3VtZW50cyBmbGlwIDE4MCBkZWdyZWVzIGluIGEgZmV3IHBhcmFncmFwaHMsIGJ1 dCB5b3UncmUgbm90IGFsb25lIHRoZXJlLiAgSSBmaW5kIHRoZSBzYW1lIHRoaW5nLCB0aGF0IHRh bGtpbmcgaGVscHMgbWUgZmluZCBteSBvd24gc29sdXRpb25zLg0KDQpBcyBmYXIgYXMgdGhlIGlt cGxlbWVudGF0aW9uIGdvZXMsIHRoZSBjaGFuZ2VzIGFyZSBwZXJmZWN0LiAgSXQncyBhIGxvdCBj bGVhbmVyIHRoYW4gbXkgb3JpZ2luYWwgdmVyc2lvbiAobm8gY291cGxpbmcgd2l0aCBEaXNwYXRj aGVyU2VydmxldCBvciBwcm9wZXJ0eSBlZGl0b3JzKSwgYnV0IHdlIHN0aWxsIGhhdmUgdGhlIGJl bmVmaXQgb2YgY3VzdG9tIHByb3BlcnR5IGhhbmRsaW5nLg0KDQpJJ3ZlIG1pZ3JhdGVkIG91ciBw cm9qZWN0IGZyb20gdGhlIG9yaWdpbmFsIG11bHRpcGFydCB0byB0aGUgbmV3IHZlcnNpb24sIGFu ZCBldmVyeXRoaW5nIHdvcmtzIGdyZWF0LiAgTXkgY29kZSB1c2VzICJzdGFuZGFyZCIgaGFuZGxp bmcgKGJ5dGVbXSBhbmQgTXVsdGlwYXJ0RmlsZSkgYXMgd2VsbCBhcyB0aGUgY3VzdG9tIHByb3Bl cnR5IGVkaXRvcnMuICBJJ3ZlIGFsc28gc3ViY2xhc3NlZCB0aGUgQ29tbW9uc011bHRpcGFydFJl c29sdmVyIHRvIHByb3ZpZGUgc29tZSBhZGRpdGlvbmFsIGZ1bmN0aW9uYWxpdHkgaW4gb3VyIGFw cCwgYW5kIHRoYXQgd29ya3MgcGVyZmVjdCBhcyB3ZWxsLg0KDQpJIHRoaW5rIHdlIGhhdmUgYSB3 aW5uZXIgOikNCg0KVHJldm9yIEQuIENvb2sNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXSBbbWFpbHRvOmp1ZXJnZW4uaG9lbGxl ckB3ZXJrM2F0LmNvbV0NClNlbnQ6IE9jdG9iZXIgMTQsIDIwMDMgMToxMyBBTQ0KVG86IGrDvHJn ZW4gaMO2bGxlciBbd2VyazNBVF07IFRyZXZvciBDb29rOyBTcHJpbmcgRGV2ZWxvcGVycw0KU3Vi amVjdDogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBNdWx0aXBhcnQgRmlsZSBIYW5k bGluZw0KDQoNClAuUy46IEZ1bm55IGhvdyB0aGUgZGlyZWN0aW9uIG9mIGFuIG93biBhcmd1bWVu dCBjYW4gY2hhbmdlIGluIHRoZSBjb3Vyc2Ugb2YgYSBzaW5nbGUgZW1haWwgOy0pIE9mIGNvdXJz ZSwgSSB3YXMgdGFsa2luZyBhYm91dCBQcm9wZXJ0eUVkaXRvcidzIHNldEFzVGV4dCAoYW5kIHRo ZSBpbmRpcmVjdGlvbiB3aXRoIFN0cmluZyB2YWx1ZXMgdGhhdCBtYXRjaCBmaWVsZCBuYW1lcykg aW4gdGhlIGZpcnN0IHBhcmFncmFwaCwgYW5kIGhhdmVuJ3QgaGFkIHJlYWxpemVkIGF0IHRoYXQg dGltZSB0aGF0IHRoZXJlIHdhcyB0aGUgY29tcGxldGVseSBkaWZmZXJlbnQgc2V0VmFsdWUgb3B0 aW9uIHRvby4uLg0KIA0KSnVlcmdlbg0KIA0KDQoJLS0tLS1VcnNwcm5nbGljaGUgTmFjaHJpY2h0 LS0tLS0gDQoJVm9uOiBqIHJnZW4gaGxsZXIgW3dlcmszQVRdIA0KCUdlc2VuZGV0OiBEaSAxNC4x MC4yMDAzIDAxOjI2IA0KCUFuOiBUcmV2b3IgQ29vazsgU3ByaW5nIERldmVsb3BlcnMgDQoJQ2M6 IA0KCUJldHJlZmY6IFJlOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gTXVsdGlwYXJ0IEZp bGUgSGFuZGxpbmcNCgkNCgkNCg0KCVRyZXZvciwNCgkNCglTb3JyeSBpZiBJJ3ZlIGJlZW4gYSBi aXQgZWFnZXIgaW4gdGVybXMgb2YgZ2V0dGluZyByaWQgb2YgdGhlIFByb3BlcnR5RWRpdG9yIHN0 dWZmIGZvciBtdWx0aXBhcnQgZmlsZXMuIEkgc3Ryb25nbHkgYmVsaWV2ZSB0aGF0IHRoZSBKYXZh QmVhbnMgUHJvcGVydHlFZGl0b3IgaXMgbm90IGFwcHJvcHJpYXRlIGZvciBtdWx0aXBhcnQgZmls ZXMgdGhvdWdoLCBhcyBpdCBpcyBhYm91dCBjb252ZXJ0aW5nICpTdHJpbmcqIHBhcmFtZXRlcnMg dG8gb3RoZXIgdHlwZXMuIFRoaXMgaXMgZmluZSBmb3Igc3RhbmRhcmQgU2VydmxldFJlcXVlc3Qg cGFyYW1ldGVycyB0aGF0IGNvbWUgaW4gYXMgU3RyaW5nIHZhbHVlcyBhbmQgbmVlZCB0byBiZSBi b3VuZCB0byBhcmJpdHJhcnkgcHJvcGVydGllcyBvZiBjb21tYW5kIG9iamVjdHMuIE11bHRpcGFy dCBmaWxlcyBvbiB0aGUgb3RoZXIgaGFuZCBhcmUgYnkgdGhlaXIgdmVyeSBuYXR1cmUgY29tcGxl eCBvYmplY3RzOyB0aGV5IGRvIG5vdCBoYXZlIGEgbmF0dXJhbCBTdHJpbmcgcmVwcmVzZW50YXRp b24uDQoJDQoJVGhlIHByZXZpb3VzIG1lY2hhbmlzbSBvZiBiaW5kaW5nIG11bHRpcGFydCBmaWxl cyB2aWEgUHJvcGVydHlFZGl0b3IgcmVxdWlyZWQgTXVsdGlwYXJ0SHR0cFNlcnZsZXRSZXF1ZXN0 J3MgZ2V0UGFyYW1ldGVyIG1ldGhvZCB0byByZXR1cm4gdGhlIGZpZWxkIG5hbWUgYXMgdmFsdWUg YSBsYSBnZXRQYXJhbWV0ZXIoIm15ZmllbGQiKSAtPiAibXlmaWVsZCIsIHNvIHRoYXQgYSBQcm9w ZXJ0eUVkaXRvciB0aGF0IGNhbiBqdXN0IHNlZSB0aGUgdmFsdWUgd291bGQgYmUgYWJsZSB0byBp ZGVudGlmeSB0aGUgZmllbGQgbmFtZSBhbmQgaW52b2tlIE11bHRpcGFydEh0dHBTZXJ2bGV0UmVx dWVzdCdzIGdldEZpbGUoIm15ZmllbGQiKSB0byByZXR1cm4gdGhlIE11bHRpcGFydEZpbGUgaW5z dGFuY2UuIFRoaXMgKmlzKiBhIHdvcmthcm91bmQsIGFzIGl0IGlzIG5vdCBhdCBhbGwgbmF0dXJh bCB0byBoYXZlIGdldFBhcmFtZXRlciByZXR1cm4gdGhlIGZpZWxkIG5hbWUgYXMgdmFsdWUgaW4g Y2FzZSBvZiBhIG11bHRpcGFydCBmaWxlLg0KCQ0KCVNlcnZsZXRSZXF1ZXN0RGF0YUJpbmRlciBp cyBub3QgYSBiYWQgcGxhY2UgZm9yIGJpbmRpbmcgbXVsdGlwYXJ0IGZpbGVzLCBnaXZlbiB0aGF0 IG91ciBNdWx0aXBhcnRIdHRwU2VydmxldFJlcXVlc3QgaXMgYSBnZW5lcmljIGludGVyZmFjZSB0 aGF0IHJlc2lkZXMgaW4gdGhlIG5vbi1EaXNwYXRjaGVyU2VydmxldC1zcGVjaWZpYyB3ZWIubXVs dGlwYXJ0IHBhY2thZ2Ugbm93LiBJIGFncmVlIHRoYXQgaXQgaXNuJ3QgZ2VuZXJhbGx5IHByZWZl cmFibGUgdG8gaGFyZGNvZGUgYmluZGluZyBvcHRpb25zLCBidXQgSSd2ZSBpbml0aWFsbHkgZmVs dCB0aGF0IHRoZXJlIGFyZW4ndCBhbnkgb3RoZXIgbWVhbmluZ2Z1bCBjb252ZXJzaW9ucyB0aGFu IGEgTXVsdGlwYXJ0RmlsZSBpdHNlbGYgb3IgYSBieXRlW10gYXMgdmFsdWUgb2YgYSBjb21tYW5k IGJlYW4gcHJvcGVydHkuIE5vdGUgdGhhdCB5b3UgY2FuIGFsd2F5cyBvdmVycmlkZSBCYXNlQ29t bWFuZENvbnRyb2xsZXIncyBvbkJpbmRBbmRWYWxpZGF0ZSB0byBwZXJmb3JtICpjdXN0b20qIGJp bmRpbmcuDQoJDQoJLS0tLS0NCgkNCglPbiBzZWNvbmQgdGhvdWdodCwgSSBhZ3JlZSB0aGF0IGEg cGx1Z2dhYmxlIGNvbnZlcnNpb24gbWVjaGFuaXNtIGlzIHByZWZlcmFibGUuIEkndmUganVzdCBy ZXdvcmtlZCB0aGUgbXVsdGlwYXJ0IGJpbmRpbmcgaW50byBhIFByb3BlcnR5RWRpdG9yIG1lY2hh bmlzbSBhZ2FpbiwgYnV0IHdpdGggYSBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb24gcGF0dGVybjog U2VydmxldFJlcXVlc3REYXRhQmluZGVyIHNpbXBseSBiaW5kcyB0aGUgZmlsZSBtYXAgcmV0dXJu ZWQgYnkgTXVsdGlwYXJ0SHR0cFNlcnZsZXRSZXF1ZXN0LmdldEZpbGVNYXAgYXMgcHJvcGVydHkg dmFsdWVzLiBUaGlzIG1lYW5zIHRoYXQgYmVhbiBwcm9wZXJ0aWVzIG9mIHR5cGUgTXVsdGlwYXJ0 RmlsZSBjYW4gYmUgcG9wdWxhdGVkIGRpcmVjdGx5LCB3aXRob3V0IGNvbnZlcnNpb24uIE90aGVy IHR5cGVzIGdvIHRocm91Z2ggdGhlIFByb3BlcnR5RWRpdG9yIG1lY2hhbmlzbSwgYnV0IHZpYSBj YWxsaW5nIHNldFZhbHVlKE9iamVjdCkgaW5zdGVhZCBvZiBzZXRBc1RleHQoU3RyaW5nKS4NCgkN CglCeXRlQXJyYXlNdWx0aXBhcnRGaWxlRWRpdG9yIGFuZCBTdHJpbmdNdWx0aXBhcnRGaWxlRWRp dG9yIGltcGxlbWVudCBzZXRWYWx1ZSB0byB0cmFuc2Zvcm0gdGhlIGdpdmVuIE11bHRpcGFydEZp bGUgaW5zdGFuY2UgaW50byBlaXRoZXIgYSBieXRlIGFycmF5IG9yIGEgU3RyaW5nLCB0aGUgbGF0 dGVyIHdpdGggY29uZmlndXJhYmxlIGNoYXJzZXQuIE5vdGUgdGhhbiBub25lIG9mIHRoZXNlIG5l ZWRzIGEgTXVsdGlwYXJ0SHR0cFNlcnZsZXRSZXF1ZXN0OiBUaGV5IHJlY2VpdmUgdGhlIE11bHRp cGFydEZpbGUgaW5zdGFuY2VzIGJvdW5kIGFzIHByb3BlcnR5IHZhbHVlcyBieSBTZXJ2bGV0UmVx dWVzdERhdGFCaW5kZXIuIFRob3NlIHR3byBjdXN0b20gZWRpdG9ycyBuZWVkIHRvIGJlIHJlZ2lz dGVyZWQgd2l0aCBTZXJ2bGV0UmVxdWVzdERhdGFCaW5kZXIgdmlhIHJlZ2lzdGVyQ3VzdG9tRWRp dG9yLCBwcmVmZXJhYmx5IGZvciBzcGVjaWZpYyBmaWVsZHMgdG8gYXZvaWQgY29uZmxpY3RzIHdp dGggb3RoZXIgZmllbGRzIG9mIHRoZSB0eXBlIGJ5dGUgYXJyYXkgb3IgU3RyaW5nLg0KCQ0KCUkg Y29uc2lkZXIgdGhpcyBhIGdvb2Qgc29sdXRpb24sIG1vcmUgZmxleGlibGUgdGhhbiB0aGUgaGFy ZGNvZGVkIGJpbmRpbmcsIGJ1dCBhbHNvIGNsZWFuZXIgdGhhbiB0aGUgUHJvcGVydHlFZGl0b3Ig aW5kaXJlY3Rpb24gd2l0aCBTdHJpbmcgcGFyYW1ldGVycy4gVGhhbmtzIGZvciBwb2ludGluZyBh dCB0aGUgaXNzdWUgYWdhaW4hIE92ZXJyaWRpbmcgUHJvcGVydHlFZGl0b3IncyBzZXRWYWx1ZSBp cyBnZW5lcmFsbHkgYSBuaWNlIHdheSB0byBjb252ZXJ0IGZyb20gbm9uLVN0cmluZyB2YWx1ZXMg dG8gdGhlIHJlcXVpcmVkIHR5cGU7IEkgZGlkbid0IHRoaW5rIG9mIGl0IGF0IGZpcnN0LCBhbmQg SSBoYWQgdG8gdHdlYWsgQmVhbldyYXBwZXJJbXBsIGEgYml0IHRvIGFsbG93IGZvciBpdC4gSSBo b3BlIHlvdSBsaWtlIHRoZSBjdXJyZW50IHNvbHV0aW9uIHRvbzsgZG9lcyBpdCBmdWxmaWwgeW91 ciByZXF1aXJlbWVudHMgbm93Pw0KCQ0KCUp1ZXJnZW4NCgkNCgkNCgkNCgkgICAgICAgIC0tLS0t VXJzcHIgbmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KCSAgICAgICAgVm9uOiBUcmV2b3IgQ29vayBb bWFpbHRvOnByaXNlMDNAc2VudGV4Lm5ldF0NCgkgICAgICAgIEdlc2VuZGV0OiBNbyAxMy4xMC4y MDAzIDIyOjIyDQoJICAgICAgICBBbjoganJnZW4gaCBsbGVyIFt3ZXJrM0FUXTsgU3ByaW5nIERl dmVsb3BlcnMNCgkgICAgICAgIENjOg0KCSAgICAgICAgQmV0cmVmZjogUkU6IFtTcHJpbmdmcmFt ZXdvcmstZGV2ZWxvcGVyXSBNdWx0aXBhcnQgRmlsZSBIYW5kbGluZw0KCSAgICAgICANCgkgICAg ICAgDQoJDQoJICAgICAgICA8anVlcmdlbj4NCgkgICAgICAgIEZ1cnRoZXJtb3JlLCBJJ3ZlIGRy b3BwZWQgdGhlIHByZXZpb3VzIFByb3BlcnR5RWRpdG9ycyBzdXBwb3J0LCBhbmQgdGhlIGFzc29j aWF0ZWQgcmVxdWlyZW1lbnQgZm9yIGZpbGUgcGFyYW1ldGVycyBoYXZpbmcgdG8gYmUgYXZhaWxh YmxlIGFzIG5vcm1hbCBwYXJhbWV0ZXJzIHdpdGggdGhlIGZpZWxkIG5hbWUgYXMgdmFsdWUuIFRo YXQgc2VlbWVkIGxpa2UgYSB3b3JrYXJvdW5kOyBpbnN0ZWFkLCBJJ3ZlIGFkZGVkIGV4cGxpY2l0 IGRldGVjdGlvbiB0byBTZXJ2bGV0UmVxdWVzdERhdGFCaW5kZXIsIHdoaWNoIGlzIG5vdyBhYmxl IHRvIGJpbmQgZmlsZSBwYXJhbWV0ZXJzIGFzIE11bHRpcGFydEZpbGUgb3IgYnl0ZVtdLCBkZXBl bmRpbmcgb24gdGhlIHR5cGUgb2YgdGhlIHRhcmdldCBiZWFuIHByb3BlcnR5LiBJJ3ZlIG5vdCBy ZWludHJvZHVjZWQgYmluZGluZyB0aGUgb3JpZ2luYWwgZmlsZSBuYW1lIHRvIGEgU3RyaW5nIHBy b3BlcnR5LCBhcyBJIGNhbid0IHNlZSB0aGUgdmFsdWUgb2YgdGhhdCBmZWF0dXJlLg0KCSAgICAg ICAgPC9qdWVyZ2VuPg0KCSAgICAgICANCgkgICAgICAgIE5vIHByb2JsZW0gZHJvcHBpbmcgdGhl IFN0cmluZyA8PiBmaWxlbmFtZSwgSSB3YXNuJ3Qgc3VyZSBpZiB0aGF0IHdvdWxkIGJlIHVzZWZ1 bCBvciBub3QuDQoJICAgICAgIA0KCSAgICAgICAgSSBkbyBoYXZlIGEgcHJvYmxlbSB3aXRoIGRy b3BwaW5nIHRoZSBQcm9wZXJ0eUVkaXRvcnMgc3VwcG9ydCwgc2luY2UgaW4gbXkgbWluZCBpdCBy ZW1vdmVzIGZsZXhpYmlsaXR5IGFuZCBjb25zaXN0ZW5jeS4NCgkgICAgICAgDQoJICAgICAgICBU cmVhdGluZyBhbGwgdGhlIGRhdGEgKHNpbXBsZSB0ZXh0IGZpZWxkcyBvciBmaWxlcykgYXMgcGFy YW1ldGVycyBzZWVtcyB0byBtYWtlIGEgbG90IG1vcmUgc2Vuc2UgdG8gbWUgc2luY2UgeW91IGNh biB0aGVuIHRyZWF0IGV2ZXJ5IHBpZWNlIG9mIGRhdGEgdGhlIHNhbWUgKGluc3RlYWQgb2YgaGF2 aW5nIHRvIGhhbmRsZSBwYXJhbWV0ZXJzIGFuZCBmaWxlcyBzZXBlcmF0ZWx5KS4gIElmIHRoZSBp bXBsZW1lbnRhdGlvbiB3YXMgYSBsaXR0bGUgY2x1bXN5IEkgYXBvbG9naXplLCBidXQgdGhlIGNv bmNlcHQgd2FzIG5vdCBhIHdvcmthcm91bmQgYnV0IGEgZ29hbCB0byBhbGxvdyB0aGUgdXNlciB0 byBiZSBhYmxlIHRvIHRyZWF0IGFsbCBkYXRhIGluIHRoZSBzYW1lIG1hbm5lci4NCgkgICAgICAg DQoJICAgICAgICBUaGUgaXNzdWUgb2YgZmxleGliaWxpdHkgaXMgZHVlIHRvIHRoZSAiZXhwbGlj aXQgZGV0ZWN0aW9uIHRvIFNlcnZsZXRSZXF1ZXN0RGF0YUJpbmRlciIuICBJbiB0aGUgcHJldmlv dXMgaW1wbGVtZW50YXRpb24gYW5kIHRoZSBjdXJyZW50IG9uZSwgZmlsZXMgd2VyZSBhdXRvbWF0 aWNhbGx5IGJvdW5kIHRvIGFuIG9iamVjdCBiYXNlZCBvbiB0aGUgdGFyZ2V0IHByb3BlcnRpZXMg dHlwZS4gIFRoZSBkaWZmZXJlbmNlIHdhcyB0aGF0IHlvdSBjb3VsZCBvdmVycmlkZSBpdCB3aXRo IGEgY3VzdG9tIHByb3BlcnR5IGVkaXRvciAoaW4gdGhlIEJhc2VDb21tYW5kQ29udHJvbGxlciBp bml0QmluZGVyIG1ldGhvZCwgZm9yIGV4YW1wbGUpLiAgVW5kZXIgdGhlIGN1cnJlbnQgaW1wbGVt ZW50YXRpb24sIHRoZXJlIGlzIG5vIHdheSB0byBvdmVycmlkZSBob3cgdGhlIGZpbGUgaXMgYXR0 YWNoZWQgdG8gdGhlIGJlYW4uICBEbyB5b3UgKG9yIGFueWJvZHkgZWxzZSkgaGF2ZSBhbnkgc3Vn Z2VzdGlvbnMgb24gaG93IHRvIG92ZXJyaWRlIHRoZSBkZWZhdWx0IFNwcmluZyBoYW5kbGluZyAo Y3VycmVudGx5IGhhcmQtY29kZWQgaW4gU2VydmxldFJlcXVlc3REYXRhQmluZGVyKSwgb3IgYW55 IGlkZWFzIG9mIGhvdyB0byBjaGFuZ2UgdGhlIGltcGxlbWVudGF0aW9uIHRvIGFsbG93IHRoaXMg Y3VzdG9tIGhhbmRsaW5nPw0KCSAgICAgICANCgkgICAgICAgIFRyZXZvciBELiBDb29rDQoJICAg ICAgIA0KCSAgICAgICANCgkNCglOGEhZWHUWdxorbT54Whp6TXgnF3p7CBxCEDV6Pz8nKXJIP3EH ej8/SgdqZ3p4P0c/cQd6P1g/fnp3WD8/B2pneiANCg0KDQotLS0NCkluY29taW5nIG1haWwgaXMg Y2VydGlmaWVkIFZpcnVzIEZyZWUuDQpDaGVja2VkIGJ5IEFWRyBhbnRpLXZpcnVzIHN5c3RlbSAo aHR0cDovL3d3dy5ncmlzb2Z0LmNvbSkuDQpWZXJzaW9uOiA2LjAuNTI1IC8gVmlydXMgRGF0YWJh c2U6IDMyMiAtIFJlbGVhc2UgRGF0ZTogMDkvMTAvMjAwMw0KDQo= |
|
From: Trevor C. <pr...@se...> - 2003-10-14 13:32:50
|
Not "just a distributed one", this team honestly is alot better than =
that (and you personally have put a ton into this thing, which I am =
indebted to you for). At work I only get to choose the best and =
brightest within commuting distance, here we have a global pool. Our =
other advantage is that nobody has to help (paycheque, etc.), so it's =
all pride and passion. Plus no interruptions when somebody wants to =
borrow a stapler, etc. (fill in all your favorite Dilbert cartoons here =
:) ).
Anyway, the additional functionality is a bean which determines the =
"MaximumFileSize" based on the user who is logged in (using the standard =
"request.getUserPrincipal()") . Our app has multiple roles, and we =
allow "small" upload sizes to the public, variable sizes to different =
business partners (for product lists, etc.), and unlimited sizes to the =
administrators (us and our clients). It requires creating a =
"DiskFileUpload" for every multipart request, but it gives us a lot of =
flexibility.
Trevor
-----Original Message-----
From: j=C3=BCrgen h=C3=B6ller [werk3AT] =
[mailto:jue...@we...]
Sent: October 14, 2003 9:14 AM
To: Trevor Cook; Spring Developers
Subject: RE: [Springframework-developer] Multipart File Handling
The separating line in my original mail actually means about 2 hours =
inbetween... enough time to do intense code checks and some serious =
reconsideration. I still have to smile myself when I look at that again =
;-)
The arguments didn't flip completely BTW, just in terms of dismissing =
PropertyEditor as a whole: We don't use intermediate String =
representations via request.getParameter anymore, which was my main =
intent.
I'm glad that you're happy with it now. I'm too, actually! That's the =
great thing about working in a team, even if "just" a distributed one: =
Multiple points of view can create much better solutions than a single =
mind ever could.
Just out of curiosity: What additional functionality did you add to =
CommonsMultipartResolver?
Juergen
-----Original Message-----
From: Trevor Cook [mailto:pr...@se...]
Sent: Tuesday, October 14, 2003 3:06 PM
To: jrgen h ller [werk3AT]; Spring Developers
Subject: RE: [Springframework-developer] Multipart File Handling
It is interesting seeing your arguments flip 180 degrees in a few =
paragraphs, but you're not alone there. I find the same thing, that =
talking helps me find my own solutions.
As far as the implementation goes, the changes are perfect. It's a lot =
cleaner than my original version (no coupling with DispatcherServlet or =
property editors), but we still have the benefit of custom property =
handling.
I've migrated our project from the original multipart to the new =
version, and everything works great. My code uses "standard" handling =
(byte[] and MultipartFile) as well as the custom property editors. I've =
also subclassed the CommonsMultipartResolver to provide some additional =
functionality in our app, and that works perfect as well.
I think we have a winner :)
Trevor D. Cook
-----Original Message-----
From: jrgen h ller [werk3AT] [mailto:jue...@we...]
Sent: October 14, 2003 1:13 AM
To: jrgen h ller [werk3AT]; Trevor Cook; Spring Developers
Subject: Re: [Springframework-developer] Multipart File Handling
P.S.: Funny how the direction of an own argument can change in the =
course of a single email ;-) Of course, I was talking about =
PropertyEditor's setAsText (and the indirection with String values that =
match field names) in the first paragraph, and haven't had realized at =
that time that there was the completely different setValue option too...
=20
Juergen
=20
-----Ursprngliche Nachricht-----=20
Von: j rgen hller [werk3AT]=20
Gesendet: Di 14.10.2003 01:26=20
An: Trevor Cook; Spring Developers=20
Cc:=20
Betreff: Re: [Springframework-developer] Multipart File Handling
=09
=09
Trevor,
=09
Sorry if I've been a bit eager in terms of getting rid of the =
PropertyEditor stuff for multipart files. I strongly believe that the =
JavaBeans PropertyEditor is not appropriate for multipart files though, =
as it is about converting *String* parameters to other types. This is =
fine for standard ServletRequest parameters that come in as String =
values and need to be bound to arbitrary properties of command objects. =
Multipart files on the other hand are by their very nature complex =
objects; they do not have a natural String representation.
=09
The previous mechanism of binding multipart files via PropertyEditor =
required MultipartHttpServletRequest's getParameter method to return the =
field name as value a la getParameter("myfield") -> "myfield", so that a =
PropertyEditor that can just see the value would be able to identify the =
field name and invoke MultipartHttpServletRequest's getFile("myfield") =
to return the MultipartFile instance. This *is* a workaround, as it is =
not at all natural to have getParameter return the field name as value =
in case of a multipart file.
=09
ServletRequestDataBinder is not a bad place for binding multipart =
files, given that our MultipartHttpServletRequest is a generic interface =
that resides in the non-DispatcherServlet-specific web.multipart package =
now. I agree that it isn't generally preferable to hardcode binding =
options, but I've initially felt that there aren't any other meaningful =
conversions than a MultipartFile itself or a byte[] as value of a =
command bean property. Note that you can always override =
BaseCommandController's onBindAndValidate to perform *custom* binding.
=09
-----
=09
On second thought, I agree that a pluggable conversion mechanism is =
preferable. I've just reworked the multipart binding into a =
PropertyEditor mechanism again, but with a different implementation =
pattern: ServletRequestDataBinder simply binds the file map returned by =
MultipartHttpServletRequest.getFileMap as property values. This means =
that bean properties of type MultipartFile can be populated directly, =
without conversion. Other types go through the PropertyEditor mechanism, =
but via calling setValue(Object) instead of setAsText(String).
=09
ByteArrayMultipartFileEditor and StringMultipartFileEditor implement =
setValue to transform the given MultipartFile instance into either a =
byte array or a String, the latter with configurable charset. Note than =
none of these needs a MultipartHttpServletRequest: They receive the =
MultipartFile instances bound as property values by =
ServletRequestDataBinder. Those two custom editors need to be registered =
with ServletRequestDataBinder via registerCustomEditor, preferably for =
specific fields to avoid conflicts with other fields of the type byte =
array or String.
=09
I consider this a good solution, more flexible than the hardcoded =
binding, but also cleaner than the PropertyEditor indirection with =
String parameters. Thanks for pointing at the issue again! Overriding =
PropertyEditor's setValue is generally a nice way to convert from =
non-String values to the required type; I didn't think of it at first, =
and I had to tweak BeanWrapperImpl a bit to allow for it. I hope you =
like the current solution too; does it fulfil your requirements now?
=09
Juergen
=09
=09
=09
-----Urspr ngliche Nachricht-----
Von: Trevor Cook [mailto:pr...@se...]
Gesendet: Mo 13.10.2003 22:22
An: jrgen h ller [werk3AT]; Spring Developers
Cc:
Betreff: RE: [Springframework-developer] Multipart File =
Handling
=20
=20
=09
<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>
=20
No problem dropping the String <> filename, I wasn't sure if =
that would be useful or not.
=20
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.
=20
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
=20
=20
=09
=
N=18HYXu=16w=1A+m>xZ=1AzMx'=17z{=08=1CB=105z??')rH?q=07z??J=07jgzx?G?q=07=
z?X?~zwX??=07jgz=20
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.525 / Virus Database: 322 - Release Date: 09/10/2003
|
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-09-28 12:18:25
|
Will there be a way - using this solution - to bind the file using a = propertyeditor (or something else maybe), just as any other command = object is filled with parameters from the request. For consistency, I = think that's pretty important to be consistent. Furthermore I think it's pretty cool if the fileupload could be fixed = before the 1.0 release! Good thing! Alef -----Oorspronkelijk bericht----- Van: spr...@li... = [mailto:spr...@li...] Namens = j=C3=BCrgen h=C3=B6ller [werk3AT] Verzonden: Sunday, September 28, 2003 12:33 PM Aan: Trevor Cook; Spring Developers Onderwerp: Re: [Springframework-developer] Multipart File Handling Hi Trevor, =20 A MultipartResolver interface with implementations for Commons = FileUpload and COS is fine with me - it just hadn't high priority since = I proposed it half a year ago. As I still have a pretty clear picture of = the issues, I'll be happy to review your code once you've checked it in. = As this should be pretty straightforward, let's try to include this = already in 1.0 M2 - at least with a Commons FileUpload implementation. =20 BTW, in contrast to COS, Commons FileUpload doesn't provide a Servlet = 2.3 filter anyway. This means that there would be some infrastructure = code to write for that use case too, even when using standard filters. A = simple but convenient Spring solution would definitely be a good thing. =20 Juergen =20 =20 =20 -----Urspr=C3=BCngliche Nachricht-----=20 Von: Trevor Cook [mailto:pr...@se...]=20 Gesendet: Sa 27.09.2003 19:35=20 An: Spring Developers=20 Cc:=20 Betreff: [[W3-SPAM]] - [Springframework-developer] Multipart File = Handling - Email found in subject =09 =09 First some history: http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279 http://sourceforge.net/mailarchive/message.php?msg_id=3D5175276 = http://sourceforge.net/mailarchive/forum.php?thread_id=3D3125561&forum_id= =3D3028 7 http://sourceforge.net/mailarchive/message.php?msg_id=3D6062288 =09 To address a few things Juergen mentioned previously. =09 >> a less intrusive way would be to wrap the HttpServletRequest via a = filter I personally don't like the filter approach, at least for the = framework. It requires additional setup for the user (in the web.xml file) and might = be less understandable since our normal strategy so far has been with = resolvers inside the servlet. =09 >>we would need to find concrete requirements for this We have numerous uses for file upload handling. We have a public photo contest where users can upload fotos. We have special access for = suppliers to upload product files (csv) which we then add in to our ordering = system. Finally, we have a web administration interface which allows our client = to upload files to the website so they can be downloaded. I think that including this support (multipart handling) is a no-brainer. =09 Basically, I have used COS exclusively in our projects, but I don't = think that's easy for Spring to use (due to the licensing). I would simply = code this according to Spring norms using an interface and a default version using Commons FileUpload. Later, if somebody wants to create a cos = version we can (but to be honest, if we have a working, integrated solution I'm = not sure that is necessary - at least not in the Spring framework). = Basically, provide hooks and a default implementation, and allow users to adopt as necessary. =09 In our project we had modified the AbstractController and put the code = into it to handle the multipart processing, returning a wrapped HttpServletRequest through the handlers. This is very similiar to = Juergen's outline = (http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279). =09 Since we are migrating to the current Spring codebase, I need to move = our multipart handling code. The main question is whether we keep it internally, or place it into Spring. I propose modifying org.springframework.web.servlet.DispatcherServlet to have a "MultipartResolver". In the DispatcherServlet, the resolver would be = called to wrap the request in doService immediately before getHandler(request) = - currently line 351, and then called to do any cleanup immediately = before exiting the doService method. =09 I have about 2/3 of the code already written, and I will be writing the = rest between now and Monday. Does this strategy sound appropriate for = Spring (meaning should I commit it to the Spring codebase) when it's finished? =09 Trevor D. Cook Interprise Software =09 =09 =09 ------------------------------------------------------- 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 =09 N=18 Xu)=19Y g =17 HzGJ jg=EE=A2=B9z=ED=BD=89=ED=B7=99x=CB=A6 G =CB=B2q = z m?X (=1E~zw X b=CB=9D? jg=EB=B0=A2=1Dz=ED=BD=96=ED=B2=97 |
|
From: Rod J. <rod...@in...> - 2003-09-28 12:35:46
|
>Will there be a way - using this solution - to bind the file using a propertyeditor (or something else maybe), just as any other command object is filled with parameters from the request. For consistency, I think that's pretty important to be consistent. Now that _would_ be nice. |
|
From: Trevor C. <pr...@se...> - 2003-09-28 14:37:27
|
>>Furthermore I think it's pretty cool if the fileupload could be fixed = before the 1.0 release! Good thing! I'm working under "business deadlines", so I actually need to have this = stuff done by Wednesday night, so it will definately be in by 1.0 :) Trevor |
|
From: Trevor C. <pr...@se...> - 2003-09-28 14:40:05
|
Juergen - Glad that you'll look at it. Based on the previous emails you = seem to have a pretty good handle on this, and my ideas are fairly close = to yours. Are you back from vacation now, or still checking remotely? As far as the filter goes, that is definately a possiblity to add later = (possibly even for 1.0) but not something I'll be able to look at right = away. However, it could use the same code, so it shouldn't be too = difficult. Trevor -----Original Message----- From: j=C3=BCrgen h=C3=B6ller [werk3AT] = [mailto:jue...@we...] Sent: September 28, 2003 6:33 AM To: Trevor Cook; Spring Developers Subject: Re: [Springframework-developer] Multipart File Handling Hi Trevor, =20 A MultipartResolver interface with implementations for Commons = FileUpload and COS is fine with me - it just hadn't high priority since = I proposed it half a year ago. As I still have a pretty clear picture of = the issues, I'll be happy to review your code once you've checked it in. = As this should be pretty straightforward, let's try to include this = already in 1.0 M2 - at least with a Commons FileUpload implementation. =20 BTW, in contrast to COS, Commons FileUpload doesn't provide a Servlet = 2.3 filter anyway. This means that there would be some infrastructure = code to write for that use case too, even when using standard filters. A = simple but convenient Spring solution would definitely be a good thing. =20 Juergen =20 =20 =20 -----Ursprngliche Nachricht-----=20 Von: Trevor Cook [mailto:pr...@se...]=20 Gesendet: Sa 27.09.2003 19:35=20 An: Spring Developers=20 Cc:=20 Betreff: [[W3-SPAM]] - [Springframework-developer] Multipart File = Handling - Email found in subject =09 =09 First some history: http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279 http://sourceforge.net/mailarchive/message.php?msg_id=3D5175276 = http://sourceforge.net/mailarchive/forum.php?thread_id=3D3125561&forum_id= =3D3028 7 http://sourceforge.net/mailarchive/message.php?msg_id=3D6062288 =09 To address a few things Juergen mentioned previously. =09 >> a less intrusive way would be to wrap the HttpServletRequest via a = filter I personally don't like the filter approach, at least for the = framework. It requires additional setup for the user (in the web.xml file) and might = be less understandable since our normal strategy so far has been with = resolvers inside the servlet. =09 >>we would need to find concrete requirements for this We have numerous uses for file upload handling. We have a public photo contest where users can upload fotos. We have special access for = suppliers to upload product files (csv) which we then add in to our ordering = system. Finally, we have a web administration interface which allows our client = to upload files to the website so they can be downloaded. I think that including this support (multipart handling) is a no-brainer. =09 Basically, I have used COS exclusively in our projects, but I don't = think that's easy for Spring to use (due to the licensing). I would simply = code this according to Spring norms using an interface and a default version using Commons FileUpload. Later, if somebody wants to create a cos = version we can (but to be honest, if we have a working, integrated solution I'm = not sure that is necessary - at least not in the Spring framework). = Basically, provide hooks and a default implementation, and allow users to adopt as necessary. =09 In our project we had modified the AbstractController and put the code = into it to handle the multipart processing, returning a wrapped HttpServletRequest through the handlers. This is very similiar to = Juergen's outline = (http://sourceforge.net/mailarchive/message.php?msg_id=3D3891279). =09 Since we are migrating to the current Spring codebase, I need to move = our multipart handling code. The main question is whether we keep it internally, or place it into Spring. I propose modifying org.springframework.web.servlet.DispatcherServlet to have a "MultipartResolver". In the DispatcherServlet, the resolver would be = called to wrap the request in doService immediately before getHandler(request) = - currently line 351, and then called to do any cleanup immediately = before exiting the doService method. =09 I have about 2/3 of the code already written, and I will be writing the = rest between now and Monday. Does this strategy sound appropriate for = Spring (meaning should I commit it to the Spring codebase) when it's finished? =09 Trevor D. Cook Interprise Software =09 =09 =09 ------------------------------------------------------- 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 =09 |
