Menu
▾
▴
springframework-developer — Spring Framework developers list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(55) |
Mar
(100) |
Apr
(203) |
May
(330) |
Jun
(190) |
Jul
(302) |
Aug
(323) |
Sep
(197) |
Oct
(245) |
Nov
(490) |
Dec
(330) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(194) |
Feb
(400) |
Mar
(416) |
Apr
(415) |
May
(359) |
Jun
(381) |
Jul
(491) |
Aug
(311) |
Sep
(291) |
Oct
(273) |
Nov
(355) |
Dec
(266) |
| 2005 |
Jan
(306) |
Feb
(303) |
Mar
(520) |
Apr
(346) |
May
(255) |
Jun
(221) |
Jul
(171) |
Aug
(247) |
Sep
(147) |
Oct
(125) |
Nov
(165) |
Dec
(65) |
| 2006 |
Jan
(90) |
Feb
(53) |
Mar
(121) |
Apr
(103) |
May
(113) |
Jun
(103) |
Jul
(104) |
Aug
(67) |
Sep
(78) |
Oct
(82) |
Nov
(78) |
Dec
(70) |
| 2007 |
Jan
(77) |
Feb
(76) |
Mar
(63) |
Apr
(30) |
May
(47) |
Jun
(41) |
Jul
(44) |
Aug
(44) |
Sep
(49) |
Oct
(33) |
Nov
(25) |
Dec
(21) |
| 2008 |
Jan
(45) |
Feb
(13) |
Mar
(15) |
Apr
(12) |
May
(9) |
Jun
(33) |
Jul
(30) |
Aug
(7) |
Sep
(20) |
Oct
(17) |
Nov
(20) |
Dec
(10) |
| 2009 |
Jan
(8) |
Feb
(5) |
Mar
(12) |
Apr
(17) |
May
(19) |
Jun
(97) |
Jul
(77) |
Aug
(33) |
Sep
(24) |
Oct
(41) |
Nov
(16) |
Dec
(32) |
| 2010 |
Jan
(24) |
Feb
(14) |
Mar
(50) |
Apr
(71) |
May
(70) |
Jun
(64) |
Jul
(45) |
Aug
(62) |
Sep
(32) |
Oct
(4) |
Nov
(12) |
Dec
(2) |
| 2011 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(3) |
May
(6) |
Jun
(1) |
Jul
(4) |
Aug
(3) |
Sep
(4) |
Oct
(6) |
Nov
(3) |
Dec
(3) |
| 2012 |
Jan
(4) |
Feb
(8) |
Mar
(6) |
Apr
(10) |
May
(2) |
Jun
(3) |
Jul
(11) |
Aug
(10) |
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(4) |
Feb
(1) |
Mar
(9) |
Apr
(1) |
May
(8) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(10) |
Dec
(8) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(9) |
Apr
(12) |
May
(2) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(9) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(7) |
Oct
(9) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(7) |
Feb
(5) |
Mar
(5) |
Apr
(5) |
May
(8) |
Jun
(4) |
Jul
(5) |
Aug
(4) |
Sep
(6) |
Oct
(7) |
Nov
(2) |
Dec
(3) |
| 2017 |
Jan
(7) |
Feb
(8) |
Mar
(7) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(8) |
Sep
(4) |
Oct
(2) |
Nov
(3) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <jh...@we...> - 2003-02-22 18:57:01
|
VHJldm9yLA0KIA0KVGhlIG5hbWUgIkxvY2FsZVJlc29sdmVyIiBpcyBmaW5lLCBhbmQgbmFtaW5n IHRoZSByZXRyaWV2YWwgbWV0aG9kICJyZXNvbHZlTG9jYWxlIiB0b28sIGFuYWxvZ291cyB0byBW aWV3UmVzb2x2ZXIuIEJ1dCBJJ20gbm90IHN1cmUgd2hhdCB5b3UgbWVhbiBjb25jZXJuaW5nIHRo ZSBzZXRMb2NhbGUgbWV0aG9kIGFuZCBpdHMgTG9jYWxlIHBhcmFtZXRlcjogV2UgbmVlZCBhIHdh eSBvZiB0ZWxsaW5nIHRoZSByZXNvbHZlciB0aGF0IHRoZSB1c2VyIGhhcyBjaG9zZW4gYSBzcGVj aWZpYyBsb2NhbGUgLSBqdXN0IGxpa2UgeW91IG5vdGUgaW4geW91ciA0dGggcGFyYWdyYXBoLiBJ LmUuIG9uZSByZXNvbHV0aW9uIG1ldGhvZCBhbmQgb25lIG1vZGlmaWNhdGlvbiBtZXRob2QuDQog DQpJIGFsc28gcHJlZmVyIHRoZSAidmlld1Jlc29sdmVyIiBiZWFuIHJlZmVyZW5jZSwgbG9va2Vk IHVwIGJ5IHRoZSBDb250cm9sbGVyU2VydmxldCwgd2l0aG91dCBpbmRpdmlkdWFsIExvY2FsZVJl c29sdmVyIGluc3RhbmNlcyBwZXIgY29udHJvbGxlci4gT2YgY291cnNlLCBjb250cm9sbGVycyBu ZWVkIGEgd2F5IHRvIGJvdGggcmV0cmlldmUgYW5kIHNldCB0aGUgY3VycmVudCBsb2NhbGUuIFNv IHdlIHNob3VsZCBwcm9iYWJseSBwcm9wYWdhdGUgdGhlIENvbnRyb2xsZXJTZXJ2bGV0J3MgTG9j YWxlUmVzb2x2ZXIgaW5zdGFuY2UgdmlhIEhhbmRsZXJNYXBwaW5nIHRvIENvbnRyb2xsZXIgaW5z dGFuY2VzIHRoYXQgaW1wbGVtZW50IExvY2FsZVJlc29sdmVyQXdhcmUgKGFzIEkndmUgYWxyZWFk eSBwcm9wb3NlZCksIGFuYWxvZ291cyB0byBBcHBsaWNhdGlvbkNvbnRleHQgYW5kIEFwcGxpY2F0 aW9uQ29udGV4dEF3YXJlLg0KIA0KQ29uY2VybmluZyBMb2NhbGVSZXNvbHZlciBpbXBsZW1lbnRh dGlvbnM6IE1heWJlIGNhbGwgdGhlIGRlZmF1bHQgaW1wbGVtZW50YXRpb24gIkJyb3dzZXJTZXR0 aW5nTG9jYWxlUmVzb2x2ZXIiPyBBbmQgeWVzLCB3ZSBzaG91bGQgcHJvdmlkZSBhICJTZXNzaW9u TG9jYWxlUmVzb2x2ZXIiIGFuZCBhICJDb29raWVMb2NhbGVSZXNvbHZlciIgb3V0IG9mIHRoZSBi b3guDQogDQpJIGxpa2UgdGhhdCBsb2NhbGUgcmVzb2x1dGlvbiBzdXBwb3J0OiBmYWlybHkgc29w aGlzdGljYXRlZCwgYnV0IHN0aWxsIHJlYXNvbmFibHkgc2ltcGxlIQ0KIA0KSnVlcmdlbg0KIA0K IA0KDQoJLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IFRyZXZvciBD b29rIFttYWlsdG86dGNvb2tAaW50ZXJwcmlzZXNvZnR3YXJlLmNvbV0gDQoJR2VzZW5kZXQ6IFNh IDIyLjAyLjIwMDMgMTc6MzAgDQoJQW46IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMu c291cmNlZm9yZ2UubmV0IA0KCUNjOiANCglCZXRyZWZmOiBSRTogW1NwcmluZ2ZyYW1ld29yay1k ZXZlbG9wZXJdIEV4cGxpY2l0IGxvY2FsZXMNCgkNCgkNCg0KCU5hbWluZyAtIEkgYWdyZWUgdGhh dCBMb2NhbGVIYW5kbGVyIGlzIGNvbmZ1c2luZy4gSSBsaWtlIExvY2FsZVJlc29sdmVyLCBzaW5j ZSBpdCBpcyBjb25zaXN0ZW50IHdpdGggdGhlIHRoZSBWaWV3UmVzb2x2ZXIgY2xhc3Nlcy4gDQoN CglJbnRlcmZhY2UgLSByZWFsbHkgZ29vZCwgYnV0IEkgZG9uJ3QgdGhpbmsgaXQncyBuZWNlc3Nh cnkgdG8gaGF2ZSBsb2NhbGUgYXMgYSBwYXJhbWV0ZXIgb2Ygc2V0TG9jYWxlLCBzaW5jZSB0aGF0 IG1ldGhvZCB3aWxsIGJlIGRldGVybWluaW5nIHRoZSBhY3R1YWwgbG9jYWxlLiBXaGF0IHZhbHVl IGJlIHBhc3NlZCBieSB0aGUgQ29udHJvbGxlclNlcnZsZXQgZm9yIHRoaXMgcGFyYW1ldGVyPyAg TWF5YmUgaXQgd291bGQgYmUgbGVzcyBjb25mdXNpbmcgdG8gbWFrZSB0aGUgc2lnbmF0dXJlOg0K DQoJICAgICAgICBMb2NhbGUgcmVzb2x2ZUxvY2FsZShIdHRwU2VydmxldFJlcXVlc3QgcmVxdWVz dCwgSHR0cFNlcnZsZXRSZXNwb25zZSByZXNwb25zZSk7IA0KCVRoZSBzaWduYXR1cmUgbm93IG1h a2VzIGl0IGNsZWFyIHRoYXQgd2UgYXJlIG5vdCAic2V0dGluZyBpdCIgc28gbXVjaCBhcyBhc2tp bmcgdGhlIG1ldGhvZCB0byBkZXRlcm1pbmUgaG93IGl0IHNob3VsZCBiZSBzZXQuICBJdCBhbHNv IG1hdGNoZXMgdGhlIHZpZXdSZXNvbHZlciB1c2FnZS4gQW4gYWRkaXRpb25hbCAic2V0TG9jYWxl IiBtZXRob2Qgd2l0aCB0aGUgc2lnbmF0dXJlIHlvdSBwcm92aWRlZDoNCg0KCSAgICAgICAgdm9p ZCBzZXRMb2NhbGUoSHR0cFNlcnZsZXRSZXF1ZXN0IHJlcXVlc3QsIEh0dHBTZXJ2bGV0UmVzcG9u c2UgcmVzcG9uc2UsIExvY2FsZSBsb2NhbGUpOyANCgljb3VsZCBiZSB1c2VkIHRvIGV4cGxpY2l0 bHkgb3ZlcnJpZGUgdGhlIExvY2FsZSBkZXRlcm1pbmVkIGJ5IHRoZSByZXNvbHZlTG9jYWxlIG1l dGhvZC4gIFRoaXMgd291bGQgYmVuZWZpdCBDb250cm9sbGVyIHNwZWNpZmljIG92ZXJyaWRlcyAo YWRkcmVzc2VkIGJlbG93KS4gIEFzIHlvdSBub3RlZCwgdGhlIHJlc3BvbnNlIGlzIG5lY2Vzc2Fy eSBmb3IgY29va2llLWJhc2VkIGltcGxlbWVudGF0aW9ucyAoZ29vZCBjYXRjaCkuDQoNCglDb25m aWd1cmF0aW9uIC0gSSB0aGluayB0aGF0IGxvYWRpbmcgaXQgYXMgYSBiZWFuIHJlZmVyZW5jZSAo bGlrZSAidmlld1Jlc29sdmVyIikgbWFrZXMgdGhlIG1vc3Qgc2Vuc2UuICBJZiB3ZSBwcm92aWRl IGFuIGFjY2VzcyBtZXRob2QsIHRoaXMgd291bGQgYWxsb3cgaW5kaXZpZHVhbCBDb250cm9sbGVy cyB0byBnZXQgYSByZWZlcmVuY2UgdG8gdGhlIHJlc29sdmVyIGFuZCBvdmVycmlkZSB0aGUgbG9j YWxlIHVzaW5nIHRoZSBzZXRMb2NhbGUgbWV0aG9kIG1lbnRpb25lZCBhYm92ZS4gIEkgdGhpbmsg dGhlIENvbnRyb2xsZXJTZXJ2bGV0IHNob3VsZCBoYW5kbGUgdGhlIGxvY2FsZSByZXNvbHV0aW9u IHJhdGhlciB0aGFuIGEgIkxvY2FsZUhhbmRsZXItcGVyLUNvbnRyb2xsZXIiLiAgSWYgc29tZW9u ZSBuZWVkcyAibm9ybWFsIiBsb2NhbGUgaGFuZGxpbmcsIEkgdGhpbmsgdGhlIHBlci1Db250cm9s bGVyIG1ldGhvZCB3b3VsZCByZXF1aXJlIHRvbyBtdWNoIGN1dC1uLXBhc3RlIHR5cGUgY29kZS4g IEhvd2V2ZXIsIHRoZSBleHBvc2VkIHNldExvY2FsZSBtZXRob2Qgd291bGQgYWxsb3cgdGhvc2Ug d2hvIG5lZWQgdG8gc2V0IGl0IG9uIGEgcGVyLUNvbnRyb2xsZXIgYmFzaXMgdGhlIGFiaWxpdHkg dG8gZG8gc28uDQoNCglEZWZhdWx0SW1wbGVtZW50YXRpb24gLSBJIHRoaW5rICJDbGllbnRMb2Nh bGVIYW5kbGVyIiBpcyB0b28gZ2VuZXJhbCwgc2luY2UgYWxsIExvY2FsZUhhbmRsZXJzIChvciBM b2NhbGVSZXNvbHZlcnMgYXMgSSBwcmVmZXIgOikgKSBhcmUgbWFraW5nIGRlY2lzaW9ucyBiYXNl ZCBvbiB0aGUgY2xpZW50LiAgVGhlIGRlZmF1bHQgd2lsbCBiZSB1c2luZyB0aGUgc2VydmxldHMg ZGVmYXVsdCBtZWNoYW5pc20sIHNvIG1heWJlICJTZXJ2bGV0TG9jYWxlUmVzb2x2ZXIiIG9yICJS ZXF1ZXN0TG9jYWxlUmVzb2x2ZXIiIChhbHRob3VnaCBhZ2FpbiwgdG9vIG1lIHRoZXkncmUgdG9v IGdlbmVyYWwgLSBJIGNhbid0IHRoaW5rIG9mIGEgcmVhbGx5IGdvb2QgbmFtZSkuICBXZSBzaG91 bGQgYWxzbyBjcmVhdGUgYWRkaXRpb25hbCBpbXBsZW1lbnRhdGlvbnMgZm9yIGRpc3RyaWJ1dGlv biBzdWNoIGFzIHRoZSBjb29raWUgYW5kIHNlc3Npb24gYmFzZWQgdmVyc2lvbnMsIHJhdGhlciB0 aGFuIHJlcXVpcmluZyBlYWNoIGNsaWVudCB0byBjb2RlIG9uZSB0aGVtc2VsdmVzIChhbHRob3Vn aCB0aGV5IHdpbGwgaGF2ZSB0aGUgb3BwdXJ0dW5pdHkgdG8gZG8gc28pLg0KDQoJR3JlYXQgYW5h bHlzaXMgSnVlcmdlbiEgDQoNCg0KCVRyZXZvciBELiBDb29rIA0KCQ0KCS0tLQ0KCU91dGdvaW5n IG1haWwgaXMgY2VydGlmaWVkIFZpcnVzIEZyZWUuDQoJQ2hlY2tlZCBieSBBVkcgYW50aS12aXJ1 cyBzeXN0ZW0gKGh0dHA6Ly93d3cuZ3Jpc29mdC5jb20pLg0KCVZlcnNpb246IDYuMC40NTYgLyBW aXJ1cyBEYXRhYmFzZTogMjU2IC0gUmVsZWFzZSBEYXRlOiAyLzE4LzAzDQoJICANCg0K |
|
From: <jh...@we...> - 2003-02-22 18:36:37
|
SmVhbi1QaWVycmUsDQogDQpDb25jZXJuaW5nIHlvdXIgSlNUTCBoYW5kbGluZzogSSBhc3N1bWUg aXQgaXMgYWJvdXQgZXhwb3NpbmcgU3ByaW5nJ3MgbWVzc2FnZSByZXNvdXJjZSBidW5kbGUgYW5k IHRoZSBjdXJyZW50IGxvY2FsZSB0byBKU1RMIHRhZ3MuIFdlIHNob3VsZCByZWFsbHkgdGhpbmsg YWJvdXQgc3VwcG9ydGluZyB0aGlzIHdpdGhpbiBTcHJpbmcuDQogDQpKU1RMIGRlZmluZXMgc3Rh bmRhcmQgYXR0cmlidXRlIG5hbWVzLCB1c2FibGUgYXQgYWxsIHNjb3BlIGxldmVscywgZm9yIHN0 YW5kYXJkIExvY2FsZSBhbmQgZm9yIGl0cyBzcGVjaWZpYyBjbGFzcyBMb2NhbGl6YXRpb25Db250 ZXh0IHRoYXQgY29tYmluZXMgUmVzb3VyY2VCdW5kbGUgYW5kIExvY2FsZSBwcm9wZXJ0aWVzLiBU aGUgYXBwcm9wcmlhdGUgbGV2ZWwgZm9yIFNwcmluZyBzdXBwb3J0IGlzIHByb2JhYmx5IGV4cG9z aW5nIGEgTG9jYWxpemF0aW9uQ29udGV4dCBhdCByZXF1ZXN0IHNjb3BlLiBFeHBvc2luZyBzaG91 bGQgaGFwcGVuIGFmdGVyIHJlcXVlc3QgcHJvY2Vzc2luZywgYXMgYSBjb250cm9sbGVyIGNvdWxk IGNoYW5nZSB0aGUgdXNlcidzIGN1cnJlbnQgbG9jYWxlLg0KIA0KT2YgY291cnNlLCB0aGVyZSBh cmUgdmFyaW91cyB3YXlzIG9mIHN1cHBvcnQ6IFdlIGNvdWxkIG1ha2UgdGhlIENvbnRyb2xsZXJT ZXJ2bGV0IGV4cG9zZSB0aGUgTG9jYWxpemF0aW9uQ29udGV4dCwgb3IgbGVhdmUgdGhhdCB0byBl YWNoIGNvbnRyb2xsZXIgaW1wbGVtZW50YXRpb24uIEJ1dCBJIGNvbnNpZGVyIGEgSlNUTC1zcGVj aWZpYyBWaWV3IGltcGxlbWVudGF0aW9uIHRoZSBiZXN0IGNob2ljZSwgaS5lLiBhIEpzdGxWaWV3 IGNsYXNzLiBUaGUgbGF0dGVyIHNob3VsZCBiYXNpY2FsbHkgYmVoYXZlIGxpa2UgYW4gSW50ZXJu YWxSZXNvdXJjZVZpZXcsIGJ1dCBhZGRpdGlvbmFsbHkgcmV0cmlldmUgdGhlIFdlYkFwcGxpY2F0 aW9uQ29udGV4dCdzIG1lc3NhZ2UgcmVzb3VyY2UgYnVuZGxlIGFuZCB0aGUgY3VycmVudCBsb2Nh bGUgKHZpYSBvdXIgbmV3bHkgcHJvcG9zZWQgTG9jYWxlUmVzb2x2ZXIpLCBhbmQgZXhwb3NlIHRo ZW0gYXMgYSBKU1RMIExvY2FsaXphdGlvbkNvbnRleHQuDQogDQpUaGVyZSdzIG9uZSBkcmF3YmFj azogU3ByaW5nJ3MgTWVzc2FnZVNvdXJjZSBpcyBhIGdlbmVyaWMgaW50ZXJmYWNlLCBhbmQgUmVz b3VyY2VCdW5kbGVNZXNzYWdlU291cmNlIGp1c3Qgb25lIGltcGxlbWVudGF0aW9uIG9mIGl0LiBK U1RMIGV4cGVjdHMgYSBSZXNvdXJjZUJ1bmRsZSwgYnV0IHdlIGRvbid0IHdhbnQgdG8gdGllIG91 ciBzdXBwb3J0IHRvIFJlc291cmNlQnVuZGxlTWVzc2FnZVNvdXJjZXMuIEZvcnR1bmF0ZWx5LCB0 aGlzIGlzIG5vdCBoYXJkIHRvIHNvbHZlOiBSZXNvdXJjZUJ1bmRsZSBpcyBhbiBhYnN0cmFjdCBj bGFzcywgcmVxdWlyaW5nIGFuICJPYmplY3QgaGFuZGxlR2V0T2JqZWN0KFN0cmluZyBrZXkpIiBp bXBsZW1lbnRhdGlvbi4gV2UgY2FuIGludHJvZHVjZSBhIE1lc3NhZ2VTb3VyY2VSZXNvdXJjZUJ1 bmRsZSBjbGFzcyAocHVuIGludGVuZGVkKSB0aGF0IGRlbGVnYXRlcyB0byAiTWVzc2FnZVNvdXJj ZS5nZXRNZXNzYWdlKFN0cmluZyBjb2RlLCBMb2NhbGUgbG9jYWxlKS4gQW4gaW5zdGFuY2Ugb2Yg aXQgY291bGQgYmUgY3JlYXRlZCBvbi10aGUtZmx5IGJ5IEpzdGxWaWV3LCB1c2luZyB0aGUgY3Vy cmVudCBsb2NhbGUuDQogDQpXaGF0IGRvIHlvdSB0aGluaywgd291bGQgc3VjaCBhIHNvbHV0aW9u IGJlIGFwcHJvcHJpYXRlPyBJZiB5ZXMsIHRoZW4gSSdtIGdvbm5hIGFkZCBpdCBwcm9tcHR5IGlu IHRoZSBjb3Vyc2Ugb2YgbXkgY3VycmVudCB3ZWIgcGFja2FnZSBwb2xpc2hpbmcuIEl0IGlzIHNp bXBsZSBidXQgbmV2ZXJ0aGVsZXNzIHZlcnkgY29udmVuaWVudCwgSU1ITy4NCiANCkp1ZXJnZW4N CiANCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBKUCBQ QVdMQUsoVGlzY2FsaSkgW21haWx0bzpqcC5wYXdsYWtAdGlzY2FsaS5mcl0gDQoJR2VzZW5kZXQ6 IEZyIDIxLjAyLjIwMDMgMDg6MDMgDQoJQW46IFNwcmluZyBEZXZlbG9wZXJzIChFLW1haWwpIA0K CUNjOiANCglCZXRyZWZmOiBUUiA6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBFeHBsaWNp dCBsb2NhbGVzDQoJDQoJDQoNCglFbnZvecOpIDogamV1ZGkgMjAgZsOpdnJpZXIgMjAwMyAyMjo1 MA0KCcOAIDogJ1RyZXZvciBDb29rJw0KCU9iamV0IDogUkUgOiBbU3ByaW5nZnJhbWV3b3JrLWRl dmVsb3Blcl0gRXhwbGljaXQgbG9jYWxlcw0KDQoJIA0KDQoJSSB1c2UgYSBzb2x1dGlvbiBuZWFy IG9mIHlvdXJzIGJ1dCB3aXRoIGEgbW9yZSBnZW5lcmFsaXN0IGFwcHJvYWNoLiBUbyBrZWVwIHRo ZSB1c2VycyBsb2NhbGUsIGRpZmZlcmVudCBwb3NzaWJpbGl0aWVzIGV4aXN0OiBzZXNzaW9uLCBj b29raWUsIFVSTC4gQnV0IGVhY2ggc29sdXRpb24gY2FuIGJlIGhhbmRsZWQga25vd2luZyB0aGUg cmVxdWVzdCBvYmplY3QuIFNvIEkgdXNlIGEgYmVhbiBmb3IgaW1wbGVtZW50aW5nIHRoZSBlZmZl Y3RpdmUgc3RyYXRlZ3kgaW4gdGhlIHdheSBvZiB0aGUgZ2VuZXJhbCBzcGlyaXQgb2YgU3ByaW5n Lg0KDQoJIDEpIENyZWF0ZSBhIHNpbXBsZSBpbnRlcmZhY2UgbGlrZSB0aGlzOg0KDQoJcHVibGlj IGludGVyZmFjZSBMb2NhbGVMb2NhdG9yIHsNCg0KCSAgICAgIExvY2FsZSBnZXRTZXNzaW9uTG9j YWxlKEh0dHBTZXJ2bGV0UmVxdWVzdCByZXF1ZXN0KTsNCg0KCSAgICAgIHZvaWQgc2V0U2Vzc2lv bkxvY2FsZShIdHRwU2VydmxldFJlcXVlc3QgcmVxdWVzdCwgTG9jYWxlIHNlc3Npb25Mb2NhbGUp Ow0KDQoJfQ0KDQoJMikgQ3JlYXRlIGFuIGltcGxlbWVudGF0aW9uIGNsYXNzIHdoaWNoIGluIHlv dXIgY2FzZSBoYW5kbGVzIHdpdGggdGhlIGNvb2tpZXMsIGJ1dCB3aGljaCBjYW4gdXNlIHRoZSBz ZXNzaW9uIG9yIHdoYXQgbWV0aG9kIHlvdSBsaWtlLg0KDQoJMykgT3ZlcnJpZGluZyB0aGUgQ29u dHJvbGxlclNlcnZsZXQgdG8gdXNlIGEgTG9jYWxlTG9jYXRvciBwcm9wZXJ0eSB3aXRoIGF0IGxl YXN0IHRoZSBzZXR0ZXIsIHNvIHRoZSBpbXBsZW1lbnRhdGlvbiBjbGFzcyBjYW4gYmUgZG9uZSBp biB0aGUgc2VydmxldC1jb25maWd1cmF0aW9uIGZpbGUuDQoNCgkgICAgICA8YmVhbiBuYW1lPSJs b2NhbGVMb2NhdG9yIiBzaW5nbGV0b249InRydWUiIGNsYXNzPSJwZXJzby5qcHAuZndrLndlYi5M b2NhbGVMb2NhdG9ySW1wbCIgLz4gICAgDQoNCgkgICAgICA8YmVhbiBuYW1lPSJqc3RsSGFuZGxl ciIgc2luZ2xldG9uPSJ0cnVlIiBjbGFzcz0icGVyc28uanBwLmZ3ay53ZWIuSnN0bEhhbmRsZXJJ bXBsIiA+ICAgICAgDQoNCgkgICAgICAgICAgICA8cHJvcGVydHkgbmFtZT0iYnVuZGxlTmFtZSI+ YWNoYXBwcm88L3Byb3BlcnR5Pg0KDQoJICAgICAgPC9iZWFuPg0KDQoJIA0KDQoJY29kZSBhZGRl ZCBpbiBkZWNsYXJhdGlvbiBwYXJ0Og0KDQoJICAgICAgLy8gQWRkZWQgYnkgSlBQDQoNCgkgICAg ICAvKiogVGhlIGJlYW4gbmFtZSBhbGxvd2luZyB0aGUgdXNlciBzZXNzaW9uIGxvY2FsZSB0byBi ZSByZXRyaWV2ZWQgKi8gDQoNCgkgICAgICBwdWJsaWMgc3RhdGljIGZpbmFsIFN0cmluZyBMT0NB TEVfTE9DQVRPUiA9ICJsb2NhbGVMb2NhdG9yIjsNCg0KCSANCg0KCSAgICAgIC8qKiBUaGUgYmVh biBuYW1lIGFsbG93aW5nIHRoZSBqc3RsIHJlc3NvdWVjZSBidW5kbGUgdG8gYmUgc2V0ICovIA0K DQoJICAgICAgcHVibGljIHN0YXRpYyBmaW5hbCBTdHJpbmcgSlNUTF9IQU5ETEVSID0gImpzdGxI YW5kbGVyIjsNCg0KCSANCg0KCSAgICAgIC8qKiBMb2NhbGVMb2NhdG9yIHVzZWQgYnkgdGhpcyBz ZXJ2bGV0DQoNCgkgICAgICAgKiBJZiBub3QgcHJvdmlkZWQsIHJlcXVlc3QuZ2V0TG9jYWxlKCkg d2lsbCBiZSB1c2VkIGluc3RlYWQgKi8gIA0KDQoJICAgICAgcHJpdmF0ZSBMb2NhbGVMb2NhdG9y IGxvY2FsZUxvY2F0b3I7DQoNCgkgICAgICAvLyBFbmQgYWRkZWQNCg0KCSANCg0KCSANCg0KCWNv ZGUgYWRkZWQgaW4gQ29udHJvbGxlclNlcnZsZXQgKG9yIGRlc2NlbmRlbnQpIGF0IGVuZCBvZiBp bml0RnJhbWV3b3JrU2VydmxldCA6DQoNCgkgICAgICAgICAgICBpbml0Vmlld1Jlc29sdmVyKCk7 DQoNCgkgICAgICAgICAgICANCg0KCSAgICAgICAgICAgIC8vIEFkZGVkIGJ5IEpQUA0KDQoJICAg ICAgICAgICAgdHJ5IHsNCg0KCSAgICAgICAgICAgICAgICAgIGxvY2FsZUxvY2F0b3IgPSAoTG9j YWxlTG9jYXRvcikNCg0KCSAgICAgICAgICAgICAgICAgICAgICAgIGdldFdlYkFwcGxpY2F0aW9u Q29udGV4dCgpLmdldEJlYW4oTE9DQUxFX0xPQ0FUT1IpOyANCg0KCSAgICAgICAgICAgICAgICAg IGxvZ2dlci5jb25maWcoImxvY2FsZUxvY2F0b3IgZm91bmQgaW4gc2VydmxldCAnIiArIGdldFNl cnZsZXROYW1lKCkgDQoNCgkgICAgICAgICAgICAgICAgICAgICAgICArICInIDogIiArIGxvY2Fs ZUxvY2F0b3IuZ2V0Q2xhc3MoKS5nZXROYW1lKCkpOw0KDQoJICAgICAgICAgICAgfSBjYXRjaChF eGNlcHRpb24gZSkgew0KDQoJICAgICAgICAgICAgICAgICAgbG9jYWxlTG9jYXRvciA9IG51bGw7 ICAgLy8gTm90IHJlcXVpcmVkIGFzIGl0IHNob3VsZCB5ZXQgYmVlbiBudWxsDQoNCgkgICAgICAg ICAgICAgICAgICBsb2dnZXIuY29uZmlnKCJObyBsb2NhbGVMb2NhdG9yIGZvdW5kIGluIHNlcnZs ZXQgJyIgKyBnZXRTZXJ2bGV0TmFtZSgpICsgIicsIHJlcXVlc3QgTG9jYWxlIHdpbGwgYmUgdXNl ZC4iKTsNCg0KCSAgICAgICAgICAgIH0NCg0KCSAgICAgICAgICAgIC8vIEpzdGwgaGFuZGxpbmcN Cg0KCSAgICAgICAgICAgIC8vIFB1dCBvbmx5IGluIGEgc3ViY2xhc3MgPyBCdXQgSnN0bCBpcyBh Z2VuZXJpYyB1c2UNCg0KCSAgICAgICAgICAgIC8vIFRoZSBBcHBsaWNhdGlvbkNvbnRleHRBd2Fy ZSBkb2Vzbid0IHByb3ZpZGUgYW4gYWNjZXNzIHRvIHRoZSBzZXJ2bGV0Q29udGV4dA0KDQoJICAg ICAgICAgICAgLy8gSXQncyB0aGUgcmVhc29uIG9mIGFuIGluaXRpYWxpc2F0aW9uIGhlcmUuIEV4 aXN0cyBhIGJlc3QgYXBwcm9hY2ggPw0KDQoJICAgICAgICAgICAgdHJ5IHsNCg0KCSAgICAgICAg ICAgICAgICAgIEpzdGxIYW5kbGVyIGpzdGxIYW5kbGVyID0gKEpzdGxIYW5kbGVyKSAgDQoNCgkg ICAgICAgICAgICAgICAgICAgICAgICBnZXRXZWJBcHBsaWNhdGlvbkNvbnRleHQoKS5nZXRCZWFu KEpTVExfSEFORExFUik7IA0KDQoJICAgICAgICAgICAgICAgICAganN0bEhhbmRsZXIuc2V0U2Vy dmxldEN0eCh0aGlzLmdldFNlcnZsZXRDb250ZXh0KCkpOw0KDQoJICAgICAgICAgICAgICAgICAg bG9nZ2VyLmNvbmZpZygianN0bEhhbmRsZXIgZm91bmQgaW4gc2VydmxldCAnIiArIGdldFNlcnZs ZXROYW1lKCkgDQoNCgkgICAgICAgICAgICAgICAgICAgICAgICArICInIDogIiArIGpzdGxIYW5k bGVyLmdldENsYXNzKCkuZ2V0TmFtZSgpKTsNCg0KCSAgICAgICAgICAgIH0gY2F0Y2goRXhjZXB0 aW9uIGUpIHsNCg0KCSAgICAgICAgICAgICAgICAgIGxvZ2dlci5jb25maWcoIk5vIGpzdGxIYW5k bGVyIGZvdW5kIGluIHNlcnZsZXQgJyIgKyBnZXRTZXJ2bGV0TmFtZSgpKTsNCg0KCSAgICAgICAg ICAgIH0NCg0KCSAgICAgICAgICAgIA0KDQoJICAgICAgICAgICAgLy8gRW5kIGFkZGVkDQoNCgkg DQoNCgk0KSBBcyB5b3UgY2FuIHNlZSwgSSBoYW5kbGUgSSBhIHNhbWUgd2F5IHRoZSBkZWZpbml0 aW9uIG9mIGxvY2FsZSBhbmQgYnVuZGxlIGZvciBKU1RMLg0KDQoJNSkgVGhlIExvY2FsZUxvY2F0 b3IgY2FuIGJlIGRvbmF0ZWQgYnkgYmVhbnJlZiBwcm9wZXJ0eSB0byBvYmplY3RzIHdoaWNoIGhh dmUgdG8ga25vdyB0aGUgY3VycmVudCBsb2NhbGUgaGF2aW5nIHRoZSByZXF1ZXN0IG9iamVjdC4N Cg0KCSANCg0KCUkgaG9wZSB0aGlzIHdpbGwgYmUgYSB1c2VmdWwgYWRkLW9uIGluIHRoaXMgZGlz Y3Vzc2lvbi4gSSBzdWdnZXN0IHRvIGludGVncmF0ZSBhIHN1Y2ggYmVoYXZpb3VyIGluIHRoZSBv cmlnaW5hbCBDb250cm9sbGVyU2VydmxldCBhcyB0aGVzIG5lZWRzIGFyZSB2ZXJ5IGdlbmVyYWxs eS4NCg0KCSANCg0KCVJlZ2FyZHMsDQoNCglKZWFuLVBpZXJyZQ0KDQoJIA0KDQoNCi0tLQ0KT3V0 Z29pbmcgbWFpbCBpcyBjZXJ0aWZpZWQgVmlydXMgRnJlZS4NCkNoZWNrZWQgYnkgQVZHIGFudGkt dmlydXMgc3lzdGVtIChodHRwOi8vd3d3LmdyaXNvZnQuY29tKS4NClZlcnNpb246IDYuMC40NTYg LyBWaXJ1cyBEYXRhYmFzZTogMjU2IC0gUmVsZWFzZSBEYXRlOiAyLzE4LzAzDQoNCg0K |
|
From: <jh...@we...> - 2003-02-22 17:14:38
|
VG9ueSwgUm9kLCBldmVyeW9uZSwNCiANClN1cHBvcnQgZm9yIGVycm9yIGFyZ3VtZW50cyBpcyBp bmRlZWQgYSB2YWx1YWJsZSBjb250cmlidXRpb24gdGhhdCBmaWxscyBhIGdhcC4gTGV0J3MgZ2V0 IGl0IGludG8gQ1ZTIQ0KIA0KQ29uY2VybmluZyBTdHJ1dHM6IERlc3BpdGUgYWxsIG9mIGl0cyBz aG9ydGNvbWluZ3MsIFN0cnV0cyBkb2VzIGhhdmUgYSBsb3Qgb2YgZmVhdHVyZXMuIEkndmUgaGFk IGEgZGV0YWlsZWQgbG9vayBhdCBTdHJ1dHMgMS4xYjMgcmVjZW50bHksIGVzcGVjaWFsbHkgYW5h bHl6aW5nIFN0cnV0cycgd2F5IG9mIGRvaW5nIHRoaW5ncy4gVGhlcmUgYXJlIHNvbWUgdGhpbmdz IHdvcnRoIGxvb2tpbmcgYXQ6IGRpc3BhdGNoIGFjdGlvbnMsIGR5bmFtaWMgZm9ybXMsIGVycm9y IG1lc3NhZ2UgaGFuZGxpbmcsIHJlcXVlc3QgdG9rZW5zLCBkZWNsYXJhdGl2ZSB2YWxpZGF0aW9u LCBtdWx0aXBhcnQgcmVxdWVzdCBwcm9jZXNzaW5nLCAibW9kdWxlcyIsIFRpbGVzIGludGVncmF0 aW9uLg0KIA0KT2YgY291cnNlLCBTdHJ1dHMnIEFQSSBhbmQgaW1wbGVtZW50YXRpb24gYXJlIGEg bWF0dGVyIG9mIHRhc3RlIGF0IGJlc3QuIEl0cyBhcmNoaXRlY3R1cmUgaXMgZnVsbCBvZiBzaWdu aWZpY2FudCBxdWlya3MuIFNvbWUgdGhpbmdzIGFyZSB1bmZsZXhpYmxlLCBsaWtlIHR5aW5nIGV2 ZXJ5dGhpbmcgdG8gQWN0aW9uU2VydmxldC9BY3Rpb25Gb3JtL0FjdGlvbiBhbmQgdHJlYXRpbmcg ZXZlcnkgcmVxdWVzdCBhcyBhIGZvcm0uIFNvbWUgdGhpbmdzIGFyZSBvYnZpb3VzbHkgcmVzdWx0 cyBvZiBpbnRyb2R1Y2luZyBiYXNpYyBjaGFuZ2VzIHdpdGggMS4xLCBkZXByZWNhdGluZyBhIGxv dCBvZiAxLjAgbWV0aG9kcywgbGVhdmluZyB0aGUgaW1wcmVzc2lvbiBvZiBzdWJvcHRpbWFsIHNv bHV0aW9ucy4NCiANCkdlbmVyYWxseSwgdGhlcmUgYXJlIGhhcmRseSBhbnkgaW50ZXJmYWNlcyAt IGFuZCB0aHVzIGhhcmRseSBhbnkgZGVsZWdhdGlvbiAtIHdpdGhpbiBTdHJ1dHM6IDE4IGluIHRv dGFsLCA4IG9mIHRoZW0gaW4gdGhlIHRhZ2xpYiBpbXBsZW1lbnRhdGlvbiBhbmQgNSBpbiB0aGUg dGlsZXMgcGx1Z2luOyBsZWF2aW5nIDUgaW50ZXJmYWNlcyBpbiB0aGUgZnJhbWV3b3JrIGl0c2Vs ZiwgMiBvZiB0aGVtIGluIHRoZSB1cGxvYWQgcGFja2FnZSAoYXMgb2YgMS4xYjMpLiBJbnN0ZWFk LCBTdHJ1dHMgcmVsaWVzIGhlYXZpbHkgb24gc3ViY2xhc3Npbmcgc3BlY2lmaWMgZnJhbWV3b3Jr IGNsYXNzZXMsIGUuZy4gQWN0aW9uIGFuZCBBY3Rpb25Gb3JtLg0KIA0KSW4gY29tcGFyaXNvbiwg U3ByaW5nIGhhcyBjdXJyZW50bHkgbW9yZSB0aGFuIDQwIGludGVyZmFjZXMgaW4gdGhlIGZyYW1l d29yayBpdHNlbGYsIGFuZCBtb2RlbHMgYXMgbXVjaCBhcyBwb3NzaWJsZSB2aWEgZGVsZWdhdGlv bi4gQ3VzdG9tIGFwcGxpY2F0aW9ucyBvbmx5IGhhdmUgdG8gaW1wbGVtZW50IFNwcmluZy1zcGVj aWZpYyBpbnRlcmZhY2VzIG9yIGV4dGVuZCBTcHJpbmctc3BlY2lmaWMgY2xhc3NlcyB3aGVuIHJl YWxseSBuZWNlc3NhcnkuIFRoZXJlJ3MgYSBjbGVhciBzZXBhcmF0aW9uIG9mIGNvbmNlcm5zLCBh bmQgcGFydGljdWxhcmx5IGltcG9ydGFudCwgYSBjbGVhciBzZXBhcmF0aW9uIGJldHdlZW4gZ2Vu ZXJpYyBpbmZyYXN0cnVjdHVyZSBhbmQgd2ViIHN1cHBvcnQuIEluIGNvbnRyYXN0IHRvIFN0cnV0 cywgU3ByaW5nIGlzIGEgZ2VuZXJpYyBhcHBsaWNhdGlvbiBmcmFtZXdvcmssIHdlbGwgc3VpdGVk IGZvciBjcmVhdGluZyByZXVzYWJsZSBidXNpbmVzcyBsb2dpYyBmb3IgYWxsIGtpbmRzIG9mIGFw cGxpY2F0aW9ucywgd2l0aCBhIHNwZWNpYWwgd2ViIGFwcGxpY2F0aW9uIGZyYW1ld29yayBvbiB0 b3Agb2YgaXQuDQogDQpCdXQgaWYgd2UgZmluZCBzb21lIG5pY2UgU3RydXRzIGZlYXR1cmVzIHRo YXQgd2UgY2FuIGltcGxlbWVudCB3aXRoaW4gU3ByaW5nIGluIGEgY2xlYW4gd2F5LCB0aGVuIHdl IHNob3VsZG4ndCBoZXNpdGF0ZSB0byBkbyBzbyENCiANClJlZ2FyZHMsDQpKdWVyZ2VuDQogDQog DQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjogUm9kIEpvaG5z b24gW21haWx0bzpyb2Quam9obnNvbkBpbnRlcmZhY2UyMS5jb21dIA0KCUdlc2VuZGV0OiBGciAy MS4wMi4yMDAzIDE2OjQ4IA0KCUFuOiBUb255IEZhbGFiZWxsYTsgc3ByaW5nZnJhbWV3b3JrLWRl dmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgDQoJQ2M6IA0KCUJldHJlZmY6IFJlOiBbU3By aW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gbW9kaWZpY2F0aW9uIHJlcXVlc3QgZm9yIGludGVyZmFj ZSBFcnJvckNvZGVkIEFORCBNZXNzYWdlU291cmNlDQoJDQoJDQoNCglUb255LA0KCQ0KCUkgdGhp bmsgdGhpcyBpcyBhIHZhbHVhYmxlIGNvbnRyaWJ1dGlvbi4gSW5kZWVkLCBpdCBpcyBhIGdhcCBp biB0aGUgcHJlc2VudA0KCWluY2FybmF0aW9uIG9mIFNwcmluZy4gQW5kIGl0IGlzIGEgMS4wIHRo aW5nICh0byBnbyB3aXRoIHRoZSBmb3J0aGNvbWluZw0KCWludGVybmF0aW9uYWxpemF0aW9uIHN1 cHBvcnQgaW4gdGhlIHdlYiBzdHVmZikuDQoJDQoJSSBoYXZlIHNvbWUgY29tbWVudHMgdGhhdCBJ J2xsIGFkZCB0byB5b3VyIGRvY3VtZW50IGFuZCBmZWVkIGJhY2sgdG8geW91DQoJKGp1c3QgYSBx dWVzdGlvbiBvZiB3aGVuOiBwcm9iYWJseSBTdW5kYXkpLg0KCQ0KCUknbSBwbGFubmluZyB0byBn aXZlIHlvdSBkZXZlbG9wZXIgcmlnaHRzIGFuZCBzYXkgbWFrZSB0aGUgY2hhbmdlcywgd2l0aA0K CXNvbWUgbWlub3IgdHdlYWtzLg0KCQ0KCVRlYW0sIGFueSBvYmplY3Rpb25zIHRvIG1vdmluZyBh aGVhZCB3aXRoIHRoaXM/DQoJDQoJVGhhbmtzIGZvciB0aGUgbmV3IHRlc3RzLCBieSB0aGUgd2F5 LiBBcyB5b3Uga25vdyBJJ20ga2VlbiBvbiB0ZXN0aW5nIGFuZA0KCUknbSBkZWxpZ2h0ZWQgdG8g c2VlIGNvbnRyaWJ1dGlvbnMgdGhhdCBpbXByb3ZlIG92ZXJhbGwgdGVzdCBjb3ZlcmFnZSENCgkN CglSZWdhcmRzLA0KCVJvZA0KCQ0KCS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCglGcm9t OiAiVG9ueSBGYWxhYmVsbGEiIDx0b255X2ZhbGFiZWxsYUB5YWhvby5jb20+DQoJVG86IDxzcHJp bmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldD4NCglTZW50OiBUaHVy c2RheSwgRmVicnVhcnkgMjAsIDIwMDMgNToyOSBBTQ0KCVN1YmplY3Q6IFtTcHJpbmdmcmFtZXdv cmstZGV2ZWxvcGVyXSBtb2RpZmljYXRpb24gcmVxdWVzdCBmb3IgaW50ZXJmYWNlDQoJRXJyb3JD b2RlZCBBTkQgTWVzc2FnZVNvdXJjZQ0KCQ0KCQ0KCT4NCgk+IFJvZCwNCgk+DQoJPiAocG9zdGlu ZyB0aGlzIGFnYWluIHNpbmNlIGdvdCBhbiAidG9vIGxhcmdlIiBtZXNzYWdlIGZyb20gbGlzdCBz ZXJ2ZXINCglmaXJzdCB0aW1lKSwNCgk+DQoJPiBBcyBpdCBjdXJyZW50bHkgc3RhbmRzIHlvdXIg aW50ZXJmYWNlIGNvbS5pbnRlcmZhY2UyMS5jb3JlLkVycm9yQ29kZWQgb25seQ0KCWhhcyB0aGUg Zm9sbG93aW5nIG1ldGhvZDoNCgk+ICAgIFN0cmluZyBnZXRFcnJvckNvZGUoKQ0KCT4NCgk+IEkg c2VlIGdyZWF0IHZhbHVlIGluIGhhdmluZyBhbiBpbnRlcmZhY2UgdGhhdCB3aWxsIGFsbG93IG1l c3NhZ2VzIHRoYXQgeW91DQoJd2lzaCB0byBkaXNwbGF5IHRvIHVzZXJzIHRvIHJldHVybiBhbiBl cnJvckNvZGUuICBUaGUgbWFpbiBwcmVtaXNlcyBJIHNlZQ0KCWJlaGluZCB0aGlzIGFyZToNCgk+ IDEpIEFuIGVycm9yQ29kZSBjYW4gYmUgdXNlZCB0byBsb29rIHVwIGFuIGFjdHVhbCBlcnJvciBp biBhIG1lc3NhZ2UNCgljYXRhbG9nLiAgVGhpcyB3aWxsIGFsbG93IHN1cHBvcnRpbmcgaW50ZXJu YXRpb25hbGl6YXRpb24gYW5kIGNhbiBhbGxvdw0KCWtlZXBpbmcgYW4gZXJyb3IgbWVzc2FnZSdz IHRleHQgaW4gYSBzaW5nbGUgY29tbW9uIGFyZWEuDQoJPiAyKSBIYXZpbmcgYW4gZXhjZXB0aW9u IHRoYXQgaXMgYWJsZSB0byByZXR1cm4gYW4gZXJyb3JDb2RlIGNhbiBhbGxvdyBmb3INCglHVUkg ZmllbGQvZXJyb3JDb2RlIG1hcHBpbmcgdGFibGVzIHRvIGJlIGNvbXB1dGVkLiAgVGhpcyBpcyBo ZWxwZnVsIGZvciBmYXQNCgljbGllbnRzIHRoYXQgd2lzaCB0byBjaGFuZ2UgY2VydGFpbiBmaWVs ZHMgYSBkaWZmZXJlbnQgY29sb3Igd2hlbiB2YXJpb3VzDQoJZXJyb3JzIG9jY3VyLCBpbmRpY2F0 aW5nIHdoYXQgZmllbGRzIG1heSBoYXZlIGludmFsaWQgZGF0YS4NCgk+DQoJPiBBcyB0aGUgY29k ZSBjdXJyZW50bHkgc3RhbmRzIGhvd2V2ZXIsIEkgZG8gc2VlIGEgZmFpcmx5IGJpZyBsaW1pdGF0 aW9uLg0KCVRoYXQgYmVpbmcgdGhhdCBxdWl0ZSBvZnRlbiBhbiBlcnJvciBtZXNzYWdlIG11c3Qg aGF2ZSBhcmd1bWVudHMgc3VwcGxpZWQgdG8NCglpdCB0byBtYWtlIGEgbW9yZSBtZWFuaW5nZnVs IGVycm9yIG1lc3NhZ2UuICBGb3IgZXhhbXBsZSwgdGhlIFN0cnV0cw0KCW9yZy5hcGFjaGUuc3Ry dXRzLnV0aWwuTWVzc2FnZVJlc291cmNlcyBjbGFzcyBjb250YWlucyB0aGUgZm9sbG93aW5nIG1l dGhvZHMNCgkoSSB3aWxsIGxpbWl0IHRoZSBjb252ZW5pZW5jZSBmb3JtcyBvZiB0aGlzIG1ldGhv ZCB0byBvbmx5IHNob3cgb25lIG9mDQoJdGhlbSk6DQoJPiAgICBwdWJsaWMgU3RyaW5nIGdldE1l c3NhZ2UoTG9jYWxlIGxvY2FsZSwgU3RyaW5nIGtleSwgT2JqZWN0IGFyZ3NbXSkNCgk+ICAgIHB1 YmxpYyBTdHJpbmcgZ2V0TWVzc2FnZShMb2NhbGUgbG9jYWxlLCBTdHJpbmcga2V5LCBPYmplY3Qg YXJnMCkNCgk+DQoJPiBXaGlsZSB0aGUgY29udmVuaWVuY2UgbWV0aG9kcyBTdHJ1dHMgaGFzIGFy ZSBoZWxwZnVsLCBzaW5jZSBFcnJvckNvZGVkIGlzDQoJYW4gaW50ZXJmYWNlIHlvdSBkbyBub3Qg aGF2ZSB0aGUgbHV4dXJ5IG9mIGhpZGluZyB0aGUgdmFyaW91cyBvdmVybG9hZHMgaW4NCglhbiBh YnN0cmFjdCBzdXBlcmNsYXNzLg0KCT4NCgk+IFNvIG15IHByb3Bvc2FsIGlzIHRoYXQgeW91IGFk ZCB0aGUgZm9sbG93aW5nIHRvIHRoZQ0KCWNvbS5pbnRlcmZhY2UyMS5jb3JlLkVycm9yQ29kZWQg aW50ZXJmYWNlOg0KCT4gICAgT2JqZWN0W10gZ2V0RXJyb3JBcmdzKCkNCgk+IEFsc28gY2hhbmdl IHRoZSBjb20uaW50ZXJmYWNlMjEuY29udGV4dC5NZXNzYWdlU291cmNlIGludGVyZmFjZSBtZXRo b2QNCglzaWduYXR1cmVzIGxpa2Ugc286DQoJPiAgICBTdHJpbmcgZ2V0TWVzc2FnZShTdHJpbmcg Y29kZSwgTG9jYWxlIGxvY2FsZSwgT2JqZWN0IGFyZ3NbXSkgdGhyb3dzDQoJTm9TdWNoTWVzc2Fn ZUV4Y2VwdGlvbg0KCT4gICAgU3RyaW5nIGdldE1lc3NhZ2UoU3RyaW5nIGNvZGUsIExvY2FsZSBs b2NhbGUsIE9iamVjdCBhcmdzW10sIFN0cmluZw0KCWRlZmF1bHRNZXNzYWdlKQ0KCT4NCgk+IEkn dmUgYWxyZWFkeSBtYWRlIHRoaXMgY2hhbmdlIHRvIG15IHZlcnNpb24gb2YgdGhlIGZyYW1ld29y ayBhbmQgd3JpdHRlbiBhDQoJZmV3IG5ldyBUZXN0U3VpdGUgY2xhc3NlcyB0byB0ZXN0IGl0LiAg SSd2ZSBnb3QgYSB6aXBwZWQgZmlsZSBjb250YWluaW5nIGFsbA0KCXRoZSBuZWNlc3NhcnkgY29k ZSB0byBpbmNvcnBvcmF0ZSBmb3IgdGhpcyBjaGFuZ2UgdGhhdCBJIGNhbiBtYWlsIHRvIHlvdS4N Cgk+DQoJPiBXaGF0IGRvZXMgdGhlIGdyb3VwIHRoaW5rIGFib3V0IG1lc3NhZ2VzIGJlaW5nIGFi bGUgdG8gdGFrZSBhcmd1bWVudHMgaW4NCgliZWZvcmUgdGhleSBhcmUgZGlzcGxheWVkPw0KCT4N Cgk+DQoJDQoJDQoJDQoJDQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KCVRoaXMgU0YubmV0IGVtYWlsIGlzIHNwb25zb3JlZCBieTogU2xp Y2tFZGl0IEluYy4gRGV2ZWxvcCBhbiBlZGdlLg0KCVRoZSBtb3N0IGNvbXByZWhlbnNpdmUgYW5k IGZsZXhpYmxlIGNvZGUgZWRpdG9yIHlvdSBjYW4gdXNlLg0KCUNvZGUgZmFzdGVyLiBDL0MrKywg QyMsIEphdmEsIEhUTUwsIFhNTCwgbWFueSBtb3JlLiBGUkVFIDMwLURheSBUcmlhbC4NCgl3d3cu c2xpY2tlZGl0LmNvbS9zb3VyY2Vmb3JnZQ0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoJU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciBtYWlsaW5nIGxp c3QNCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KCWh0 dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3NwcmluZ2ZyYW1ld29y ay1kZXZlbG9wZXINCgkNCg0K |
|
From: Trevor C. <tc...@in...> - 2003-02-22 16:30:01
|
Naming - I agree that LocaleHandler is confusing. I like LocaleResolver, since it is consistent with the the ViewResolver classes. Interface - really good, but I don't think it's necessary to have locale as a parameter of setLocale, since that method will be determining the actual locale. What value be passed by the ControllerServlet for this parameter? Maybe it would be less confusing to make the signature: Locale resolveLocale(HttpServletRequest request, HttpServletResponse response); The signature now makes it clear that we are not "setting it" so much as asking the method to determine how it should be set. It also matches the viewResolver usage. An additional "setLocale" method with the signature you provided: void setLocale(HttpServletRequest request, HttpServletResponse response, Locale locale); could be used to explicitly override the Locale determined by the resolveLocale method. This would benefit Controller specific overrides (addressed below). As you noted, the response is necessary for cookie-based implementations (good catch). Configuration - I think that loading it as a bean reference (like "viewResolver") makes the most sense. If we provide an access method, this would allow individual Controllers to get a reference to the resolver and override the locale using the setLocale method mentioned above. I think the ControllerServlet should handle the locale resolution rather than a "LocaleHandler-per-Controller". If someone needs "normal" locale handling, I think the per-Controller method would require too much cut-n-paste type code. However, the exposed setLocale method would allow those who need to set it on a per-Controller basis the ability to do so. DefaultImplementation - I think "ClientLocaleHandler" is too general, since all LocaleHandlers (or LocaleResolvers as I prefer :) ) are making decisions based on the client. The default will be using the servlets default mechanism, so maybe "ServletLocaleResolver" or "RequestLocaleResolver" (although again, too me they're too general - I can't think of a really good name). We should also create additional implementations for distribution such as the cookie and session based versions, rather than requiring each client to code one themselves (although they will have the oppurtunity to do so). Great analysis Juergen! Trevor D. Cook --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03 |
|
From: <jh...@we...> - 2003-02-22 13:22:17
|
SGkgZXZlcnlib2R5LA0KIA0KSSd2ZSBiZWVuIHRoaW5raW5nIGFib3V0IHRoZSBpc3N1ZSBmb3Ig cXVpdGUgYSB3aGlsZSwgYW5kIGFjdHVhbGx5IEkgbGlrZSB0aGUgaWRlYSBvZiBhbiBpbnRlcmZh Y2UtYmFzZWQgc29sdXRpb24gdG9vLiBBbGxvd2luZyBmb3IgdXNlci1jaG9zZW4gbG9jYWxlcyB3 aXRob3V0IHJlcXVpcmluZyBhIHNlc3Npb24gZGVtYW5kcyBmb3IgYSBtb3JlIHNvcGhpc3RpY2F0 ZWQgc29sdXRpb24uIEkgd29uZGVyIGFib3V0IHRoZSBuYW1lOiBMb2NhbGVMb2NhdG9yPyBMb2Nh bGVQcm92aWRlcj8gTG9jYWxlUmVzb2x2ZXI/IExvY2FsZU1hbmFnZXI/IExvY2FsZUhhbmRsZXI/ IE9ubHkgdGhlIGxhdHRlciAyIGltcGx5IHJldHJpZXZhbCBhbmQgbWFuaXB1bGF0aW9uLiBQZXJz b25hbGx5LCBJIHByZWZlciBMb2NhbGVIYW5kbGVyIC0gdGhlIGRyYXdiYWNrIGJlaW5nIHRoYXQg Y29tLmludGVyZmFjZTIxLndlYi5zZXJ2bGV0IGFscmVhZHkgY29udGFpbnMgSGFuZGxlckFkYXB0 ZXIgYW5kIEhhbmRsZXJNYXBwaW5nLCB3aGljaCBjYW4gbGVhZCB0byBtaW5vciBjb25mdXNpb24u DQogDQpTbyB0aGUgaW50ZXJmYWNlIG1pZ2h0IGxvb2sgbGlrZSB0aGlzIChsZXQncyBvbWl0IHRo ZSB3b3JkICJzZXNzaW9uIiwgYXMgaXQgd291bGQgaW1wbHkgYSBIdHRwU2Vzc2lvbiBiZWluZyBp bnZvbHZlZCkgOg0KIA0KICBwdWJsaWMgaW50ZXJmYWNlIExvY2FsZUhhbmRsZXIgew0KICAgIExv Y2FsZSBnZXRMb2NhbGUoSHR0cFNlcnZsZXRSZXF1ZXN0IHJlcXVlc3QpOw0KICAgIHZvaWQgc2V0 TG9jYWxlKEh0dHBTZXJ2bGV0UmVxdWVzdCByZXF1ZXN0LCBIdHRwU2VydmxldFJlc3BvbnNlIHJl c3BvbnNlLCBMb2NhbGUgbG9jYWxlKTsNCiAgfQ0KIA0KTm90ZTogSSBjb25zaWRlciBzZXRMb2Nh bGUncyByZXNwb25zZSBwYXJhbWV0ZXIgbmVjZXNzYXJ5IHRvIGVuYWJsZSBjb29raWUtYmFzZWQg aW1wbGVtZW50YXRpb25zIHRoYXQgbmVlZCB0byBjYWxsIGFkZENvb2tpZS4NCiANCkNvbmNlcm5p bmcgdXNhZ2Ugb2YgdGhpcyBpbnRlcmZhY2UsIHdlIGhhdmUgdGhlIGZvbGxvd2luZyBjb25jcmV0 ZSByZXF1aXJlbWVudHM6DQotIExvY2FsZUhhbmRlciBpbnN0YW5jZXMgc2hvdWxkIGJlIGNvbmZp Z3VyYWJsZSB2aWEgdGhlIEJlYW5GYWN0b3J5Ow0KLSBhIENvbnRyb2xsZXJTZXJ2bGV0IG5lZWRz IGEgTG9jYWxlSGFuZGxlciBmb3IgY2hvb3NpbmcgYSB2aWV3Ow0KLSBhIENvbnRyb2xsZXIgaW5z dGFuY2UgbWF5IG5lZWQgYSBMb2NhbGVIYW5kbGVyIGZvciBsb2NhbGUtZGVwZW5kZW50IGFjdGlv bnMgYW5kL29yIHNldHRpbmcgYSB1c2VyIGxvY2FsZS4NCiANClRoZSBxdWVzdGlvbiBpczogSG93 IHRvIGNvbmZpZ3VyZSBMb2NhbGVIYW5kbGVycz8gU29tZSBpc3N1ZXM6DQotIEEgQ29udHJvbGxl clNlcnZsZXQgY2Fubm90IGdldCBhIExvY2FsZUhhbmRsZXIgYXMgYSBzcGVjaWZpZWQgYmVhbiBy ZWZlcmVuY2UsIHNvIGl0IHdvdWxkIGhhdmUgdG8gbG9vayBpdCB1cCBpbiBpdHMgYmVhbiBkZWZp bml0aW9ucyB1c2luZyBhIHN0YW5kYXJkIG5hbWUgKHNpbWlsYXIgdG8gInZpZXdSZXNvbHZlciIg YW5kICJtZXNzYWdlU291cmNlIikuDQotIEEgQ29udHJvbGxlciBjb3VsZCBnZXQgYSBMb2NhbGVI YW5kbGVyIGFzIGEgYmVhbiByZWZlcmVuY2UsIHNwZWNpZmllZCBhcyB1c3VhbCBpbiB0aGUgYmVh biBkZWZpbml0aW9ucyBvZiB0aGUgYXNzb2NpYXRlZCBDb250cm9sbGVyU2VydmxldC4gQSBjb3Jy ZXNwb25kaW5nIHByb3BlcnR5IHdpdGggYWNjZXNzIG1ldGhvZHMgY291bGQgYmUgcHJvdmlkZWQg YnkgQWJzdHJhY3RDb250cm9sbGVyLg0KLSBBbHRlcm5hdGl2ZWx5LCB3ZSBjb3VsZCB0cnkgdG8g c2V0IHRoZSBDb250cm9sbGVyU2VydmxldCdzIExvY2FsZUhhbmRsZXIgb24gQ29udHJvbGxlciBp bnN0YW5jZXMgdGhhdCBpbXBsZW1lbnQgYSBMb2NhbGVIYW5kbGVyQXdhcmUgaW50ZXJmYWNlLiBU aGlzIHdvdWxkIGludm9sdmUgbWFraW5nIEhhbmRsZXJNYXBwaW5nIGltcGxlbWVudCBMb2NhbGVI YW5kbGVyQXdhcmUgdG9vLCBhbmQgcHVzaGluZyB0aGUgTG9jYWxlSGFuZGxlciBmcm9tIENvbnRy b2xsZXJTZXJ2bGV0IHZpYSBIYW5kbGVyTWFwcGluZyB0byBDb250cm9sbGVyIGluc3RhbmNlcyAo dGh1cyBlZmZlY3RpdmVseSBvdmVyd3JpdGluZyByZXNwZWN0aXZlIGJlYW4gZmFjdG9yeSBzZXR0 aW5ncyBvZiB0aGUgQ29udHJvbGxlciBpbnN0YW5jZXMpLg0KLSBTbyB3ZSB3aWxsIGhhdmUgdG8g ZGVjaWRlIGJldHdlZW4gYSBMb2NhbGVIYW5kbGVyLXBlci1Db250cm9sbGVyIGFwcHJvYWNoIGFu ZCBhIExvY2FsZUhhbmRsZXItcGVyLUNvbnRyb2xsZXJTZXJ2bGV0IGFwcHJvYWNoLiBJIGd1ZXNz IHRoYXQgaW4gYWxtb3N0IGFsbCBhcHBsaWNhdGlvbnMgdGhlIGxhdHRlciB3b3VsZCBiZSBlbm91 Z2guIE9mIGNvdXJzZSwgd2UgY291bGQgYWxzbyBzdXBwb3J0IGJvdGggd2F5cyBieSBtYWtpbmcg dGhlIENvbnRyb2xsZXJTZXJ2bGV0J3MgcHVzaC10aHJvdWdoIGJlaGF2aW9yIGNvbmZpZ3VyYWJs ZSwgYnV0IHRoYXQgd291bGQgcHJvYmFibHkgYmUgcmF0aGVyIGNvbmZ1c2luZyBhbmQgbm90IGFk ZCBwcmFjdGljYWwgYmVuZWZpdHMuDQotIFRoZSBkZWZhdWx0IExvY2FsZUhhbmRsZXIgaW1wbGVt ZW50YXRpb24gc2hvdWxkIGJlIENsaWVudExvY2FsZUhhbmRsZXIgKG9yIGEgY2xhc3Mgd2l0aCBh IHNpbWlsYXIgbmFtZSksIHVzaW5nIHRoZSBjbGllbnQgcmVzcC4gYnJvd3NlciBzZXR0aW5nIHRo YXQgSHR0cFNlcnZsZXRSZXF1ZXN0IHByb3ZpZGVzIChpbnN0ZWFkIG9mIG51bGwgYXMgZGVmYXVs dCBMb2NhbGUgdmFsdWUpLg0KLSBBbiBhcHBsaWNhdGlvbiBwcm9ncmFtbWVyIHNob3VsZCBub3Qg bmVlZCB0byBjYXJlIGFib3V0IExvY2FsZXMgYW5kIExvY2FsZUhhbmRsZXJzIGluIHNpbmdsZSBs YW5ndWFnZSBhcHBsaWNhdGlvbnMuDQogDQpXaGF0IGRvIHlvdSBjb25zaWRlciBtb3N0IHZpYWJs ZT8NCiANCkp1ZXJnZW4NCiANCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0t LS0gDQoJVm9uOiBSb2QgSm9obnNvbiBbbWFpbHRvOnJvZC5qb2huc29uQGludGVyZmFjZTIxLmNv bV0gDQoJR2VzZW5kZXQ6IEZyIDIxLjAyLjIwMDMgMTI6NDggDQoJQW46IHNwcmluZ2ZyYW1ld29y ay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KCUNjOiANCglCZXRyZWZmOiBGdzog W1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIEV4cGxpY2l0IGxvY2FsZXMNCgkNCgkNCg0KCVJl cGx5LXRvIGFnYWluIQ0KCQ0KCS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCglGcm9tOiAi Um9kIEpvaG5zb24iIDxyb2Quam9obnNvbkBpbnRlcmZhY2UyMS5jb20+DQoJVG86ICJKUCBQQVdM QUsoVGlzY2FsaSkiIDxqcC5wYXdsYWtAdGlzY2FsaS5mcj4NCglTZW50OiBGcmlkYXksIEZlYnJ1 YXJ5IDIxLCAyMDAzIDc6NTggQU0NCglTdWJqZWN0OiBSZTogW1NwcmluZ2ZyYW1ld29yay1kZXZl bG9wZXJdIEV4cGxpY2l0IGxvY2FsZXMNCgkNCgkNCgk+IEplYW4tUGllcnJlJ3MgaW50ZXJmYWNl LWJhc2VkIHNvbHV0aW9uICh3aGljaCBJIGhhZG4ndCBzZWVuIGJlY2F1c2UgdGhlDQoJPiBhdHRh Y2htZW50IHdhcyB0b28gYmlnIGFuZCBJIGhhZCB0byBhcHByb3ZlIGl0IGZvciBpdCB0byBhcHBl YXIpIGlzIGFsb25nDQoJPiB0aGUgbGluZXMgSSdkIGVudmlzYWdlZC4gQ29uc2lzdGVudCB3aXRo IHRoZSBTcHJpbmcgd2F5LCBhcyBoZSBwb2ludHMgb3V0Lg0KCT4NCgk+IE9uZSBvZiB0aGUgaW1w bGVtZW50YXRpb25zIG9mIHRoZSBpbnRlcmZhY2UgY291bGQgc2ltcGx5IHVzZSBhIHNlc3Npb24g YXR0DQoJPiBhcyBKdWVyZ2VuIHN1Z2dlc3RzLg0KCT4NCgk+IEkgdGhpbmsgaXQgc2hvdWxkIGdv IGludG8gdGhlIGNvbnRyb2xsZXIgc2VydmxldC4NCgk+DQoJPiBXaGVyZSBkbyB3ZSBjYWNoZSBs b2NhbGUgaW5mb3JtYXRpb24/IEknbSBub3Qga2VlbiBvbiBjcmVhdGluZyBhIHNlc3Npb24NCglp Zg0KCT4gb25lIGRvZXNuJ3QgZXhpc3QsIGFzIEkgdGhpbmsgU3RydXRzIGRvZXMsIGJlY2F1c2Ug dGhpcyBjYW4gZ2V0IHVzIGludG8NCgk+IHJlcGxpY2F0aW9uIGlzc3VlcyBpbiBvdGhlcndpc2Ug c3RhdGVsZXNzIHdlYiBhcHBzLg0KCT4NCgk+IFRoZSBMb2NhbGVMb2NhdG9yIGlzIGFsc28gcmVh bGx5IGEgbWFuYWdlci4gTWF5YmUgb25lIGltcGxlbWVudGF0aW9uIGNvdWxkDQoJPiB1c2Ugc2Vz c2lvbnMsIGFub3RoZXIgY291bGQgdXNlIGNvb2tpZXMgZXRjLiBBcyBKZWFuLVBpZXJyZSBoYXMg ZG9uZSwgdGhlDQoJPiBiZWFuIGZhY3RvcnkgaXMgYSBwZXJmZWN0IHdheSB0byBjaG9vc2UuDQoJ Pg0KCT4gUm9kDQoJDQoNCg== |
|
From: Rod J. <rod...@in...> - 2003-02-21 11:55:12
|
Reply-to again!
----- Original Message -----
From: "Rod Johnson" <rod...@in...>
To: "JP PAWLAK(Tiscali)" <jp....@ti...>
Sent: Friday, February 21, 2003 7:58 AM
Subject: Re: [Springframework-developer] Explicit locales
> Jean-Pierre's interface-based solution (which I hadn't seen because the
> attachment was too big and I had to approve it for it to appear) is along
> the lines I'd envisaged. Consistent with the Spring way, as he points out.
>
> One of the implementations of the interface could simply use a session att
> as Juergen suggests.
>
> I think it should go into the controller servlet.
>
> Where do we cache locale information? I'm not keen on creating a session
if
> one doesn't exist, as I think Struts does, because this can get us into
> replication issues in otherwise stateless web apps.
>
> The LocaleLocator is also really a manager. Maybe one implementation could
> use sessions, another could use cookies etc. As Jean-Pierre has done, the
> bean factory is a perfect way to choose.
>
> Rod
>
> ----- Original Message -----
> From: "JP PAWLAK(Tiscali)" <jp....@ti...>
> To: "Spring Developers (E-mail)"
> <spr...@li...>
> Sent: Friday, February 21, 2003 7:03 AM
> Subject: TR : [Springframework-developer] Explicit locales
>
>
> Envoyé : jeudi 20 février 2003 22:50
> À : 'Trevor Cook'
> Objet : RE : [Springframework-developer] Explicit locales
>
>
>
> I use a solution near of yours but with a more generalist approach. To
> keep the users locale, different possibilities exist: session, cookie,
> URL. But each solution can be handled knowing the request object. So I
> use a bean for implementing the effective strategy in the way of the
> general spirit of Spring.
>
> 1) Create a simple interface like this:
>
> public interface LocaleLocator {
>
> Locale getSessionLocale(HttpServletRequest request);
>
> void setSessionLocale(HttpServletRequest request, Locale
> sessionLocale);
>
> }
>
> 2) Create an implementation class which in your case handles with the
> cookies, but which can use the session or what method you like.
>
> 3) Overriding the ControllerServlet to use a LocaleLocator property with
> at least the setter, so the implementation class can be done in the
> servlet-configuration file.
>
> <bean name="localeLocator" singleton="true"
> class="perso.jpp.fwk.web.LocaleLocatorImpl" />
>
> <bean name="jstlHandler" singleton="true"
> class="perso.jpp.fwk.web.JstlHandlerImpl" >
>
> <property name="bundleName">achappro</property>
>
> </bean>
>
>
>
> code added in declaration part:
>
> // Added by JPP
>
> /** The bean name allowing the user session locale to be retrieved
> */
>
> public static final String LOCALE_LOCATOR = "localeLocator";
>
>
>
> /** The bean name allowing the jstl ressouece bundle to be set */
>
> public static final String JSTL_HANDLER = "jstlHandler";
>
>
>
> /** LocaleLocator used by this servlet
>
> * If not provided, request.getLocale() will be used instead */
>
> private LocaleLocator localeLocator;
>
> // End added
>
>
>
>
>
> code added in ControllerServlet (or descendent) at end of
> initFrameworkServlet :
>
> initViewResolver();
>
>
>
> // Added by JPP
>
> try {
>
> localeLocator = (LocaleLocator)
>
>
> getWebApplicationContext().getBean(LOCALE_LOCATOR);
>
> logger.config("localeLocator found in servlet '" +
> getServletName()
>
> + "' : " + localeLocator.getClass().getName());
>
> } catch(Exception e) {
>
> localeLocator = null; // Not required as it should
> yet been null
>
> logger.config("No localeLocator found in servlet '" +
> getServletName() + "', request Locale will be used.");
>
> }
>
> // Jstl handling
>
> // Put only in a subclass ? But Jstl is ageneric use
>
> // The ApplicationContextAware doesn't provide an access to
> the servletContext
>
> // It's the reason of an initialisation here. Exists a best
> approach ?
>
> try {
>
> JstlHandler jstlHandler = (JstlHandler)
>
>
> getWebApplicationContext().getBean(JSTL_HANDLER);
>
> jstlHandler.setServletCtx(this.getServletContext());
>
> logger.config("jstlHandler found in servlet '" +
> getServletName()
>
> + "' : " + jstlHandler.getClass().getName());
>
> } catch(Exception e) {
>
> logger.config("No jstlHandler found in servlet '" +
> getServletName());
>
> }
>
>
>
> // End added
>
>
>
> 4) As you can see, I handle I a same way the definition of locale and
> bundle for JSTL.
>
> 5) The LocaleLocator can be donated by beanref property to objects which
> have to know the current locale having the request object.
>
>
>
> I hope this will be a useful add-on in this discussion. I suggest to
> integrate a such behaviour in the original ControllerServlet as thes
> needs are very generally.
>
>
>
> Regards,
>
> Jean-Pierre
>
>
>
> -----Message d'origine-----
> De : spr...@li...
> [mailto:spr...@li...] De la
> part de Trevor Cook
> Envoyé : jeudi 20 février 2003 21:38
> À : Spring Developers (E-mail)
> Objet : RE: [Springframework-developer] Explicit locales
>
>
>
> It sounds like you're on the right track, and your approach should work
> for my stuff. I've already implemented some of this (code below) by
> overriding ControllerServlet and checking for a cookie in doService
> before passing control up. I store the locale in a persistent cookie so
> that no session is created for simple site browsing, and to remember
> chosen language for future visits. I'm sure my approach could be
> improved alot, but it's just a prototype (so I could get my html guy to
> start working).
>
> When you're implementing it, a few suggestions/ideas/requests. If this
> is put into the framework, you probably want to allow the developer to
> specify whether to make it cookie or session-based. If it is
> cookie-based, you'll probably also need to allow the developer to
> specify browser or persistent (including max age).
>
> Trevor D. Cook
>
>
>
> public class LocaleServletController extends ControllerServlet {
>
> public static final String LOCALE_HANDLE = "locale";
>
> protected void doService(
>
> HttpServletRequest request,
>
> HttpServletResponse response,
>
> boolean debugMode)
>
> throws ServletException, IOException {
>
> String locale = request.getParameter(LOCALE_HANDLE);
>
> if (locale != null) {
>
> logger.info("Setting locale to: " + locale);
>
> setLocaleCookie(request, response, locale);
>
> } else {
>
> getLocale(request);
>
> }
>
> super.doService(request, response, debugMode);
>
> }
>
> private void getLocale(HttpServletRequest request) {
>
> Cookie[] cookies = request.getCookies();
>
> int cookiesSize = cookies.length;
>
> for (int i = 0; i < cookiesSize; i++) {
>
> if (LOCALE_HANDLE.equals(cookies[i].getName())) {
>
> String localeCookie = cookies[i].getValue();
>
> setLocale(request, localeCookie);
>
> }
>
> }
>
> }
>
> private void setLocaleCookie(
>
> HttpServletRequest request,
>
> HttpServletResponse response,
>
> String localeString) {
>
> Locale locale = setLocale(request, localeString);
>
> Cookie localeCookie = new Cookie(LOCALE_HANDLE, localeString);
>
> if (locale.equals(request.getLocale())) {
>
> localeCookie.setMaxAge(-1);
>
> } else {
>
> localeCookie.setMaxAge(365 * 24 * 60 * 60);
>
> }
>
> response.addCookie(localeCookie);
>
> }
>
> private Locale setLocale(
>
> HttpServletRequest request,
>
> String localeString) {
>
> Locale locale =
>
> new Locale(localeString.substring(0, 2), localeString.substring(2));
>
> request.setAttribute("locale", locale);
>
> return locale;
>
> }
>
> }
>
>
>
>
>
> -----Original Message-----
> From: jürgen höller [werk3AT] [mailto:jue...@we...]
> Sent: February 20, 2003 3:21 PM
> To: Spring Developers (E-mail)
> Subject: Re: [Springframework-developer] Explicit locales
>
> Trevor,
>
>
>
> I've noticed that issue too. We definitely need support for a manually
> set locale in the session, already for 1.0. I consider 1. the only
> viable option but I think of a very easy and generic way: Why not just
> define a Spring standard name for a session attribute that can contain a
> Locale instance? The ControllerServlet could first check the session for
> such an attribute and fall back to the request locale.
>
>
>
> A custom application will probably not support changing the locale with
> every possible action but rather with a special one controller URL. That
> controller implementation could put a respective attribute into the
> session, with the given standard name, and update user preferences in
> the database or set a respective cookie if desired. Of course, the
> user's locale has to be retrieved for a new session - that could happen
> after login in a login controller, or in a custom filter that checks for
> a certain cookie.
>
>
>
> So the minimal framework support needed seems to be the definition of a
> standard name for a session locale, and checking the session when
> determining a view in the ControllerServlet. Of course, custom
> applications can not only set that locale but also retrieve it in
> controllers that perform locale-specific actions.
>
>
>
> I'm currently in the process of polishing Spring's web part (probably
> taking over responsibility for it, at least for 1.0), so I could add
> such locale support easily. Would the outlined approach be sufficient
> for you? If yes, I will add that support prompty, probably commiting the
> changes at the beginning of next week.
>
>
>
> Regards,
>
> Juergen
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Trevor Cook [mailto:tc...@in...]
> Gesendet: Donnerstag, 20. Februar 2003 03:55
> An: Spring Developers (E-mail)
> Betreff: [Springframework-developer] Explicit locales
>
> I have a business requirement of handling multiple locales.
> Specifically, I live in Canada, and the application must be available in
> French and English. However, due to multiple users on a single
> computer, we cannot rely solely on the users locale settings. What we
> need to do is default to the users locale, but provide them with the
> ability to override these settings (probably by clicking an
> "English/French" link).
>
> Anyway, the framework question I have is "is there anyway to do this
> currently"? Looking at the controller servlet, it returns a view based
> on "request.getLocale()". This can't be changed, so I can't see any way
> to customize/change it. My ideas are:
>
> 1. Have an explicit object in the request attribute for the locale with
> a "hook" to define how the default is determined (request locale,
> cookie, session, etc.). The view (or any other locale "lookup") would
> be based on this attribute.
>
> 2. Wrap the request/response objects in the control servlet, and provide
> hooks for these wrappers (which could override the getLocale() method).
>
> 3. Have the view return a generic view, and have the view contain
> code/taglibs which do the locale stuff in it.
>
> 4. Any other ideas?
>
> My "rating" of my own arguments is that 1 is the best since it abstracts
> the locale to the start of the servlet request as an initial parameter
> (which is how I consider it). 2 requires a lot of customization to
> support what appears to be something others might use (however, the
> ability to override other methods might be desirable). 3 is ugly code,
> and removes all the benefits of Rod's framework for seamlessly handling
> the locale issues.
>
> We probably can't make any of these changes for the 1.0 release (if we
> can great, but I'm trying to be realistic) but I was looking for some
> ideas and counter-arguments. I need to go ahead with this project (I'm
> actually waiting on this issue right now, but I think I've bought myself
> till Monday :) ) so I'll probably need to make my own modifications to a
> local copy of the code, but if my direction makes sense to everyone, I
> can probably polish/generalize my changes and roll it into the main
> stream in a future release.
>
> Trevor D. Cook
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03
>
>
>
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
>
>
>
>
|
|
From: Rod J. <rod...@in...> - 2003-02-21 07:22:33
|
Guys, I was aware that this was something that needed to be addressed. Certainly it's a 1.0 thing. Juergen's proposal seems simple and effective. I think it's what Struts does. Trevor's suggestion of a "hook" is interesting. It would be great for testing etc. to be able to configure it flexibly. Imagine if a user's locale preferences were even held in a DB? Can we parameterize based on a LocaleProvider interface? (Haven't had time to read Trevor's code--apologies if you've already considered this). Regards, Rod ----- Original Message ----- From: "jürgen höller [werk3AT]" <jue...@we...> To: "Spring Developers (E-mail)" <spr...@li...> Sent: Thursday, February 20, 2003 8:20 PM Subject: Re: [Springframework-developer] Explicit locales Trevor, I've noticed that issue too. We definitely need support for a manually set locale in the session, already for 1.0. I consider 1. the only viable option but I think of a very easy and generic way: Why not just define a Spring standard name for a session attribute that can contain a Locale instance? The ControllerServlet could first check the session for such an attribute and fall back to the request locale. A custom application will probably not support changing the locale with every possible action but rather with a special one controller URL. That controller implementation could put a respective attribute into the session, with the given standard name, and update user preferences in the database or set a respective cookie if desired. Of course, the user's locale has to be retrieved for a new session - that could happen after login in a login controller, or in a custom filter that checks for a certain cookie. So the minimal framework support needed seems to be the definition of a standard name for a session locale, and checking the session when determining a view in the ControllerServlet. Of course, custom applications can not only set that locale but also retrieve it in controllers that perform locale-specific actions. I'm currently in the process of polishing Spring's web part (probably taking over responsibility for it, at least for 1.0), so I could add such locale support easily. Would the outlined approach be sufficient for you? If yes, I will add that support prompty, probably commiting the changes at the beginning of next week. Regards, Juergen -----Ursprüngliche Nachricht----- Von: Trevor Cook [mailto:tc...@in...] Gesendet: Donnerstag, 20. Februar 2003 03:55 An: Spring Developers (E-mail) Betreff: [Springframework-developer] Explicit locales I have a business requirement of handling multiple locales. Specifically, I live in Canada, and the application must be available in French and English. However, due to multiple users on a single computer, we cannot rely solely on the users locale settings. What we need to do is default to the users locale, but provide them with the ability to override these settings (probably by clicking an "English/French" link). Anyway, the framework question I have is "is there anyway to do this currently"? Looking at the controller servlet, it returns a view based on "request.getLocale()". This can't be changed, so I can't see any way to customize/change it. My ideas are: 1. Have an explicit object in the request attribute for the locale with a "hook" to define how the default is determined (request locale, cookie, session, etc.). The view (or any other locale "lookup") would be based on this attribute. 2. Wrap the request/response objects in the control servlet, and provide hooks for these wrappers (which could override the getLocale() method). 3. Have the view return a generic view, and have the view contain code/taglibs which do the locale stuff in it. 4. Any other ideas? My "rating" of my own arguments is that 1 is the best since it abstracts the locale to the start of the servlet request as an initial parameter (which is how I consider it). 2 requires a lot of customization to support what appears to be something others might use (however, the ability to override other methods might be desirable). 3 is ugly code, and removes all the benefits of Rod's framework for seamlessly handling the locale issues. We probably can't make any of these changes for the 1.0 release (if we can great, but I'm trying to be realistic) but I was looking for some ideas and counter-arguments. I need to go ahead with this project (I'm actually waiting on this issue right now, but I think I've bought myself till Monday :) ) so I'll probably need to make my own modifications to a local copy of the code, but if my direction makes sense to everyone, I can probably polish/generalize my changes and roll it into the main stream in a future release. Trevor D. Cook --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03 |
|
From: JP PAWLAK\(Tiscali\) <jp....@ti...> - 2003-02-21 07:04:09
|
Envoy=E9 : jeudi 20 f=E9vrier 2003 22:50
=C0 : 'Trevor Cook'
Objet : RE : [Springframework-developer] Explicit locales
=20
I use a solution near of yours but with a more generalist approach. To
keep the users locale, different possibilities exist: session, cookie,
URL. But each solution can be handled knowing the request object. So I
use a bean for implementing the effective strategy in the way of the
general spirit of Spring.
1) Create a simple interface like this:
public interface LocaleLocator {
Locale getSessionLocale(HttpServletRequest request);
void setSessionLocale(HttpServletRequest request, Locale
sessionLocale);
}
2) Create an implementation class which in your case handles with the
cookies, but which can use the session or what method you like.
3) Overriding the ControllerServlet to use a LocaleLocator property with
at least the setter, so the implementation class can be done in the
servlet-configuration file.
<bean name=3D"localeLocator" singleton=3D"true"
class=3D"perso.jpp.fwk.web.LocaleLocatorImpl" /> =20
<bean name=3D"jstlHandler" singleton=3D"true"
class=3D"perso.jpp.fwk.web.JstlHandlerImpl" > =20
<property name=3D"bundleName">achappro</property>
</bean>
=20
code added in declaration part:
// Added by JPP
/** The bean name allowing the user session locale to be retrieved
*/=20
public static final String LOCALE_LOCATOR =3D "localeLocator";
=20
/** The bean name allowing the jstl ressouece bundle to be set */=20
public static final String JSTL_HANDLER =3D "jstlHandler";
=20
/** LocaleLocator used by this servlet
* If not provided, request.getLocale() will be used instead */ =20
private LocaleLocator localeLocator;
// End added
=20
=20
code added in ControllerServlet (or descendent) at end of
initFrameworkServlet :
initViewResolver();
=20
// Added by JPP
try {
localeLocator =3D (LocaleLocator)
=20
getWebApplicationContext().getBean(LOCALE_LOCATOR);=20
logger.config("localeLocator found in servlet '" +
getServletName()=20
+ "' : " + localeLocator.getClass().getName());
} catch(Exception e) {
localeLocator =3D null; // Not required as it should
yet been null
logger.config("No localeLocator found in servlet '" +
getServletName() + "', request Locale will be used.");
}
// Jstl handling
// Put only in a subclass ? But Jstl is ageneric use
// The ApplicationContextAware doesn't provide an access to
the servletContext
// It's the reason of an initialisation here. Exists a best
approach ?
try {
JstlHandler jstlHandler =3D (JstlHandler) =20
=20
getWebApplicationContext().getBean(JSTL_HANDLER);=20
jstlHandler.setServletCtx(this.getServletContext());
logger.config("jstlHandler found in servlet '" +
getServletName()=20
+ "' : " + jstlHandler.getClass().getName());
} catch(Exception e) {
logger.config("No jstlHandler found in servlet '" +
getServletName());
}
=20
// End added
=20
4) As you can see, I handle I a same way the definition of locale and
bundle for JSTL.
5) The LocaleLocator can be donated by beanref property to objects which
have to know the current locale having the request object.
=20
I hope this will be a useful add-on in this discussion. I suggest to
integrate a such behaviour in the original ControllerServlet as thes
needs are very generally.
=20
Regards,
Jean-Pierre
=20
-----Message d'origine-----
De : spr...@li...
[mailto:spr...@li...] De la
part de Trevor Cook
Envoy=E9 : jeudi 20 f=E9vrier 2003 21:38
=C0 : Spring Developers (E-mail)
Objet : RE: [Springframework-developer] Explicit locales
=20
It sounds like you're on the right track, and your approach should work
for my stuff. I've already implemented some of this (code below) by
overriding ControllerServlet and checking for a cookie in doService
before passing control up. I store the locale in a persistent cookie so
that no session is created for simple site browsing, and to remember
chosen language for future visits. I'm sure my approach could be
improved alot, but it's just a prototype (so I could get my html guy to
start working).
When you're implementing it, a few suggestions/ideas/requests. If this
is put into the framework, you probably want to allow the developer to
specify whether to make it cookie or session-based. If it is
cookie-based, you'll probably also need to allow the developer to
specify browser or persistent (including max age).
Trevor D. Cook
=20
public class LocaleServletController extends ControllerServlet {
public static final String LOCALE_HANDLE =3D "locale";
protected void doService(
HttpServletRequest request,
HttpServletResponse response,
boolean debugMode)
throws ServletException, IOException {
String locale =3D request.getParameter(LOCALE_HANDLE);
if (locale !=3D null) {
logger.info("Setting locale to: " + locale);
setLocaleCookie(request, response, locale);=20
} else {
getLocale(request);
}
super.doService(request, response, debugMode);
}
private void getLocale(HttpServletRequest request) {
Cookie[] cookies =3D request.getCookies();
int cookiesSize =3D cookies.length;
for (int i =3D 0; i < cookiesSize; i++) {
if (LOCALE_HANDLE.equals(cookies[i].getName())) {
String localeCookie =3D cookies[i].getValue();
setLocale(request, localeCookie);
}
}
}
private void setLocaleCookie(
HttpServletRequest request,
HttpServletResponse response,
String localeString) {
Locale locale =3D setLocale(request, localeString);
Cookie localeCookie =3D new Cookie(LOCALE_HANDLE, localeString);
if (locale.equals(request.getLocale())) {
localeCookie.setMaxAge(-1);
} else {
localeCookie.setMaxAge(365 * 24 * 60 * 60);
}
response.addCookie(localeCookie);
}
private Locale setLocale(
HttpServletRequest request,
String localeString) {
Locale locale =3D
new Locale(localeString.substring(0, 2), localeString.substring(2));
request.setAttribute("locale", locale);
return locale;
}
}
=20
=20
-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]
Sent: February 20, 2003 3:21 PM
To: Spring Developers (E-mail)
Subject: Re: [Springframework-developer] Explicit locales
Trevor,
=20
I've noticed that issue too. We definitely need support for a manually
set locale in the session, already for 1.0. I consider 1. the only
viable option but I think of a very easy and generic way: Why not just
define a Spring standard name for a session attribute that can contain a
Locale instance? The ControllerServlet could first check the session for
such an attribute and fall back to the request locale.
=20
A custom application will probably not support changing the locale with
every possible action but rather with a special one controller URL. That
controller implementation could put a respective attribute into the
session, with the given standard name, and update user preferences in
the database or set a respective cookie if desired. Of course, the
user's locale has to be retrieved for a new session - that could happen
after login in a login controller, or in a custom filter that checks for
a certain cookie.
=20
So the minimal framework support needed seems to be the definition of a
standard name for a session locale, and checking the session when
determining a view in the ControllerServlet. Of course, custom
applications can not only set that locale but also retrieve it in
controllers that perform locale-specific actions.
=20
I'm currently in the process of polishing Spring's web part (probably
taking over responsibility for it, at least for 1.0), so I could add
such locale support easily. Would the outlined approach be sufficient
for you? If yes, I will add that support prompty, probably commiting the
changes at the beginning of next week.
=20
Regards,
Juergen
=20
=20
-----Urspr=FCngliche Nachricht-----
Von: Trevor Cook [mailto:tc...@in...]=20
Gesendet: Donnerstag, 20. Februar 2003 03:55
An: Spring Developers (E-mail)
Betreff: [Springframework-developer] Explicit locales
I have a business requirement of handling multiple locales.
Specifically, I live in Canada, and the application must be available in
French and English. However, due to multiple users on a single
computer, we cannot rely solely on the users locale settings. What we
need to do is default to the users locale, but provide them with the
ability to override these settings (probably by clicking an
"English/French" link).
Anyway, the framework question I have is "is there anyway to do this
currently"? Looking at the controller servlet, it returns a view based
on "request.getLocale()". This can't be changed, so I can't see any way
to customize/change it. My ideas are:
1. Have an explicit object in the request attribute for the locale with
a "hook" to define how the default is determined (request locale,
cookie, session, etc.). The view (or any other locale "lookup") would
be based on this attribute.
2. Wrap the request/response objects in the control servlet, and provide
hooks for these wrappers (which could override the getLocale() method).
3. Have the view return a generic view, and have the view contain
code/taglibs which do the locale stuff in it.=20
4. Any other ideas?=20
My "rating" of my own arguments is that 1 is the best since it abstracts
the locale to the start of the servlet request as an initial parameter
(which is how I consider it). 2 requires a lot of customization to
support what appears to be something others might use (however, the
ability to override other methods might be desirable). 3 is ugly code,
and removes all the benefits of Rod's framework for seamlessly handling
the locale issues.
We probably can't make any of these changes for the 1.0 release (if we
can great, but I'm trying to be realistic) but I was looking for some
ideas and counter-arguments. I need to go ahead with this project (I'm
actually waiting on this issue right now, but I think I've bought myself
till Monday :) ) so I'll probably need to make my own modifications to a
local copy of the code, but if my direction makes sense to everyone, I
can probably polish/generalize my changes and roll it into the main
stream in a future release.
Trevor D. Cook=20
=20
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03
=20
=20
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
|
|
From: Trevor C. <tc...@in...> - 2003-02-20 20:37:04
|
It sounds like you're on the right track, and your approach should work =
for
my stuff. I've already implemented some of this (code below) by =
overriding
ControllerServlet and checking for a cookie in doService before passing
control up. I store the locale in a persistent cookie so that no =
session is
created for simple site browsing, and to remember chosen language for =
future
visits. I'm sure my approach could be improved alot, but it's just a
prototype (so I could get my html guy to start working).
When you're implementing it, a few suggestions/ideas/requests. If this =
is
put into the framework, you probably want to allow the developer to =
specify
whether to make it cookie or session-based. If it is cookie-based, =
you'll
probably also need to allow the developer to specify browser or =
persistent
(including max age).
Trevor D. Cook
=20
public class LocaleServletController extends ControllerServlet {
public static final String LOCALE_HANDLE =3D "locale";
protected void doService(
HttpServletRequest request,
HttpServletResponse response,
boolean debugMode)
throws ServletException, IOException {
String locale =3D request.getParameter(LOCALE_HANDLE);
if (locale !=3D null) {
logger.info("Setting locale to: " + locale);
setLocaleCookie(request, response, locale);=20
} else {
getLocale(request);
}
super.doService(request, response, debugMode);
}
private void getLocale(HttpServletRequest request) {
Cookie[] cookies =3D request.getCookies();
int cookiesSize =3D cookies.length;
for (int i =3D 0; i < cookiesSize; i++) {
if (LOCALE_HANDLE.equals(cookies[i].getName())) {
String localeCookie =3D cookies[i].getValue();
setLocale(request, localeCookie);
}
}
}
private void setLocaleCookie(
HttpServletRequest request,
HttpServletResponse response,
String localeString) {
Locale locale =3D setLocale(request, localeString);
Cookie localeCookie =3D new Cookie(LOCALE_HANDLE, localeString);
if (locale.equals(request.getLocale())) {
localeCookie.setMaxAge(-1);
} else {
localeCookie.setMaxAge(365 * 24 * 60 * 60);
}
response.addCookie(localeCookie);
}
private Locale setLocale(
HttpServletRequest request,
String localeString) {
Locale locale =3D
new Locale(localeString.substring(0, 2), localeString.substring(2));
request.setAttribute("locale", locale);
return locale;
}
}
=20
=20
-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]
Sent: February 20, 2003 3:21 PM
To: Spring Developers (E-mail)
Subject: Re: [Springframework-developer] Explicit locales
Trevor,
=20
I've noticed that issue too. We definitely need support for a manually =
set
locale in the session, already for 1.0. I consider 1. the only viable =
option
but I think of a very easy and generic way: Why not just define a =
Spring
standard name for a session attribute that can contain a Locale =
instance?
The ControllerServlet could first check the session for such an =
attribute
and fall back to the request locale.
=20
A custom application will probably not support changing the locale with
every possible action but rather with a special one controller URL. =
That
controller implementation could put a respective attribute into the =
session,
with the given standard name, and update user preferences in the =
database or
set a respective cookie if desired. Of course, the user's locale has to =
be
retrieved for a new session - that could happen after login in a login
controller, or in a custom filter that checks for a certain cookie.
=20
So the minimal framework support needed seems to be the definition of a
standard name for a session locale, and checking the session when
determining a view in the ControllerServlet. Of course, custom =
applications
can not only set that locale but also retrieve it in controllers that
perform locale-specific actions.
=20
I'm currently in the process of polishing Spring's web part (probably =
taking
over responsibility for it, at least for 1.0), so I could add such =
locale
support easily. Would the outlined approach be sufficient for you? If =
yes, I
will add that support prompty, probably commiting the changes at the
beginning of next week.
=20
Regards,
Juergen
=20
=20
-----Urspr=FCngliche Nachricht-----
Von: Trevor Cook [mailto:tc...@in...]=20
Gesendet: Donnerstag, 20. Februar 2003 03:55
An: Spring Developers (E-mail)
Betreff: [Springframework-developer] Explicit locales
I have a business requirement of handling multiple locales. =
Specifically, I
live in Canada, and the application must be available in French and =
English.
However, due to multiple users on a single computer, we cannot rely =
solely
on the users locale settings. What we need to do is default to the =
users
locale, but provide them with the ability to override these settings
(probably by clicking an "English/French" link).
Anyway, the framework question I have is "is there anyway to do this
currently"? Looking at the controller servlet, it returns a view based =
on
"request.getLocale()". This can't be changed, so I can't see any way =
to
customize/change it. My ideas are:
1. Have an explicit object in the request attribute for the locale with =
a
"hook" to define how the default is determined (request locale, cookie,
session, etc.). The view (or any other locale "lookup") would be based =
on
this attribute.
2. Wrap the request/response objects in the control servlet, and =
provide
hooks for these wrappers (which could override the getLocale() method).
3. Have the view return a generic view, and have the view contain
code/taglibs which do the locale stuff in it.=20
4. Any other ideas?=20
My "rating" of my own arguments is that 1 is the best since it =
abstracts the
locale to the start of the servlet request as an initial parameter =
(which is
how I consider it). 2 requires a lot of customization to support what
appears to be something others might use (however, the ability to =
override
other methods might be desirable). 3 is ugly code, and removes all the
benefits of Rod's framework for seamlessly handling the locale issues.
We probably can't make any of these changes for the 1.0 release (if we =
can
great, but I'm trying to be realistic) but I was looking for some ideas =
and
counter-arguments. I need to go ahead with this project (I'm actually
waiting on this issue right now, but I think I've bought myself till =
Monday
:) ) so I'll probably need to make my own modifications to a local copy =
of
the code, but if my direction makes sense to everyone, I can probably
polish/generalize my changes and roll it into the main stream in a =
future
release.
Trevor D. Cook=20
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system ( HYPERLINK "http://www.grisoft.com"
\nhttp://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03
=20
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.456 / Virus Database: 256 - Release Date: 2/18/03
=20
|
|
From: <jue...@we...> - 2003-02-20 20:21:26
|
Trevor, =20 I've noticed that issue too. We definitely need support for a manually = set locale in the session, already for 1.0. I consider 1. the only = viable option but I think of a very easy and generic way: Why not just = define a Spring standard name for a session attribute that can contain a = Locale instance? The ControllerServlet could first check the session for = such an attribute and fall back to the request locale. =20 A custom application will probably not support changing the locale with = every possible action but rather with a special one controller URL. That = controller implementation could put a respective attribute into the = session, with the given standard name, and update user preferences in = the database or set a respective cookie if desired. Of course, the = user's locale has to be retrieved for a new session - that could happen = after login in a login controller, or in a custom filter that checks for = a certain cookie. =20 So the minimal framework support needed seems to be the definition of a = standard name for a session locale, and checking the session when = determining a view in the ControllerServlet. Of course, custom = applications can not only set that locale but also retrieve it in = controllers that perform locale-specific actions. =20 I'm currently in the process of polishing Spring's web part (probably = taking over responsibility for it, at least for 1.0), so I could add = such locale support easily. Would the outlined approach be sufficient = for you? If yes, I will add that support prompty, probably commiting the = changes at the beginning of next week. =20 Regards, Juergen =20 =20 -----Urspr=FCngliche Nachricht----- Von: Trevor Cook [mailto:tc...@in...]=20 Gesendet: Donnerstag, 20. Februar 2003 03:55 An: Spring Developers (E-mail) Betreff: [Springframework-developer] Explicit locales =09 =09 I have a business requirement of handling multiple locales. = Specifically, I live in Canada, and the application must be available in = French and English. However, due to multiple users on a single = computer, we cannot rely solely on the users locale settings. What we = need to do is default to the users locale, but provide them with the = ability to override these settings (probably by clicking an = "English/French" link). Anyway, the framework question I have is "is there anyway to do this = currently"? Looking at the controller servlet, it returns a view based = on "request.getLocale()". This can't be changed, so I can't see any way = to customize/change it. My ideas are: 1. Have an explicit object in the request attribute for the locale with = a "hook" to define how the default is determined (request locale, = cookie, session, etc.). The view (or any other locale "lookup") would = be based on this attribute. 2. Wrap the request/response objects in the control servlet, and = provide hooks for these wrappers (which could override the getLocale() = method). 3. Have the view return a generic view, and have the view contain = code/taglibs which do the locale stuff in it.=20 4. Any other ideas?=20 My "rating" of my own arguments is that 1 is the best since it = abstracts the locale to the start of the servlet request as an initial = parameter (which is how I consider it). 2 requires a lot of = customization to support what appears to be something others might use = (however, the ability to override other methods might be desirable). 3 = is ugly code, and removes all the benefits of Rod's framework for = seamlessly handling the locale issues. We probably can't make any of these changes for the 1.0 release (if we = can great, but I'm trying to be realistic) but I was looking for some = ideas and counter-arguments. I need to go ahead with this project (I'm = actually waiting on this issue right now, but I think I've bought myself = till Monday :) ) so I'll probably need to make my own modifications to a = local copy of the code, but if my direction makes sense to everyone, I = can probably polish/generalize my changes and roll it into the main = stream in a future release. Trevor D. Cook=20 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03 =20 |
|
From: Trevor C. <tc...@in...> - 2003-02-20 02:54:29
|
I have a business requirement of handling multiple locales. Specifically, I live in Canada, and the application must be available in French and English. However, due to multiple users on a single computer, we cannot rely solely on the users locale settings. What we need to do is default to the users locale, but provide them with the ability to override these settings (probably by clicking an "English/French" link). Anyway, the framework question I have is "is there anyway to do this currently"? Looking at the controller servlet, it returns a view based on "request.getLocale()". This can't be changed, so I can't see any way to customize/change it. My ideas are: 1. Have an explicit object in the request attribute for the locale with a "hook" to define how the default is determined (request locale, cookie, session, etc.). The view (or any other locale "lookup") would be based on this attribute. 2. Wrap the request/response objects in the control servlet, and provide hooks for these wrappers (which could override the getLocale() method). 3. Have the view return a generic view, and have the view contain code/taglibs which do the locale stuff in it. 4. Any other ideas? My "rating" of my own arguments is that 1 is the best since it abstracts the locale to the start of the servlet request as an initial parameter (which is how I consider it). 2 requires a lot of customization to support what appears to be something others might use (however, the ability to override other methods might be desirable). 3 is ugly code, and removes all the benefits of Rod's framework for seamlessly handling the locale issues. We probably can't make any of these changes for the 1.0 release (if we can great, but I'm trying to be realistic) but I was looking for some ideas and counter-arguments. I need to go ahead with this project (I'm actually waiting on this issue right now, but I think I've bought myself till Monday :) ) so I'll probably need to make my own modifications to a local copy of the code, but if my direction makes sense to everyone, I can probably polish/generalize my changes and roll it into the main stream in a future release. Trevor D. Cook --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03 |
|
From: <jue...@we...> - 2003-02-18 15:45:07
|
"Reply to" address, a second time... =20 =20 -----Urspr=FCngliche Nachricht----- Von: j=FCrgen h=F6ller [werk3AT]=20 Gesendet: Freitag, 14. Februar 2003 21:00 An: Rod Johnson Betreff: Re: [Springframework-developer] Optional dependencies Rod, =20 Let's simply include the relevant JARs in the CVS lib directory. = Developers shouldn't care about some additional JARs even if they aren't = interested in them. The same rule applies to the current view = implementations that depend on Velocity and co. Of course, a dependency = table is a must, at least at the subpackage level of the Spring = codebase. =20 Regarding Struts: I guess it should be possible to include only the = relevant JARs and ignore the convenience stuff, like some of the Commons = packages. Ideally, that would mean just a struts.jar, not the whole army = that comes with a Struts distribution. Of course, the unit tests need to = be able to run, so this might be more sophisticated that I assume. =20 Concerning the distribution: I don't mind including such classes in the = standard Spring JARs, as they wouldn't need any of the third party = libraries if they are not actually used at runtime. I've used that = approach successfully numerous times within application projects, for = example in terms of separation of remote client and server classes, or = web application and applet codebase. Spring users that want to enable a = plugin should have to download the respective libraries from the third = party's site. That instructions need to be mentioned in a readme.=20 =20 Take for example Tomcat 4.x: Its distribution includes Tyrex-dependent = factory classes for its JNDI resource manager even though it doesn't = include the Tyrex libraries. Users have to download the Tyrex libraries = themselves from the ExoLab site. I don't know about Tomcat's CVS = contents, but I assume that the developers do have the Tyrex libraries = there. =20 In terms of repository size, including third party libraries should not = make a big difference. I assume that those libraries will change rarely, = at least in the Spring CVS, as we don't need to follow every minor = update. So CVS updates will usually ignore them and not cause additional = download traffic after initial checkout. =20 Regards, Juergen =20 =20 -----Urspr=FCngliche Nachricht-----=20 Von: Rod Johnson [mailto:rod...@in...]=20 Gesendet: Fr 14.02.2003 07:57=20 An: spr...@li...=20 Cc:=20 Betreff: [Springframework-developer] Optional dependencies =09 =09 Guys, =09 I've just been discussing our forthcoming Struts integration with Yann = and Paul. =09 This raises a problem that's likely to recur. This will probably = involve adding a small number of classes that are Struts-dependent. But not all developers might be interested in them. =09 In the following, read "Struts" to mean "any third party product some classes will depend on but which aren't of interest to everyone". =09 How can we prevent our whole source tree being Struts-dependent and = prevent developers uninterested in Struts from having to download the relevant = Jars? * Make it a separate CVS module? But this will lead to a profusion of = CVS modules. Harder to build etc. * Put it in the main module and change the Ant build script to compile = the necessary classes and run the the relevant tests only if it finds = Struts on the classpath? This could eventually make the build script very long = and complicated. * Better ideas I haven't thought off?? How do other projects handle = this? =09 From a distribution point of view, many users won't want the Struts = classes either. We could make them a sep download. Or we could just include = them in one of the main Jars, and they wouldn't do any harm unless they were = used without Struts. =09 From a documentation view, we'll also need a dependencies table, = showing what depends on what. =09 Regards, Rod =09 ____________________________________________________ Rod Johnson J2EE Architect and Author +44 7973 409 132 =09 Author of "Expert One-on-One J2EE Design and Development" (Wrox Press, October 2002). http://www.amazon.com/exec/obidos/tg/detail/-/1861007841/ =09 http://www.wrox.com/books/1861007841.htm =09 http://www.wrox.com/dynamic/books/find.aspx?author=3DRod+Johnson =09 =09 =09 =09 ------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer =09 |
|
From: <jue...@we...> - 2003-02-18 15:44:12
|
That xxx "reply to" address... ;-) -----Urspr=FCngliche Nachricht----- Von: j=FCrgen h=F6ller [werk3AT]=20 Gesendet: Montag, 17. Februar 2003 08:44 An: 'Rod Johnson' Betreff: Re: [Springframework-developer] build.xml: VOTE Fine! > -----Urspr=FCngliche Nachricht----- > Von: Rod Johnson [mailto:rod...@in...] > Gesendet: Sonntag, 16. Februar 2003 22:45 > An: spr...@li... > Betreff: Fw: [Springframework-developer] build.xml: VOTE >=20 >=20 > Oops, the "reply to" address got me again... >=20 >=20 > Sounds like a good idea to me. Can we vote on it? >=20 > Rod > > > > ----- Original Message ----- > > From: "Kopylenko, Dmitry" <dko...@su...> > > To: "'spring-dev-list'" > > <spr...@li...> > > Sent: Friday, February 14, 2003 8:52 PM > > Subject: [Springframework-developer] build.xml > > > > > > > Just a thought. Why not move all the property declarations out of > > build.xml > > > into a property file. It's a best practice and makes a build file > cleaner. > > > > > > Just my 2c. > > > > > > Dmitriy. > > > > > > > > > ------------------------------------------------------- > > > This SF.NET email is sponsored by: FREE SSL Guide from > Thawte are > > > you planning your Web Server Security? Click here to get a FREE > > > Thawte SSL guide and find the answers to all your SSL security=20 > > > issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > > > _______________________________________________ > > > Springframework-developer mailing list=20 > > > Spr...@li... > > >=20 > https://lists.sourceforge.net/lists/listinfo/springframework-d evelop > > er > ------------------------------------------------------- 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 |
|
From: Tim M. <mu...@on...> - 2003-02-17 22:22:39
|
I've always felt it was most effective to only put properties that were likely to be changed for an individual's local environment. So something like the location of JBoss or JDBC information. Stuff like the location of the build directory probably won't change much and just clutters up the properties file. If you have one and only put things that are likely to change, it is much more obvious to a new user where to make mods. --Tim |
|
From: Kopylenko, D. <dko...@ac...> - 2003-02-17 18:03:42
|
Yes, I will do that as soon I get a chance. Right now I am stuck here in Philadelphia with my girlfriend (I live in NJ) due to the big snow storm... :-) Will be waiting until the conditions improve :-) Later. Dmitriy. -----Original Message----- From: Rod Johnson To: Kopylenko, Dmitry; 'spring-dev-list' Sent: 2/17/2003 4:12 AM Subject: Re: [Springframework-developer] build.xml Dmitriy, Yes, this seems to be worth doing. Would you like to send me a modified build.xml and the new properties file so that I can test it and check it in? Please update to build.xml 1.3 as the basis for your new version--I made some changes last night. Regards, Rod ----- Original Message ----- From: "Kopylenko, Dmitry" <dko...@su...> To: "'spring-dev-list'" <spr...@li...> Sent: Friday, February 14, 2003 8:52 PM Subject: [Springframework-developer] build.xml > Just a thought. Why not move all the property declarations out of build.xml > into a property file. It's a best practice and makes a build file cleaner. > > Just my 2c. > > Dmitriy. > > > ------------------------------------------------------- > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: William G. T. Jr. <wg...@rc...> - 2003-02-17 13:07:07
|
Many projects have the same problem. Ant for instance has the
optional.jar. Here is how I solved this problem at the Japple project.
There are two issues:
*Building from Source
*Binary Distribution
In both cases, folks wishing to use the optional packages are
responsible for getting the dependent 3rd party packages.
* Building from Source
1) "Optional" functionality is kept is seperate modules under the root
of the project tree.
/spring/src - core spring code
/spring/optional/struts-connector/src
/spring/optional/bill's_cool_dom_view_constructor/src
...
2) The root build.xml simple calls down into the optional modules to
build them. The optional modules have their own build.xml files which
can check for 3rd party libs, etc.
/spring/build.xml
<ant dir="/optional/struts-connector" target="build"/>
/spring/optional/struts-connector/build.xml
* Binary Distribution
I prefer to Keep It Simple and have a single binary distribution with
all optional packages included. However, it is the users responsiblity
to get 3rd party libs for optional components they wish to use.
1) package optional packages in a seperate jar(s) for inclusion in a
simple bin dist
2) include only libs required to run core framework
later.
Bill
Rod Johnson wrote:
> Guys,
>
> I've just been discussing our forthcoming Struts integration with Yann and
> Paul.
>
> This raises a problem that's likely to recur. This will probably involve
> adding a small number of classes that are Struts-dependent. But not all
> developers might be interested in them.
>
> In the following, read "Struts" to mean "any third party product some
> classes will depend on but which aren't of interest to everyone".
>
> How can we prevent our whole source tree being Struts-dependent and prevent
> developers uninterested in Struts from having to download the relevant Jars?
> * Make it a separate CVS module? But this will lead to a profusion of CVS
> modules. Harder to build etc.
> * Put it in the main module and change the Ant build script to compile the
> necessary classes and run the the relevant tests only if it finds Struts on
> the classpath? This could eventually make the build script very long and
> complicated.
> * Better ideas I haven't thought off?? How do other projects handle this?
>
> From a distribution point of view, many users won't want the Struts classes
> either. We could make them a sep download. Or we could just include them in
> one of the main Jars, and they wouldn't do any harm unless they were used
> without Struts.
>
> From a documentation view, we'll also need a dependencies table, showing
> what depends on what.
>
> Regards,
> Rod
>
> ____________________________________________________
> Rod Johnson
> J2EE Architect and Author
> +44 7973 409 132
>
> Author of "Expert One-on-One J2EE Design and Development"
> (Wrox Press, October 2002).
> http://www.amazon.com/exec/obidos/tg/detail/-/1861007841/
>
> http://www.wrox.com/books/1861007841.htm
>
> http://www.wrox.com/dynamic/books/find.aspx?author=Rod+Johnson
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
|
|
From: Rod J. <rod...@in...> - 2003-02-17 09:18:50
|
Dmitriy, Yes, this seems to be worth doing. Would you like to send me a modified build.xml and the new properties file so that I can test it and check it in? Please update to build.xml 1.3 as the basis for your new version--I made some changes last night. Regards, Rod ----- Original Message ----- From: "Kopylenko, Dmitry" <dko...@su...> To: "'spring-dev-list'" <spr...@li...> Sent: Friday, February 14, 2003 8:52 PM Subject: [Springframework-developer] build.xml > Just a thought. Why not move all the property declarations out of build.xml > into a property file. It's a best practice and makes a build file cleaner. > > Just my 2c. > > Dmitriy. > > > ------------------------------------------------------- > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Trevor C. <tc...@in...> - 2003-02-17 03:32:28
|
Properties is a best practice. +1 Trevor D. Cook -----Original Message----- From: Rod Johnson [mailto:rod...@in...] Sent: February 16, 2003 4:45 PM To: spr...@li... Subject: Fw: [Springframework-developer] build.xml: VOTE Oops, the "reply to" address got me again... Sounds like a good idea to me. Can we vote on it? Rod > > ----- Original Message ----- > From: "Kopylenko, Dmitry" <dko...@su...> > To: "'spring-dev-list'" <spr...@li...> > Sent: Friday, February 14, 2003 8:52 PM > Subject: [Springframework-developer] build.xml > > > > Just a thought. Why not move all the property declarations out of > build.xml > > into a property file. It's a best practice and makes a build file cleaner. > > > > Just my 2c. > > > > Dmitriy. > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > > are you planning your Web Server Security? Click here to get a FREE > > Thawte SSL guide and find the answers to all your SSL security issues. > > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > ------------------------------------------------------- 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 --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03 |
|
From: William G. T. Jr. <wg...@rc...> - 2003-02-17 02:10:06
|
A build.properties file is used in many of the open source Java projects I am familiar with, it seems to work well. +1 for me. Bill Chris Axe wrote: > OK with me > --- Rod Johnson <rod...@in...> wrote: > >>Oops, the "reply to" address got me again... >> >> >> Sounds like a good idea to me. Can we vote on >> >>Rod >> >>>----- Original Message ----- >>>From: "Kopylenko, Dmitry" >> >><dko...@su...> >> >>>To: "'spring-dev-list'" >> >><spr...@li...> >> >>>Sent: Friday, February 14, 2003 8:52 PM >>>Subject: [Springframework-developer] build.xml >>> >>> >>> >>>>Just a thought. Why not move all the property >>> >>declarations out of >> >>>build.xml >>> >>>>into a property file. It's a best practice and >>> >>makes a build file >>cleaner. >> >>>>Just my 2c. >>>> >>>>Dmitriy. >>>> >>>> |
|
From: Chris A. <ca...@ya...> - 2003-02-16 23:36:57
|
OK with me --- Rod Johnson <rod...@in...> wrote: > Oops, the "reply to" address got me again... > > > Sounds like a good idea to me. Can we vote on it? > > Rod > > > > ----- Original Message ----- > > From: "Kopylenko, Dmitry" > <dko...@su...> > > To: "'spring-dev-list'" > <spr...@li...> > > Sent: Friday, February 14, 2003 8:52 PM > > Subject: [Springframework-developer] build.xml > > > > > > > Just a thought. Why not move all the property > declarations out of > > build.xml > > > into a property file. It's a best practice and > makes a build file > cleaner. > > > > > > Just my 2c. > > > > > > Dmitriy. > > > > > > > > > > ------------------------------------------------------- > > > This SF.NET email is sponsored by: FREE SSL > Guide from Thawte > > > are you planning your Web Server Security? Click > here to get a FREE > > > Thawte SSL guide and find the answers to all > your SSL security issues. > > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > > > _______________________________________________ > > > Springframework-developer mailing list > > > Spr...@li... > > > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > > > ------------------------------------------------------- > 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 __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com |
|
From: Rod J. <rod...@in...> - 2003-02-16 21:44:52
|
Oops, the "reply to" address got me again... Sounds like a good idea to me. Can we vote on it? Rod > > ----- Original Message ----- > From: "Kopylenko, Dmitry" <dko...@su...> > To: "'spring-dev-list'" <spr...@li...> > Sent: Friday, February 14, 2003 8:52 PM > Subject: [Springframework-developer] build.xml > > > > Just a thought. Why not move all the property declarations out of > build.xml > > into a property file. It's a best practice and makes a build file cleaner. > > > > Just my 2c. > > > > Dmitriy. > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > > are you planning your Web Server Security? Click here to get a FREE > > Thawte SSL guide and find the answers to all your SSL security issues. > > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Tony F. <ton...@ya...> - 2003-02-14 21:50:30
|
There are only 2 errors that occur when trying to compile all the framework code (including the test classes). ---------------------------------------------------------------------- In com.interface21.web.util.ServletRequestParameterPropertyValuesTestSuite.java line 7 reads "import junit.ui.TestRunner". There is no such class, so you get a compilation error. (Actually Rod, when you refer to the TestRunner later in the java file you fully qualify it.) So get rid of line 7 and compilation is fine. ---------------------------------------------------------------------- In com.interface21.jta.TxInterceptorTestSuite.java get these errors: "TxInterceptorTestSuite.java": Error #: 300 : class SingleConnectionTransactionInterceptor not found in class com.interface21.jta.TxInterceptorTestSuite at line 36, column 12 "TxInterceptorTestSuite.java": Error #: 300 : class SingleConnectionTransactionInterceptor not found in class com.interface21.jta.TxInterceptorTestSuite at line 73, column 12 ---------------------------------------------------------------------- |
|
From: Kopylenko, D. <dko...@ac...> - 2003-02-14 20:52:24
|
Just a thought. Why not move all the property declarations out of build.xml into a property file. It's a best practice and makes a build file cleaner. Just my 2c. Dmitriy. |
|
From: Srikanth S <sri...@co...> - 2003-02-14 16:52:25
|
Hi Rod I don't think it would be a good idea to make developers depend on something like Struts. A good example would be Jakarta commons logging which allows logging with different logging packages such as log4j, jdk1.4 etc. without depending on unused packages. I do not think Struts needs any special treatment. As argued in your in book Struts is too JSP centric which is by far most ugly presentation mechanism. Going forward XML based transformations would be the most popular way for presentation and we should do what ever it takes to make that more popular. Srikanth S Rod Johnson wrote: >Guys, > >I've just been discussing our forthcoming Struts integration with Yann and >Paul. > >This raises a problem that's likely to recur. This will probably involve >adding a small number of classes that are Struts-dependent. But not all >developers might be interested in them. > >In the following, read "Struts" to mean "any third party product some >classes will depend on but which aren't of interest to everyone". > >How can we prevent our whole source tree being Struts-dependent and prevent >developers uninterested in Struts from having to download the relevant Jars? >* Make it a separate CVS module? But this will lead to a profusion of CVS >modules. Harder to build etc. >* Put it in the main module and change the Ant build script to compile the >necessary classes and run the the relevant tests only if it finds Struts on >the classpath? This could eventually make the build script very long and >complicated. >* Better ideas I haven't thought off?? How do other projects handle this? > >>From a distribution point of view, many users won't want the Struts classes >either. We could make them a sep download. Or we could just include them in >one of the main Jars, and they wouldn't do any harm unless they were used >without Struts. > >>From a documentation view, we'll also need a dependencies table, showing >what depends on what. > >Regards, >Rod > >____________________________________________________ >Rod Johnson >J2EE Architect and Author >+44 7973 409 132 > >Author of "Expert One-on-One J2EE Design and Development" >(Wrox Press, October 2002). >http://www.amazon.com/exec/obidos/tg/detail/-/1861007841/ > >http://www.wrox.com/books/1861007841.htm > >http://www.wrox.com/dynamic/books/find.aspx?author=Rod+Johnson > > > > >------------------------------------------------------- >This SF.NET email is sponsored by: FREE SSL Guide from Thawte >are you planning your Web Server Security? Click here to get a FREE >Thawte SSL guide and find the answers to all your SSL security issues. >http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > |
|
From: Trevor C. <tc...@in...> - 2003-02-14 15:59:24
|
I don't think we should worry about doing anything special and make struts (or whatever other product we are supporting, webwork or logkit for example) a required download for DEVELOPERS. We don't want these required to use the framework, but developers are different. As an example, look at jakarta commons logging. It is to allow logging without dependancy on unused logging packages, but developers (or those wishing to compile from source) ARE required to have those packages, even if they are working on areas that don't require them. I don't know of any projects that allow source compiliation without all required packages. Trevor D. Cook -----Original Message----- From: Rod Johnson [mailto:rod...@in...] Sent: February 14, 2003 1:58 AM To: spr...@li... Subject: [Springframework-developer] Optional dependencies Guys, I've just been discussing our forthcoming Struts integration with Yann and Paul. This raises a problem that's likely to recur. This will probably involve adding a small number of classes that are Struts-dependent. But not all developers might be interested in them. In the following, read "Struts" to mean "any third party product some classes will depend on but which aren't of interest to everyone". How can we prevent our whole source tree being Struts-dependent and prevent developers uninterested in Struts from having to download the relevant Jars? * Make it a separate CVS module? But this will lead to a profusion of CVS modules. Harder to build etc. * Put it in the main module and change the Ant build script to compile the necessary classes and run the the relevant tests only if it finds Struts on the classpath? This could eventually make the build script very long and complicated. * Better ideas I haven't thought off?? How do other projects handle this? From a distribution point of view, many users won't want the Struts classes either. We could make them a sep download. Or we could just include them in one of the main Jars, and they wouldn't do any harm unless they were used without Struts. From a documentation view, we'll also need a dependencies table, showing what depends on what. Regards, Rod ____________________________________________________ Rod Johnson J2EE Architect and Author +44 7973 409 132 Author of "Expert One-on-One J2EE Design and Development" (Wrox Press, October 2002). http://www.amazon.com/exec/obidos/tg/detail/-/1861007841/ http://www.wrox.com/books/1861007841.htm http://www.wrox.com/dynamic/books/find.aspx?author=Rod+Johnson ------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03 |
1239 messages has been excluded from this view by a project administrator.
