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
(5) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2026 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: JP P. <jp....@ti...> - 2003-08-18 22:23:08
|
Juergen and all, After my request, the BeanWrapper can pickup arrayed Strings from the request. I talk mainly about checkboxes and multiselects. But until now, the command should have a String array to receive the information. I have made a little change in BeanWrapperImpl to be able to have custom property editors for this case. - If the String Array was not assignable to the command, an exception was thrown. - Now, it is first transformed as comma delimited String. So a custom property editor can be written against the comma delimited String for handling any kind of collection. The only case I see that cannot be properly handled is the (rare) case of Strings containing commas. Jean-Pierre |
|
From: JP P. <jp....@ti...> - 2003-08-18 22:08:44
|
FYI, the Countries demo is now added in the 1.0 branch. Jean-Pierre |
|
From: <jue...@we...> - 2003-08-18 22:06:18
|
SGkgQ29saW4sDQogDQpJJ20gZGVsaWdodGVkIHRvIGhlYXIgdGhhdCBzb21lb25lIGlzIHVzaW5n IGEgU3ByaW5nL1RhcGVzdHJ5IGNvbWJvISBJZiB5b3UgYXJlIHdpbGxpbmcgdG8gZG9jdW1lbnQg dGhlIHNldHVwIGZvciB1c2luZyBUYXBlc3RyeSBhcyB3ZWIgZnJhbWV3b3JrIHdpdGggU3ByaW5n LCBwbGVhc2UgZG8gc28hDQogDQpXZSBjb3VsZCBhbHNvIGFkZCByZXNwZWN0aXZlIG5vdGVzIGZv ciBTdHJ1dHMsIGFzIGl0IGlzIHBhcnRpY3VsYXJseSBlYXN5IHRvIGNvbWJpbmUgdGhhdCB3aXRo IFNwcmluZzogU2ltcGx5IGdldCBhIHJlZmVyZW5jZSB0byB0aGUgc2VydmxldCBjb250ZXh0IHZp YSBnZXRTZXJ2bGV0KCkuZ2V0U2VydmxldENvbnRleHQoKSBmcm9tIHdpdGhpbiBhIFN0cnV0cyBh Y3Rpb24sIGFuZCBmZXRjaCB0aGUgcm9vdCB3ZWIgYXBwbGljYXRpb24gY29udGV4dCB2aWEgV2Vi QXBwbGljYXRpb25Db250ZXh0VXRpbHMuIFdlIGNvdWxkIGV2ZW4gb2ZmZXIgYSBzaW1wbGUgQWN0 aW9uIGJhc2UgY2xhc3MgZm9yIHRoYXQsIGVzcGVjaWFsbHkgbm93IHRoYXQgd2Ugd2lsbCBoYXZl IGEgc3RydXRzLmphciBpbiB0aGUgbGliIGRpcmVjdG9yeSBhbnl3YXkuDQogDQpSZWdhcmRpbmcg YSBidWlsZCB3aXRoIGV2ZXJ5dGhpbmcgYnV0IHRoZSB3ZWIgTVZDIGZyYW1ld29yazogQXJlIHlv dSBjb25jZXJuZWQgcmVnYXJkaW5nIHRoZSBzaXplIG9mIHRoZSBqYXI/IHNwcmluZy1mdWxsIGlz IGN1cnJlbnRseSBqdXN0IH41NTAgS0IsIGFuZCBUaWxlcyB3aWxsIG9ubHkgbWFrZSBpdCBncm93 IGEgZmV3IEtCIGp1c3QgbGlrZSBWZWxvY2l0eSwgYXMgbW9zdCBvZiB0aGUgc3R1ZmYgaXMgaW4g dGhpcmQtcGFydHkgbGlicmFyaWVzIHRoYXQgYXJlbid0IGluY2x1ZGVkIGFueXdheS4gSSBkb24n dCBzZWUgYW55IGRyYXdiYWNrIGlmIHlvdSBzdGlsbCB1c2UgdGhlIHNwcmluZy1mdWxsIGphciBi dXQganVzdCBpbmNsdWRlIHRoZSB0aGlyZC1wYXJ0eSBsaWJyYXJpZXMgdGhhdCB5b3UncmUgYWN0 dWFsbHkgdXNpbmcuIFRoZSBhZGRpdGlvbmFsIGNsYXNzZXMgaW4gc3ByaW5nLWZ1bGwgZG9uJ3Qg aHVydCBiZXNpZGVzIHRoZSBzaXplLiBPciBkbyBJIG1pc3Mgc29tZXRoaW5nIGhlcmU/DQogDQpK dWVyZ2VuDQogDQogDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZv bjogQ29saW4gU2FtcGFsZWFudSBbbWFpbHRvOmNvbGlubWwxQGV4aXMuY29tXSANCglHZXNlbmRl dDogTW8gMTguMDguMjAwMyAyMzo1NCANCglBbjogasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXSAN CglDYzogYWxlZkBqdGVhbS5ubDsgc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3Vy Y2Vmb3JnZS5uZXQgDQoJQmV0cmVmZjogUmU6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBB ZGRpbmcgVGlsZXMgdG8gQ1ZTLi4uDQoJDQoJDQoNCglDYW4gSSBzdWdnZXN0IHRoYXQgdGhlIGJ1 aWxkIHByb2R1Y2UgYW5vdGhlciB2YXJpYW50IG9mIFNwcmluZyB3aGljaA0KCWRvZXNuJ3QgaW5j bHVkZSB0aGUgU3ByaW5nIG12YyBzdHVmZiBvciBjb2RlIGxpa2UgdGhpcyBUaWxlcyBzdXBwb3J0 LA0KCWJ1dCBkb2VzIGluY2x1ZGV0aGUgbm9uIHdlYi1mcmFtZXdvcmsgc3BlY2lmaWMgYnV0IHdl YiByZWxhdGVkIGNsYXNzZXM/DQoJSSBhbSB0YWxraW5nIGFib3V0IHRoaW5ncyBsaWtlIFdlYkFw cGxpY2F0aW9uQ29udGV4dFV0aWxzLiAgSSBhbQ0KCShoYXBwaWx5KSB1c2luZyBTcHJpbmcgd2l0 aCB0aGUgQXBhY2hlIFRhcGVzdHJ5IGZyYW1ld29yay4NCglXZWJBcHBsaWNhdGlvbkNvbnRleHQs IFdlYkFwcGxpY2F0aW9uQ29udGV4dFV0aWxzLCBhbmQgb3RoZXIgZ2VuZXJpYw0KCWNsYXNzZXMg d2hpY2ggbWFrZSB0aGUgc3ByaW5nIGNvbnRhaW5lciBtb3JlIHVzYWJsZSBpbiBhIHNlcnZsZXQN CgllbnZpcm9ubWVudCBhcmUgdXNlZnVsIHRvIG1lLCBidXQgSSBkb24ndCB3YW50IHRvIGJyaW5n IGluIG90aGVyIGJhZ2dhZ2UNCglsaWtlIHRoZSBTcHJpbmcgd2ViIE1WQyBzdHVmZiwgb3Igbm93 IHRoZSBUaWxlcyBzdXBwb3J0Lg0KCQ0KCUFsc28sIEkgZmluZCBUYXBlc3RyeSB0byBiZSBhIHZl cnkgZ29vZCB3ZWIgZnJhbWV3b3JrLCB3aGljaCB3b3JrcyBhdCBhDQoJbXVjaCBoaWdoZXIgbGV2 ZWwgKGNvbXBvbmVudC1iYXNlZCkgdGhhbiBtb3N0IHdlYiB1aSBmcmFtZXdvcmtzLiBJcw0KCXRo ZXJlIGludGVyZXN0IGluIGFkZGluZyBhIGRvY3VtZW50IGludG8gU3ByaW5nIGRlc2NyaWJpbmcg aG93IHRvIGJlc3QNCgl1c2UgU3ByaW5nIHdpdGggVGFwZXN0cnk/ICBUaGUgY2xlYW5lc3QgbWVj aG5pc20gKGFsbG93aW5nIHlvdSB0byBhY2Nlc3MNCglTcHJpbmcgY29udGV4dCBwcm9wZXJ0aWVz IGRlY2xhcmF0aXZlbHkgZnJvbSBUYXBlc3RyeSBwYWdlcykgaXMgbm90DQoJbmVjZXNzYXJpbGx5 IHRoYXQgaW50dWl0aXZlIHRvIGZpZ3VyZSBvdXQsIHNvIEkgdGhpbmsgbXkNCglleHBlcmltZW50 YXRpb24vd29yayB3b3VsZCBiZSB1c2VmdWwgdG8gb3RoZXIgcGVvcGxlLg0KCQ0KCVJlZ2FyZHMs DQoJQ29saW4NCgkNCgkNCglqw7xyZ2VuIGjDtmxsZXIgW3dlcmszQVRdIHdyb3RlOg0KCQ0KCT5I aSBBcmVmLA0KCT4NCgk+VGhlbiBwbGVhc2UgZ28gYWhlYWQhIDotKQ0KCT4NCgk+VGhlcmUncyBq dXN0IG9uZSBpc3N1ZSB0aGF0IEknZCBsaWtlIHRvIHJlc29sdmU6IEhvdyBkbyB5b3Ugc2V0IHVw IFRpbGVzIG9uIHN0YXJ0dXA/IFlvdSd2ZSB1c2VkIGEgVGlsZXNWaWV3UmVzb2x2ZXIgYmVmb3Jl IHdoaWNoIHNob3VsZCBub3QgYmUgbmVjZXNzYXJ5LiBXZSd2ZSBkaXNjdXNzZWQgYSBUaWxlc0Nv bmZpZ3VyZXIsIGFuYWxvZ291cyB0byB0aGUgZXhpc3RpbmcgVmVsb2NpdHlDb25maWd1cmVyLiBX aGF0IHN0cmF0ZWd5IGRpZCB5b3UgY2hvb3NlIGluIHRoZSBlbmQ/DQoJPg0KCT5SZWdhcmRpbmcg dGhlIGxpYnJhcmllczogUGxlYXNlIG9ubHkgaW5jbHVkZSB0aGUgY29tcGlsZS10aW1lIGRlcGVu ZGVuY2llcywgcmVzcGVjdGl2ZWx5IHRoZSBvbmVzIG5lZWRlZCBmb3IgZXhlY3V0aW5nIHRoZSB0 ZXN0IHN1aXRlLiBXZSBkaWQgdGhlIHNhbWUgZm9yIEhpYmVybmF0ZSB0byBhdm9pZCB0b28gbXVj aCBibG9hdC4gQWxsIG9mIHRoZSBsaWJyYXJpZXMgc2hvdWxkIGdvIGluIGxpYi90aWxlcywgYW5h bG9nb3VzIHRvIHRoZSBleGlzdGluZyBsaWIvaGliZXJuYXRlLg0KCT4NCgk+RG9uJ3QgZm9yZ2V0 IHRvIHVzZSB0aGUgbmV3ICJzcHJpbmciIG1vZHVsZSB3aXRoIHRoZSBvcmcuc3ByaW5nZnJhbWV3 b3JrIHBhY2thZ2VzLi4uIDstKQ0KCT4NCgk+SnVlcmdlbg0KCT4NCgk+DQoJPg0KCT4gICAgICAg LS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KCT4gICAgICAgVm9uOiBBbGVmIEFy ZW5kc2VuIChKVGVhbSkgW21haWx0bzphbGVmQGp0ZWFtLm5sXQ0KCT4gICAgICAgR2VzZW5kZXQ6 IE1vIDE4LjA4LjIwMDMgMjI6MTMNCgk+ICAgICAgIEFuOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxv cGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KCT4gICAgICAgQ2M6DQoJPiAgICAgICBCZXRyZWZm OiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gQWRkaW5nIFRpbGVzIHRvIENWUy4uLg0KCT4g ICAgICANCgk+ICAgICAgDQoJPg0KCT4gICAgICAgSGkgYWxsLA0KCT4NCgk+ICAgICAgIEknbSBi YXNpY2FsbHkgcmVhZHkgdG8gYWRkIHRoZSBUaWxlcyBmdW5jdGlvbmFsaXR5IHRvIHRoZSBDVlMu IEl0J3MgdGVzdGVkIGFuZCB3b3JrcyBmaW5lLg0KCT4NCgk+ICAgICAgIFdlIG5lZWQgdG8gZGVj aWRlIG5vdyB3aGljaCBkZXBlbmRlbmNpZXMgdG8gaW5jbHVkZS4gU3RydXRzIGlzIGRlcGVuZGFu dCBvbiB0aGUgZm9sbG93aW5nIGxpYnJhcmllcy4gVGhlIG9uZXMgdGhhdCBoYXZlIGFuICogd2l0 aCB0aGVtIGFyZSB0aGUgb25lcyB0aGF0IGFyZSBib3RoIGNvbXBpbGUtdGltZSBhbmQgcnVudGlt ZSwgbGlicmFyaWVzIHdpdGhvdXQgKiBhcmUgb25seSBydW50aW1lIGRlcGVuZGVuY2llczoNCgk+ DQoJPiAgICAgICAqY29tbW9ucy1iZWFudXRpbHMNCgk+ICAgICAgICpjb21tb25zLWRpZ2VzdGVy DQoJPiAgICAgICAqY29tbW9ucy1sb2dnaW5nICh3ZSBhbHJlYWR5IGhhdmUgdGhhdCBvbmUpDQoJ PiAgICAgICAqc3RydXRzIChvZiBjb3Vyc2UpDQoJPiAgICAgICBjb21tb25zLWNvbGxlY3Rpb25z DQoJPiAgICAgICBjb21tb25zLWxhbmcNCgk+ICAgICAgIGNvbW1vbnMtdmFsaWRhdG9yDQoJPiAg ICAgICBjb21tb25zLWZpbGV1cGxvYWQNCgk+ICAgICAgIGpha2FydGEtb3JvDQoJPg0KCT4gICAg ICAgSXQncyBxdWl0ZSBhIGxpc3QsIGJ1dCBmcm9tIHRoZSBwcmV2aW91cyBtYWlscyBJIHNhdyBu b2JvZHkgcmVhbGx5IG9iamVjdGVkIHRvIGluY2x1ZGluZyB0aGVtLiBTbyBqdXN0IGFkZCB0aGVt Pz8/DQoJPg0KCT4gICAgICAgUmVnYXJkcywNCgk+DQoJPiAgICAgICBBbGVmDQoJPg0KCT4gICAg ICAgPT0NCgk+ICAgICAgIEpUZWFtIEIuVi4NCgk+ICAgICAgIERvbmtlciBDdXJ0aXVzc3RyYWF0 IDctNDEyDQoJPiAgICAgICAxMDUxIEpMICBBbXN0ZXJkYW0NCgk+ICAgICAgIFQ6ICszMSAyMCA0 ODYgMjAgMzYNCgk+ICAgICAgIE06ICszMSA2IDI0IDExIDE5OTYNCgk+ICAgICAgIEY6ICszMSA4 NCA4MzcgMDAgMDANCgk+ICAgICAgIEU6IGFsZWZAanRlYW0ubmwNCgk+ICAgICAgIFc6IHd3dy5q dGVhbS5ubCA8ZmlsZTovL3d3dy5qdGVhbS5ubD4gDQoJPg0KCT5OGD9IU14/6ZqKWyk/eyg/P1s/ Wj96Pz9u6KW0BD80RD/XrD93JT/Ypz82P2kXPz8/bBE/Jj8/P3g/Kz8/bGp3RT8/Pz8/P2o/P3p6 MA4/Jz8/Pz8/WsmpP3p7Xj8/MD92P1wTPz8/Yj8/StudPz9EThttPz/asj/etT9icks/Pz8mPw0K CT4/P8a0P100P03avT/dij8/Pz9aPz/et04/P00/Pz81Sj8/Bz9qZz8/Px16Pz8/Pz8/eCU/P1I/ Pz8/P9qZPyg/R14/P2g/Pz8/bD8/P3E/Pwc/ej9tPz8/P1g/Pz8oPz8efj8/enc/P1g/Pz8/P2I/ Pz8/Pz8HP2pnPz8/HXo/Pw0KCT4NCgkNCgkNCgkNCg0K |
|
From: <jue...@we...> - 2003-08-18 21:56:19
|
QWxlZiwNCiANClBsZWFzZSBkbyBhbiBpbml0aWFsIGNoZWNraW4sIEknbSBrZWVuIG9uIHJldmll d2luZyBpdCA6LSkNCiANCkkgZ3Vlc3MgYW4gb3JnLnNwcmluZ2ZyYW1ld29yay53ZWIuc2Vydmxl dC52aWV3LnRpbGVzIHBhY2thZ2UgaXMgdGhlIGJlc3QgcGxhY2UgZm9yIHRoZSBjb2RlLCBsaWIv dGlsZXMgZm9yIHRoZSB0aGlyZC1wYXJ0eSBqYXJzLCBhbmQgZG9jcy90aWxlcyBmb3IgZG9jdW1l bnRhdGlvbiBhbmQgZXhhbXBsZXMuDQogDQpKdWVyZ2VuDQogDQogDQoNCgktLS0tLVVyc3Byw7xu Z2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjogQWxlZiBBcmVuZHNlbiAoSlRlYW0pIFttYWls dG86YWxlZkBqdGVhbS5ubF0gDQoJR2VzZW5kZXQ6IE1vIDE4LjA4LjIwMDMgMjM6MzYgDQoJQW46 IGrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF07IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlz dHMuc291cmNlZm9yZ2UubmV0IA0KCUNjOiANCglCZXRyZWZmOiBSRTogW1NwcmluZ2ZyYW1ld29y ay1kZXZlbG9wZXJdIEFkZGluZyBUaWxlcyB0byBDVlMuLi4NCgkNCgkNCg0KCUkndmUgdGFrZW4g dGhlIENvbmZpZ3VyZXIgYXBwcm9hY2gsIGJ1dCBtaWdodCB3YW50IHRvIGFkZCB0aGUgUmVzb2x2 ZXIgbGF0ZXIgb24uLi4NCgkNCglXaHk/DQoJDQoJVGlsZXMgaW5jbHVkZXMgYSBMb2NhbGUgc3Bl Y2lmaWMgRGVmaW5pdGlvbnNGYWN0b3J5IChJMThGYWN0b3J5U2V0KSB0aGF0IGxvYWRzIGRlZmlu aXRpb24gZmlsZXMgZm9yIGRpZmZlcmVudCBsb2NhbGVzIGp1c3QgYXMgdGhlIFJlc291cmNlQnVu ZGxlVmlld1Jlc29sdmVyIGRvZXMuIEhvd2V2ZXIsIGNyZWF0aW5nIGJvdGggcHJvcGVydGllcy1m aWxlcyBmb3IgdGhlIFJlc291cmNlQnVuZGxlVmlld1Jlc29sdmVyIGFuZCBkZWZpbml0aW9uIGZp bGVzIGZvciB0aGUgVGlsZXMgZGVmaW5pdGlvbnMgKG9uZSBmb3IgZWFjaCBsYW5ndWFnZSkgc2Vl bXMgc2lsbHkuLi4gV2hlbiB1c2luZyB0aGUgSW50ZXJuYWxSZXNvdXJjZVZpZXdSZXNvbHZlciBs b2NhbGl6YXRpb24gaXNuJ3QgKGFzIHRoZSBkb2N1bWVudGF0aW9uIGFsc28gc2F5cykgcG9zc2li bGUuLi4NCgkNCglJIGRpZG4ndCBydW4gaW50byBhbiBhcHAgbmVlZGluZyBkaWZmZXJlbnQgZGVm aW5pdGlvbnMgcGVyIGxhbmd1YWdlLCBidXQgdGhpcyBtaWdodCBiZSBuZWNlc3NhcnkgZm9yIHNv bWUgcGVvcGxlLiBGcm8gbm93IHRoZSBDb25maWd1cmVyIHdpbGwgZG8hIQ0KCQ0KCUJ5IHRoZSB3 YXksIEkndmUgc2V0IHVwIGEgc21hbGwgZXhhbXBsZSBpbGx1c3RyYXRpbmcgdGhlIFRpbGVzIGJl aHZhaW9yIGFuZCBhIHNtYWxsIEhUTUwgZG9jdW1lbnQgd2hpY2ggY291bGQgYmUgcGxhY2VkIGlu IHRoZSBkb2NzIGRpcmVjdG9yeS4gU2hhbGwgSSBpbmNsdWRlIHRob3NlIGFzIHdlbGw/DQoJDQoJ QWxlZg0KCQ0KCS0tLS0tT29yc3Byb25rZWxpamsgYmVyaWNodC0tLS0tDQoJVmFuOiBzcHJpbmdm cmFtZXdvcmstZGV2ZWxvcGVyLWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCBbbWFpbHRvOnNw cmluZ2ZyYW1ld29yay1kZXZlbG9wZXItYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0XSBOYW1l bnMgasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXQ0KCVZlcnpvbmRlbjogTW9uZGF5LCBBdWd1c3Qg MTgsIDIwMDMgMTA6MzUgUE0NCglBYW46IGFsZWZAanRlYW0ubmw7IHNwcmluZ2ZyYW1ld29yay1k ZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJT25kZXJ3ZXJwOiBSZTogW1NwcmluZ2Zy YW1ld29yay1kZXZlbG9wZXJdIEFkZGluZyBUaWxlcyB0byBDVlMuLi4NCgkNCgkNCglIaSBBcmVm LA0KCQ0KCVRoZW4gcGxlYXNlIGdvIGFoZWFkISA6LSkNCgkNCglUaGVyZSdzIGp1c3Qgb25lIGlz c3VlIHRoYXQgSSdkIGxpa2UgdG8gcmVzb2x2ZTogSG93IGRvIHlvdSBzZXQgdXAgVGlsZXMgb24g c3RhcnR1cD8gWW91J3ZlIHVzZWQgYSBUaWxlc1ZpZXdSZXNvbHZlciBiZWZvcmUgd2hpY2ggc2hv dWxkIG5vdCBiZSBuZWNlc3NhcnkuIFdlJ3ZlIGRpc2N1c3NlZCBhIFRpbGVzQ29uZmlndXJlciwg YW5hbG9nb3VzIHRvIHRoZSBleGlzdGluZyBWZWxvY2l0eUNvbmZpZ3VyZXIuIFdoYXQgc3RyYXRl Z3kgZGlkIHlvdSBjaG9vc2UgaW4gdGhlIGVuZD8NCgkNCglSZWdhcmRpbmcgdGhlIGxpYnJhcmll czogUGxlYXNlIG9ubHkgaW5jbHVkZSB0aGUgY29tcGlsZS10aW1lIGRlcGVuZGVuY2llcywgcmVz cGVjdGl2ZWx5IHRoZSBvbmVzIG5lZWRlZCBmb3IgZXhlY3V0aW5nIHRoZSB0ZXN0IHN1aXRlLiBX ZSBkaWQgdGhlIHNhbWUgZm9yIEhpYmVybmF0ZSB0byBhdm9pZCB0b28gbXVjaCBibG9hdC4gQWxs IG9mIHRoZSBsaWJyYXJpZXMgc2hvdWxkIGdvIGluIGxpYi90aWxlcywgYW5hbG9nb3VzIHRvIHRo ZSBleGlzdGluZyBsaWIvaGliZXJuYXRlLg0KCQ0KCURvbid0IGZvcmdldCB0byB1c2UgdGhlIG5l dyAic3ByaW5nIiBtb2R1bGUgd2l0aCB0aGUgb3JnLnNwcmluZ2ZyYW1ld29yayBwYWNrYWdlcy4u LiA7LSkNCgkNCglKdWVyZ2VuDQoJDQoJDQoJDQoJICAgICAgICAtLS0tLVVyc3Byw7xuZ2xpY2hl IE5hY2hyaWNodC0tLS0tDQoJICAgICAgICBWb246IEFsZWYgQXJlbmRzZW4gKEpUZWFtKSBbbWFp bHRvOmFsZWZAanRlYW0ubmxdDQoJICAgICAgICBHZXNlbmRldDogTW8gMTguMDguMjAwMyAyMjox Mw0KCSAgICAgICAgQW46IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9y Z2UubmV0DQoJICAgICAgICBDYzoNCgkgICAgICAgIEJldHJlZmY6IFtTcHJpbmdmcmFtZXdvcmst ZGV2ZWxvcGVyXSBBZGRpbmcgVGlsZXMgdG8gQ1ZTLi4uDQoJICAgICAgIA0KCSAgICAgICANCgkN CgkgICAgICAgIEhpIGFsbCwNCgkNCgkgICAgICAgIEknbSBiYXNpY2FsbHkgcmVhZHkgdG8gYWRk IHRoZSBUaWxlcyBmdW5jdGlvbmFsaXR5IHRvIHRoZSBDVlMuIEl0J3MgdGVzdGVkIGFuZCB3b3Jr cyBmaW5lLg0KCQ0KCSAgICAgICAgV2UgbmVlZCB0byBkZWNpZGUgbm93IHdoaWNoIGRlcGVuZGVu Y2llcyB0byBpbmNsdWRlLiBTdHJ1dHMgaXMgZGVwZW5kYW50IG9uIHRoZSBmb2xsb3dpbmcgbGli cmFyaWVzLiBUaGUgb25lcyB0aGF0IGhhdmUgYW4gKiB3aXRoIHRoZW0gYXJlIHRoZSBvbmVzIHRo YXQgYXJlIGJvdGggY29tcGlsZS10aW1lIGFuZCBydW50aW1lLCBsaWJyYXJpZXMgd2l0aG91dCAq IGFyZSBvbmx5IHJ1bnRpbWUgZGVwZW5kZW5jaWVzOg0KCQ0KCSAgICAgICAgKmNvbW1vbnMtYmVh bnV0aWxzDQoJICAgICAgICAqY29tbW9ucy1kaWdlc3Rlcg0KCSAgICAgICAgKmNvbW1vbnMtbG9n Z2luZyAod2UgYWxyZWFkeSBoYXZlIHRoYXQgb25lKQ0KCSAgICAgICAgKnN0cnV0cyAob2YgY291 cnNlKQ0KCSAgICAgICAgY29tbW9ucy1jb2xsZWN0aW9ucw0KCSAgICAgICAgY29tbW9ucy1sYW5n DQoJICAgICAgICBjb21tb25zLXZhbGlkYXRvcg0KCSAgICAgICAgY29tbW9ucy1maWxldXBsb2Fk DQoJICAgICAgICBqYWthcnRhLW9ybw0KCQ0KCSAgICAgICAgSXQncyBxdWl0ZSBhIGxpc3QsIGJ1 dCBmcm9tIHRoZSBwcmV2aW91cyBtYWlscyBJIHNhdyBub2JvZHkgcmVhbGx5IG9iamVjdGVkIHRv IGluY2x1ZGluZyB0aGVtLiBTbyBqdXN0IGFkZCB0aGVtPz8/DQoJDQoJICAgICAgICBSZWdhcmRz LA0KCQ0KCSAgICAgICAgQWxlZg0KCQ0KCSAgICAgICAgPT0NCgkgICAgICAgIEpUZWFtIEIuVi4N CgkgICAgICAgIERvbmtlciBDdXJ0aXVzc3RyYWF0IDctNDEyDQoJICAgICAgICAxMDUxIEpMICBB bXN0ZXJkYW0NCgkgICAgICAgIFQ6ICszMSAyMCA0ODYgMjAgMzYNCgkgICAgICAgIE06ICszMSA2 IDI0IDExIDE5OTYNCgkgICAgICAgIEY6ICszMSA4NCA4MzcgMDAgMDANCgkgICAgICAgIEU6IGFs ZWZAanRlYW0ubmwNCgkgICAgICAgIFc6IHd3dy5qdGVhbS5ubCA8ZmlsZTovL3d3dy5qdGVhbS5u bD4gDQoJDQoJThhIU1vpiqJ7IFp6bgQ0ROi0iteKd9iANmkXEcqZeCBqd2p6eg7tuJbttozJqXp7 2op2XBNKIE4bIHJLDQoJIF1N073virdOTSBKIGpneiB4y6YgRyDLsnEgeiBtP1ggKB5+encgWCBi y50/ICBqZ+uwoh167b2W7bKXDQoJDQoJDQoNCg== |
|
From: Colin S. <col...@ex...> - 2003-08-18 21:54:09
|
Can I suggest that the build produce another variant of Spring which doesn't include the Spring mvc stuff or code like this Tiles support, but does includethe non web-framework specific but web related classes? I am talking about things like WebApplicationContextUtils. I am (happily) using Spring with the Apache Tapestry framework. WebApplicationContext, WebApplicationContextUtils, and other generic classes which make the spring container more usable in a servlet environment are useful to me, but I don't want to bring in other baggage like the Spring web MVC stuff, or now the Tiles support. Also, I find Tapestry to be a very good web framework, which works at a much higher level (component-based) than most web ui frameworks. Is there interest in adding a document into Spring describing how to best use Spring with Tapestry? The cleanest mechnism (allowing you to access Spring context properties declaratively from Tapestry pages) is not necessarilly that intuitive to figure out, so I think my experimentation/work would be useful to other people. Regards, Colin jürgen höller [werk3AT] wrote: >Hi Aref, > >Then please go ahead! :-) > >There's just one issue that I'd like to resolve: How do you set up Tiles on startup? You've used a TilesViewResolver before which should not be necessary. We've discussed a TilesConfigurer, analogous to the existing VelocityConfigurer. What strategy did you choose in the end? > >Regarding the libraries: Please only include the compile-time dependencies, respectively the ones needed for executing the test suite. We did the same for Hibernate to avoid too much bloat. All of the libraries should go in lib/tiles, analogous to the existing lib/hibernate. > >Don't forget to use the new "spring" module with the org.springframework packages... ;-) > >Juergen > > > > -----Ursprüngliche Nachricht----- > Von: Alef Arendsen (JTeam) [mailto:al...@jt...] > Gesendet: Mo 18.08.2003 22:13 > An: spr...@li... > Cc: > Betreff: [Springframework-developer] Adding Tiles to CVS... > > > > Hi all, > > I'm basically ready to add the Tiles functionality to the CVS. It's tested and works fine. > > We need to decide now which dependencies to include. Struts is dependant on the following libraries. The ones that have an * with them are the ones that are both compile-time and runtime, libraries without * are only runtime dependencies: > > *commons-beanutils > *commons-digester > *commons-logging (we already have that one) > *struts (of course) > commons-collections > commons-lang > commons-validator > commons-fileupload > jakarta-oro > > It's quite a list, but from the previous mails I saw nobody really objected to including them. So just add them??? > > Regards, > > Alef > > == > JTeam B.V. > Donker Curtiusstraat 7-412 > 1051 JL Amsterdam > T: +31 20 486 20 36 > M: +31 6 24 11 1996 > F: +31 84 837 00 00 > E: al...@jt... > W: www.jteam.nl <file://www.jteam.nl> > >N?HS^?隊[)?{(??[?Z?z??n襴?4D??w%?ا?6?i???l?&???x?+??ljwE??????j??zz0?'?????Zɩ?z{^??0?v?\???b??J??DNm??ڲ??brK???&? >??ƴ?]4?Mڽ?݊????Z??N??M???5J???jg??? z??????x%??R?????ڙ?(?G^??h????l???q???z?m????X???(?? ~??zw??X?????b???????jg??? z?? > |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-08-18 21:36:30
|
I've taken the Configurer approach, but might want to add the Resolver = later on... Why? Tiles includes a Locale specific DefinitionsFactory (I18FactorySet) that = loads definition files for different locales just as the = ResourceBundleViewResolver does. However, creating both properties-files = for the ResourceBundleViewResolver and definition files for the Tiles = definitions (one for each language) seems silly... When using the = InternalResourceViewResolver localization isn't (as the documentation = also says) possible... I didn't run into an app needing different definitions per language, but = this might be necessary for some people. Fro now the Configurer will = do!! By the way, I've set up a small example illustrating the Tiles behvaior = and a small HTML document which could be placed in the docs directory. = Shall I include those as well? Alef -----Oorspronkelijk bericht----- Van: spr...@li... = [mailto:spr...@li...] Namens = j=C3=BCrgen h=C3=B6ller [werk3AT] Verzonden: Monday, August 18, 2003 10:35 PM Aan: al...@jt...; spr...@li... Onderwerp: Re: [Springframework-developer] Adding Tiles to CVS... Hi Aref, =20 Then please go ahead! :-) =20 There's just one issue that I'd like to resolve: How do you set up Tiles = on startup? You've used a TilesViewResolver before which should not be = necessary. We've discussed a TilesConfigurer, analogous to the existing = VelocityConfigurer. What strategy did you choose in the end? =20 Regarding the libraries: Please only include the compile-time = dependencies, respectively the ones needed for executing the test suite. = We did the same for Hibernate to avoid too much bloat. All of the = libraries should go in lib/tiles, analogous to the existing = lib/hibernate. =20 Don't forget to use the new "spring" module with the org.springframework = packages... ;-) =20 Juergen =20 =20 -----Urspr=C3=BCngliche Nachricht-----=20 Von: Alef Arendsen (JTeam) [mailto:al...@jt...]=20 Gesendet: Mo 18.08.2003 22:13=20 An: spr...@li...=20 Cc:=20 Betreff: [Springframework-developer] Adding Tiles to CVS... =09 =09 Hi all,=20 I'm basically ready to add the Tiles functionality to the CVS. It's = tested and works fine.=20 We need to decide now which dependencies to include. Struts is = dependant on the following libraries. The ones that have an * with them = are the ones that are both compile-time and runtime, libraries without * = are only runtime dependencies: *commons-beanutils=20 *commons-digester=20 *commons-logging (we already have that one)=20 *struts (of course)=20 commons-collections=20 commons-lang=20 commons-validator=20 commons-fileupload=20 jakarta-oro=20 It's quite a list, but from the previous mails I saw nobody really = objected to including them. So just add them???=20 Regards,=20 Alef=20 =3D=3D=20 JTeam B.V.=20 Donker Curtiusstraat 7-412=20 1051 JL Amsterdam=20 T: +31 20 486 20 36=20 M: +31 6 24 11 1996=20 F: +31 84 837 00 00=20 E: al...@jt...=20 W: www.jteam.nl <file://www.jteam.nl> =20 N=18HS[=E9=8A=A2{ Zzn=044D=E8=B4=8A=D7=8Aw=D8=806i=17=11=CA=99x = jwjzz=0E=ED=B8=96=ED=B6=8C=C9=A9z{=DA=8Av\=13J N=1B rK=20 ]M=D3=BD=EF=8A=B7NM J jgz x=CB=A6 G =CB=B2q z m?X (=1E~zw X b=CB=9D? = jg=EB=B0=A2=1Dz=ED=BD=96=ED=B2=97 |
|
From: <jue...@we...> - 2003-08-18 21:07:14
|
QWxlZiwNCiANCkp1c3QgdG8gZ2V0IHRoZSBpZGVhOiBXaGF0IGRvIHlvdSBpbnRlbmQgdG8gYWRk IHRvIFNlcnZsZXRSZXF1ZXN0RGF0YUJpbmRlciB2aWEgc3ViY2xhc3Npbmc/IEFjY2VzcyBjb250 cm9sIHRvIHNwZWNpZmljIGZpZWxkcyBvZiBjb21tYW5kIG9yIGZvcm0gYmVhbnM/IEknbSBub3Qg c3VyZSBpZiB0aGUgYmluZGVyIGlzIHRoZSByaWdodCBwbGFjZSB0byBkbyBzdWNoIGEgdGhpbmcu DQogDQpGb3IgYWNjZXNzIGNvbnRyb2wgYXQgdGhlIGNvbnRyb2xsZXIgbGV2ZWwsIHlvdSBjb3Vs ZCB1c2UgYSBjdXN0b20gSGFuZGxlckludGVyY2VwdG9yIGltcGxlbWVudGF0aW9uLCB0byBiZSBy ZWdpc3RlcmVkIHdpdGggeW91ciBIYW5kbGVyTWFwcGluZy4gRXZlcnkgcmVxdWVzdCBtYXBwZWQg dGhlcmUgZ2V0cyBwYXNzZWQgdG8gdGhlIGludGVyY2VwdG9yIGZpcnN0IHRoZW4sIHdoaWNoIGlz IGFibGUgdG8gYWJvcnQgdGhlIGhhbmRsZXIgY2hhaW4gYW5kIHNvIHNvbWUgY3VzdG9tIHNlY3Vy aXR5IGZhaWx1cmUgcHJvY2Vzc2luZy4NCiANCkknbSBjdXJpb3VzIDotKQ0KIA0KSnVlcmdlbg0K IA0KIA0KDQoJLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IEFsZWYg QXJlbmRzZW4gKEpUZWFtKSBbbWFpbHRvOmFsZWZAanRlYW0ubmxdIA0KCUdlc2VuZGV0OiBNbyAx OC4wOC4yMDAzIDIyOjQyIA0KCUFuOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNv dXJjZWZvcmdlLm5ldCANCglDYzogDQoJQmV0cmVmZjogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9w ZXJdIE92ZXJyaWRpbmcgU2VydmxldFJlcXVlc3REYXRhQmluZGVyIChXQVM6IHBvbGlzaGluZyBh bmQgbmV3IGZlYXR1cmVzIC0gc2VjdXJpdHkgbW9kZWw/PykNCgkNCgkNCg0KCVRyZXZvciwgSnVl cmdlbiwNCgkNCglXZWxsLCBjb3VsZCBub3QgcmVhbGx5IGFuc3dlciBsYXN0IHR3byB3ZWVrcyBi ZWNhdXNlIG9mIGEgaG9saWRheS4uLg0KCQ0KCUFueXdheSwgSSd2ZSBiZWVuIHRoaW5raW5nIGFi b3V0IGl0IGFuZCBJIHRoaW5rIHlvdSBtYWRlIGEgZ29vZCBwb2ludCENCglUaGUgc29sdXRpb24g SSBhbSBpbXBsZW1lbnRpbmcgd2lsbCBub3QgYmUgaW50cnVzaXZlIGF0IGFsbCwgYnV0DQoJc3Bl Y2lmeWluZyBob3cgc2VjdXJpdHkgaXMgdG8gYmUgaGFuZGxlZCBkb2VzIG5vdCBzb3VuZCBsaWtl IGENCglyZXNwb25zaWJpbGl0eSBmb3IgdGhlIFNycGluZyBmcmFtZXdvcmsuLi4NCgkNCglIb3dl dmVyLCBzaW5jZSBJJ20gc3RpbGwgZ29pbmcgdG8gaW1wbGVtZW50IHRoaXMsIGluZGVlZCBJIG5l ZWQgdG8gYmUNCglhYmxlIHRvIG92ZXJyaWRlIHRvIFNlcnZsZXRSZXF1ZXN0RGF0YUJpbmRlciAo YW5kIEkgY2FuIHRoaW5rIG9mIG90aGVyDQoJc2l0dWF0aW9ucyB3aGVyZSB0aGlzIG1pZ2h0IGNv bWUgaW4gaGFuZHkpLiBCYXNpY2FseSBpdCdzIG5vdCByZWFsbHkNCglwb3NzaWJsZSByaWdodCBu b3cgc2luY2UgdGhlIEJpbmRlciBpcyBpbnN0YW50aWF0ZWQgaW4gYWJvdXQgNCBwbGFjZXMgaW4N CglhIGhhcmRjb2RlZCB3YXkuDQoJDQoJV2UgY291bGQgZG8gaXQgc29tZXdoYXQgc2ltaWxhciB0 byB0aGUgTG9jYWxlUmVzb2x2ZXIsIGJ1dCB0aGVuDQoJaW1wbGVtZW50aW5nIGEgRmFjdG9yeUJl YW4gdXNpbmcgYSBwcmVkZWZpbmVkIG5hbWUgKG9mIGNvdXJzZSBieSBkZWZhdWx0DQoJdGhlIFNl cnZsZXRSZXF1ZXN0RGF0YUJpbmRlciB3aWxsIGJlIHVzZWQpPz8NCgkNCglKdWVyZ2VuLCBoYXZl IHlvdSBnb3Qgb3BpbmlvbnMgYWJvdXQgdGhpcz8NCgkNCglBbGVmDQoJDQoJLS0tLS1Pb3JzcHJv bmtlbGlqayBiZXJpY2h0LS0tLS0NCglWYW46IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXItYWRt aW5AbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJW21haWx0bzpzcHJpbmdmcmFtZXdvcmstZGV2ZWxv cGVyLWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldF0gTmFtZW5zDQoJVHJldm9yIENvb2sNCglW ZXJ6b25kZW46IEZyaWRheSwgQXVndXN0IDAxLCAyMDAzIDQ6MzcgUE0NCglBYW46IHNwcmluZ2Zy YW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJT25kZXJ3ZXJwOiBSRTog W1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIHBvbGlzaGluZyBhbmQgbmV3IGZlYXR1cmVzIC0N CglzZWN1cml0eSBtb2RlbD8/Pz8/Pw0KCQ0KCQ0KCUkgdGhpbmsgU2VjdXJpdHkgbWlnaHQgYmUg dG9vIGxhcmdlIGFuIGlzc3VlIHRvIGJlIGFkZHJlc3NlZCBpbiBTcHJpbmcsDQoJYXQgbGVhc3Qg d2l0aG91dCBjb21wbGljYXRpbmcgaXQgZXZlbiBmdXJ0aGVyLiAgV2hpbGUgeW91J3JlIGlkZWEg aGFzDQoJcHJvbWlzZSwgdGhlcmUgYXJlIHNvIG1hbnkgb3RoZXIgd2F5cyBvZiBoYW5kbGluZyBp dCAoc3VjaCBhcyB3aXRoIGRiDQoJcGVybWlzc2lvbnMsIGhhbmRsaW5nIG9ubHkgaW4gY2VydGFp biBsYXllcnMsIGNyZWF0aW5nIG9iamVjdA0KCWhpZXJhcmNoaWVzIHdpdGggZGlmZmVyZW50DQoJ bWV0aG9kcykgdGhhdCBteSBvcGluaW9uIGlzIHdlIHNob3VsZCBsZWF2ZSBpdC4gIFNwcmluZydz IHBoaWxvc29waHkNCgkoSU1PKSBoYXMgYmVlbiBhYm91dCBwcm92aWRpbmcgYSBnZW5lcmljIGNv cmUgaW5mcmFzdHJ1Y3R1cmUgdGhhdCBkb2VzDQoJTk9UIGludHJ1ZGUgb24gdGhlIGJ1c2luZXNz IGxheWVyLCBhbmQgZG9lcyBub3QgZW5mb3JjZSBhIHNwZWNpZmljIHdheQ0KCW9mIGNvZGluZyAo Zm9yIGV4YW1wbGUgdGhlIHdob2xlIEpEQkMgdnMgRUpCIHZzIEhpYmVybmF0ZSB2cyBKRE8gaXMN CgloYW5kbGVkIHNlYW1sZXNzbHkgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgdGhlIGJ1c2luZXNz IGxheWVyKS4gIEkgd291bGQNCgl2b3RlIGFnYWluc3QgYWRkaW5nIHRoZSBzb3J0IG9mIGhhbmRs aW5nIHlvdSdyZSBkZXNjcmliaW5nLg0KCQ0KCVRoYXQgYmVpbmcgc2FpZCwgd2UgaGF2ZSBydW4g aW50byBzb21lIG9mIHRoZSBpc3N1ZXMgeW91J3JlIGRpc2N1c3NpbmcNCglpbiBvdXIgcHJvZ3Jh bW1pbmcgb3ZlciB0aGUgbGFzdCBmZXcgbW9udGhzIG9uIGEgU3ByaW5nLWJhc2VkIHdlYi1hcHAu DQoJV2Ugc29sdmVkIG91ciBwcm9ibGVtIHRocm91Z2ggY3VzdG9tIHRhZ2xpYnMgaW4gdGhlIChq c3ApIHdlYiBsYXllcg0KCSh0aGlzIGhhbmRsZXMgYWNjZXNzb3JzKSwgYW5kIHlvdSBjYW4gdXNl IGEgY3VzdG9tIGJpbmRlciAoaW5zdGVhZCBvZg0KCXRoZSBkZWZhdWx0IGZyb20gQmluZFV0aWxz KSB3aGljaCByZWNlaXZlcyB0aGUgcmVxdWVzdCBvYmplY3QgKHNvIGhhcw0KCWFjY2VzcyB0byBz ZWN1cml0eQ0KCWluZm8pIGJlZm9yZSBwcm9jZXNzaW5nIGVhY2ggb2JqZWN0LiAgSSdtIG5vdCBx dWl0ZSB1cC10by1zcGVlZCBvbiB0aGUNCgljdXJyZW50IGNvZGViYXNlLCBzbyBKdWVyZ2VuIG1h eSBoYXZlIGEgInF1aWNrLXRpcCIgb24gaG93IGJlc3QgdG8NCglvdmVycmlkZSB0aGUgYmluZGVy IHVzZWQuICBBT1AgYWxzbyBsb29rcyB2ZXJ5IHByb21pc2luZywgYWx0aG91Z2ggSQ0KCWhhdmUg eWV0IHRvIGdldCBpbnRvIGl0Lg0KCQ0KCUJhc2ljYWxseSwgU3ByaW5nIHByb3ZpZGVzIG1hbnkg d2F5cyBmb3IgeW91IHRvIGhhbmRsZSB5b3VyIHByb2JsZW0NCglhY2NvcmRpbmcgdG8geW91ciBu ZWVkcywgYnV0IEkgZG9uJ3QgdGhpbmsgd2UgY2FuIGdlbmVyYWxpemUgdGhlDQoJKHNlY3VyaXR5 KSBzb2x1dGlvbiwgb25seSB0aGUgdG9vbHMgKFNwcmluZykgdG8gZGVhbCB3aXRoIGl0IGFzIG5l ZWRlZC4NCgkNCglNeSAyIGNlbnRzLg0KCQ0KCVRyZXZvciBELiBDb29rDQoJDQoJDQoJLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCglGcm9tOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyLWFk bWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KCVttYWlsdG86c3ByaW5nZnJhbWV3b3JrLWRldmVs b3Blci1hZG1pbkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXRdT24gQmVoYWxmDQoJT2YgQWxlZiBBcmVu ZHNlbiAoSlRlYW0pDQoJU2VudDogQXVndXN0IDEsIDIwMDMgNDoyNCBBTQ0KCVRvOiAnVGltbyBW ZXJob2V2ZW4nOyBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5l dA0KCVN1YmplY3Q6IFJFOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gcG9saXNoaW5nIGFu ZCBuZXcgZmVhdHVyZXMgLQ0KCXNlY3VyaXR5IG1vZGVsPz8/Pz8/DQoJDQoJDQoJPHF1b3RlPg0K CSBDIC0gWyBkZXBlbmRzIG9uIHByb2plY3QgXQ0KCSBCIC0gUE9KTyBCdXNpbmVzcyBPYmplY3Rz DQoJIEEgLSBQT0pPIERBTyBPYmplY3RzIChIaWJlcm5hdGUgaW4gbXkgY2FzZSkNCgkNCgkgT2Jq ZWN0cyBpbiBlYWNoIGxheWVyIG1heSBvbmx5IGNhbGwgb3RoZXIgT2JqZWN0IGluIHRoZSBzYW1l IGxheWVyIG9yDQoJT2JqZWN0cyBpbiB0aGUgTkVYVCBsb3dlciBsYXllci4NCgkNCgkgR2l2ZW4g SSB3YXMgdG8gYnVpbGQgYW4gRUpCIHNvbHV0aW9uLCBsYXllciBDIHdvdWxkIGJlIGEgU0lOR0xF IHNlc3Npb24NCgkNCgkgZmFjYWRlIFNMU0IgKHNpbmdsZSBiZWNhdXNlIEkgd2FudCB0byBhdm9p ZCBDT1NUTFkgaW50ZXIgRUpCIGNhbGxzKS4NCglGb3IgdGVzdGluZy9RQSwgSSB3b3VsZCB3cml0 ZSB1bml0dGVzdHMgYXQgbGF5ZXIgQyB0byB0ZXN0IEIgYW5kIEEsIGFuZA0KCQ0KCSBtYXliZSB1 bml0dGVzdHMgYXQgbGF5ZXIgRCB0byB0ZXN0IHRoZSBTTFNCLiBGb3IgbWFpbnRlbmFuY2UNCgko ZGV2ZWxvcGVycyBvbmx5KSBJIGNvdWxkIHdyaXRlIGFub3RoZXIgUE9KTyBqYXZhLWFwcCBydW5u aW5nIGF0IEMuIElmDQoJSSB3YW50ZWQgdG8gQ0hBTkdFIHRoZSBzb2x1dGlvbi10eXBlIGZyb20g RUpCIHRvIHdlYmludGVyZmFjZSBJIGNvdWxkDQoJZWl0aGVyIHJlcGxhY2UgdGhlIFNMU0IgYXQg QyB3aXRoIHNlcnZsZXRzL2pzcHMvZXRjLiBvciB3cml0ZSBhDQoJc2VydmxldC9qc3AvZXRjLiBs YXllciBhdCBEIHVzaW5nIEVKQiBsYXllciBDLiA8L3F1b3RlPiBXZWxsLCB0aGlzIGlzbid0DQoJ dmVyeSBvZGQhIEl0IHJlc2VtYmxlcyB0aGUgd2F5IHdlIChhbmQgcHJvYmFibHkgYSBsb3QgT2Yg b3RoZXIgcGVvcGxlKQ0KCWRvIHRoaW5ncy4uLg0KCQ0KCTxxdW90ZT4NCgkgVGhlIGFib3ZlIGFw cGVhcnMgVkVSWSBGTEVYQklMRSB0byBtZS4gSWYgSSBnb3QgeW91IHJpZ2h0LCB5b3Ugd291bGQN CglsaWtlIHRvIGFkZCBzZWN1cml0eSBhdCBsYXllciBBLiBUaGlzIHdvdWxkIHNjcmV3IHVwIHRo ZSBtb2RlbCBhdA0KCXZhcmlvdXMgcG9pbnRzIChteSBwcm9ibGVtIC0gSSBkbyBub3QgaGF2ZSB0 byB1c2UgdGhvc2Ugc2VjdXJpdHkNCglmZWF0dXJlcykuIEZ1cnRoZXJtb3JlLCBpdCBtaWdodCBu b3QgYmUgYSBnb29kIGlkZWEgdG8gaGF2ZSBhIGRlcGVuY3kNCglpbiBhIFNwcmluZyBzZWN1cml0 eSBBUEkgb24gU1BFQ0lGSUMgb3RoZXIgc2VjdXJpdHkgcHJvdmlkaW5nDQoJZnJhbWV3b3JrcyBz dWNoIGFzIEVKQiBhbmQgU2VydmxldHMgLSByZWx5aW5nIG9uIHRoZSBQcmluY2lwYWwNCglpbnRl cmZhY2Ugc29ydCBvZiBpbnRyb2R1Y2VzIHN1Y2ggYSBkZXBlbmRlbmN5LCB0aG91Z2guDQoJDQoJ IFBsZWFzZSBkb24ndCBnZXQgbWUgd3Jvbmc6IFRoZXNlIGFyZSBtYWlubHkgbXkgdGhvdWdodHMg b24gaG93IHlvdXINCglwcm9wb3NhbCB3b3VsZCBhZmZlY3QgbXkgY3VycmVudCBtb2RlbC4uLiA8 L3F1b3RlPiBJIHRvdGFsbHkgZ2V0IHlvdXINCglwb2ludC4gVGhlIHdheSB5b3UncmUgd29ya2lu ZyBpcyBleGFjdGx5IHRoZSBzYW1lIGFzIFdlIGRvLiBXZSBjYWxsDQoJbGF5ZXJzIEEgJiBCICh0 aGV5IGRvbid0IGRpZmZlciBtdWNoIGhlcmUpIHRoZSBtb2R1bGUgbGF5ZXIgaGVyZSwgdGhlDQoJ bGF5ZXIgYWJvdmUgaXMgdGhlIGNvbXBvbmVudCBsYXllciBjb250YWluaW5nIGJ1c2luZXNzIGxv Z2ljLi4uIE1vZHVsZXMNCgljYW4ndCBoYXZlIHNlY3VyaXR5LCBjYW4ndCBoYXZlIGlvLCBjYW4n dCBoYXZlIG5ldHdvcmtpbmcgZXRjdGVyYQ0KCShiYXNpY2FsbHkgYWxsIEVKQiBmb3JiaWRzKS4u LiBUaGUgY29tcG9uZW50IGxheWVyIGNvbnRhaW5zDQoJdHJhbnNhY3Rpb25zL3NlY3VyaXR5LCBl dGN0ZXJhLg0KCQ0KCVRoZSB0aGluZyBpcywgdGhhdCB0aGUgc2VjdXJpdHkgbW9kZWwgSjJFRSBw cm92aWRlcyBkb2VzIG5vdCBtZWV0IG91cg0KCWRlbWFuZHMgd2hlbiBpdCBjb21lcyB0byBzZWN1 cml0eSBmb3IgX19wYXJ0cyBvZiBvYmplY3RzX18uIEknbSB0cnlpbmcNCgl0byBmaWd1cmUgb3V0 IHNvbWV0aGluZyB0byBhZGQgdGhpcy4gVGhpcyBkb2VzIG5vdCBtZWFuIEknbSBpbnRydWRpbmcg b24NCgl0aGUgbW9kdWxlIGxldmVsIChBK0IpLiBZb3UgY2FuIGNvbXBhcmUgaXQgYSBsb3Qgd2l0 aCB0aGUgdmFsaWRhdGlvbg0KCWZyYW1ld29yay4gV2UncmUgaGF2aW5nIHRoZSBjb21tb25zIHZh bGlkYXRvciBpbmNsdWRlZCBhcyB2YWxpZGF0b3IgZm9yDQoJdGhlIFNwcmluZyBmcmFtZXdvcmsg KGp1c3QgZXh0ZW5kIHRoZSB2YWxpZGF0b3IgaW50ZXJmYWNlIGFuZCB1c2UgdGhlDQoJY29tbW9u cyB2YWxpZGF0b3IgdGhlcmUpLiBFYWNoIGRhdGEgb2JqZWN0IGluIG91ciBzeXN0ZW0gaGFzIGEN Cgl2YWxpZGF0aW9uLnhtbCBmaWxlIChsb2NhdGVkIHJpZ2h0IGJlc2lkZSB0aGUgY2xhc3MgZmls ZSwgY2FsbGVkDQoJW2NsYXNzXS52YWxpZGF0aW9uLnhtbCkuIFRoaXMgbWVhbnMgSSBoYXZlbid0 IGludHJ1ZGVkIG9uIHRoZSBkYXRhDQoJbGV2ZWwsIGp1c3QgYWRkZWQgYSBkZXNjaXJwdG9yZmls ZSwgZGVzY3JpYmluZyB2YWxpZGF0aW9uIHJ1bGVzLi4uIE5vDQoJZXh0cmEgaW50ZXJmYWNlIChJ IGhhdGUgdGhhdCA7LSkuIFNhbWUgdGhpbmcgaG9sZHMgZm9yIHRoZSBIaWJlcm5hdGUNCglzdHVm Zi4uLiBXZSdyZSB1c2luZyBhIHByb3ByaWV0YXJ5IGxpdHRsZSBmYXJtZXdvcmsgZm9yIGludGVn cmF0aW9uIG9mDQoJSGliZXJuYXRlIGludG8gU3ByaW5nICh3b3VsZCByYXRoZXIgaGF2ZSB1c2Vk IFNwcmluZyBoZXJlLCBidXQgdGhlDQoJZnJhbWV3b3JrIGlzIGFscmVhZHkgaW4gcGxhY2UgZm9y IGEgbG9uZyB0aW1lKS4gVGhlIEhpYmVybmF0ZSBmaWxlcyBhcmUNCglwbGFjZWQgcmlnaHQgYmVz aWRlcyB0aGUgZGF0YSBmaWxlcyBhbmQgYXJlIGNhbGxlZCBbY2xhc3NdLmhibS54bWwuDQoJDQoJ UmlnaHQgbm93IEkgd2FudCB0byBhZGQgc2VjdXJpdHkuIEhPVyB0aGUgc2VjdXJpdHkgaXMgZG9u ZSwgaXMgYWN0dWFsbHkNCglkZXRlcm1pbmUgYnkgdGhlIHNlY3VyaXR5LWltcGxlbWVudGF0aW9u IChpbiB0aGlzIGNhdXNlIGENCglSb2xlT2JqZWN0UGVybWlzc2lvbnNXaGF0ZXZlciwgX19sb2Nh dGVkIGF0IHRoZSBjb21wb25lbnQgbGV2ZWwgKFNwcmluZw0KCSsgQylfXywgaG93ZXZlciB1c2lu ZyB0aGUgZGVzY3JpcHRvciBmaWxlcyBmcm9tIHRoZSBtb2R1bGUgbGV2ZWwNCgkoQStCKS4uLiBO byBleHRyYSBpbnRlcmZhY2Ugb3IgY2xhc3NlcyB0byBleHRlbmQsIGp1c3QgYW4gZXh0cmENCglk ZXNjcmlwdGlvbi4NCgkNCglXaGF0IHRoZSBjcml0ZXJpYSBmb3IgdGhlIHBlcm1pc3Npb25zIHdv dWxkIGJlLCBpcyB0b3RhbGx5IHVwIHRvIHRoZQ0KCWltcGxlbWVudGF0aW9uLiBJbiB0aGlzIGNh c2UgSSBuZWVkIFJvbGUvUHJpbmNpcGFsIGluZm9ybWF0aW9uLCB3aGljaA0KCW1lYW5zIEkgZWl0 aGVyIG5lZWQgdGhlIFNlc3Npb25Db250ZXh0L0VudGl0eUNvbnRleHQgb3IgYSBTZXJ2bGV0UmVx dWVzdA0KCSh3aGF0ZXZlciwgc29tZXRoaW5nIHVzaW5nIEpBQVMvamF2YXguc2VjdXJpdHkpLiBU aGlzIG1lYW5zIHRoZQ0KCWltcGxlbWVudGF0aW9uIGNhbiBfX25ldmVyX18gYmUgbG9jYXRlZCBh dCB0aGUgbW9kdWxlbGF5ZXIgKEErQikuIE90aGVyDQoJaW1wbGVtZW50YXRpb25zIHdvdWxkIHBy b3ZpZGUgdGltZSBiYXNlZCBwZXJtaXNzaW9ucyAoYmV0d2VlbiAyYW0tM2FtDQoJbm90IHBvc3Np YmxlIHRvIGVkaXQgYmFja3VwIHNjaGVkdWxlLCBiZWNhdXNlIGJhY2t1cCBpcyBhY3R1YWxseSBk b25lDQoJdGhlbikuLi4NCgkNCglBbnl3YXksIEkgaG9wZSB0aGlzIGNsYXJpZmllcyB0aGluZ3Mg YSBsaXR0bGUgYml0IGFuZCBJIGhvcGUgdG8gZ2V0IHNvbWUNCgltb3JlIGZlZWRiYWNrIGFuZCBz dHVmZiAocGVvcGxlIGp1c3Qgc2hvdXRpbmcgX19hcmdoaCB0aGlzIGlzIHVnbHlfXw0KCXdvdWxk IGRvIGFzIHdlbGwhISEpLi4uDQoJDQoJVGhhbngsDQoJDQoJQWxlZg0KCQ0KCQ0KCQ0KCS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCglUaGlz IFNGLk5ldCBlbWFpbCBzcG9uc29yZWQgYnk6IEZyZWUgcHJlLWJ1aWx0IEFTUC5ORVQgc2l0ZXMg aW5jbHVkaW5nDQoJRGF0YSBSZXBvcnRzLCBFLWNvbW1lcmNlLCBQb3J0YWxzLCBhbmQgRm9ydW1z IGFyZSBhdmFpbGFibGUgbm93Lg0KCURvd25sb2FkIHRvZGF5IGFuZCBlbnRlciB0byB3aW4gYW4g WEJPWCBvciBWaXN1YWwgU3R1ZGlvIC5ORVQuDQoJaHR0cDovL2FzcG5ldC5jbGljay11cmwuY29t L2dvL3BzYTAwMTAwMDAzYXZlL2RpcmVjdDthdC5hc3BuZXRfMDcyMzAzXzAxDQoJLzAxDQoJX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCglTcHJpbmdmcmFt ZXdvcmstZGV2ZWxvcGVyIG1haWxpbmcgbGlzdA0KCVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJA bGlzdHMuc291cmNlZm9yZ2UubmV0DQoJaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlz dHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcg0KCQ0KCS0tLQ0KCUluY29taW5n IG1haWwgaXMgY2VydGlmaWVkIFZpcnVzIEZyZWUuDQoJQ2hlY2tlZCBieSBBVkcgYW50aS12aXJ1 cyBzeXN0ZW0gKGh0dHA6Ly93d3cuZ3Jpc29mdC5jb20pLg0KCVZlcnNpb246IDYuMC41MDIgLyBW aXJ1cyBEYXRhYmFzZTogMzAwIC0gUmVsZWFzZSBEYXRlOiAxOC8wNy8yMDAzDQoJDQoJDQoJDQoJ LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K CVRoaXMgU0YuTmV0IGVtYWlsIHNwb25zb3JlZCBieTogRnJlZSBwcmUtYnVpbHQgQVNQLk5FVCBz aXRlcyBpbmNsdWRpbmcNCglEYXRhIFJlcG9ydHMsIEUtY29tbWVyY2UsIFBvcnRhbHMsIGFuZCBG b3J1bXMgYXJlIGF2YWlsYWJsZSBub3cuDQoJRG93bmxvYWQgdG9kYXkgYW5kIGVudGVyIHRvIHdp biBhbiBYQk9YIG9yIFZpc3VhbCBTdHVkaW8gLk5FVC4NCglodHRwOi8vYXNwbmV0LmNsaWNrLXVy bC5jb20vZ28vcHNhMDAxMDAwMDNhdmUvZGlyZWN0O2F0LmFzcG5ldF8wNzIzMDNfMDENCgkvMDEN CglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCVNwcmlu Z2ZyYW1ld29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQoJU3ByaW5nZnJhbWV3b3JrLWRldmVs b3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCglodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5l dC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQoJDQoJDQoJDQoJLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCVRo aXMgU0YuTmV0IGVtYWlsIHNwb25zb3JlZCBieTogRnJlZSBwcmUtYnVpbHQgQVNQLk5FVCBzaXRl cyBpbmNsdWRpbmcNCglEYXRhIFJlcG9ydHMsIEUtY29tbWVyY2UsIFBvcnRhbHMsIGFuZCBGb3J1 bXMgYXJlIGF2YWlsYWJsZSBub3cuDQoJRG93bmxvYWQgdG9kYXkgYW5kIGVudGVyIHRvIHdpbiBh biBYQk9YIG9yIFZpc3VhbCBTdHVkaW8gLk5FVC4NCglodHRwOi8vYXNwbmV0LmNsaWNrLXVybC5j b20vZ28vcHNhMDAxMDAwMDNhdmUvZGlyZWN0O2F0LmFzcG5ldF8wNzIzMDNfMDEvMDENCglfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCVNwcmluZ2ZyYW1l d29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQoJU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBs aXN0cy5zb3VyY2Vmb3JnZS5uZXQNCglodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0 cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQoJDQoNCg== |
|
From: <tri...@tr...> - 2003-08-18 20:46:38
|
Lars,
Try this:
I'm assuming that you have a datasource set up in WebLogic and that it's JNDI
name is cxwHibernate. You should check this name by viewing the JNDI tree from
WebLogic console.
Make sure that you have a <resource-ref> set up in web.xml that you reference in
the applicationContext.xml (I'll use the name refHibernate). In weblogic.xml
you link this resource-ref to the actual JNDI name specified in WLS
configuration (I'll use the name cxwHibernate).
In application.xml use the following:
<beans>
<bean id="dataSource" class="com.interface21.jndi.JndiObjectFactoryBean">
<property name="jndiName"><value>refHibernate</value></property>
</bean>
<!-- more bean definitions -->
<beans>
In web.xml use:
<resource-ref>
<description>The data source ref name</description>
<res-ref-name>refHibernate</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
In weblogic.xml use:
<weblogic-web-app>
<description>WebLogic data source JNDI name</description>
<reference-descriptor>
<resource-description>
<res-ref-name>refHibernate</res-ref-name>
<jndi-name>cxwHibernate</jndi-name>
</resource-description>
</reference-descriptor>
</weblogic-web-app>
If this does not work, could you post the web.xml and weblogic.xml that you are
using.
Thomas
> Hi all,
>
> I have a problem with a DataSource definition in applicationContext.xml.
>
> I've defined a connection pool and a data source with WebLogic 8.1 but
> at deployment time Spring says:
>
> 18.08.2003 17.42 Uhr CEST> <Warning> <HTTP> <BEA-101162> <User defined
> listener com.interface21.web.context.ContextLoaderListener failed:
> com.interface21.context.ApplicationContextException: Cannot load
> configuration: problem
> instantiating or initializing beans; nested exception is:
> com.interface21.beans.FatalBeanException: afterPropertiesSet on with
> name 'cwxDataSource' threw an exception; nested exception is:
> javax.naming.NameNotFoundException: While trying to look up
> comp/env/cxwHibernate in /app/webapp/springapp/22589165.; remaining name
> 'comp/env/cxwHibernate'.>
>
> This may be a WebLogic issue but I can't find any good BEA documentation for
> this issue.
>
> Does anyone have experience configuring WebLogic JNDI with Spring ?
>
> Thanks
> Lars
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
|
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-08-18 20:41:57
|
Trevor, Juergen, Well, could not really answer last two weeks because of a holiday... Anyway, I've been thinking about it and I think you made a good point! The solution I am implementing will not be intrusive at all, but specifying how security is to be handled does not sound like a responsibility for the Srping framework... However, since I'm still going to implement this, indeed I need to be able to override to ServletRequestDataBinder (and I can think of other situations where this might come in handy). Basicaly it's not really possible right now since the Binder is instantiated in about 4 places in a hardcoded way. We could do it somewhat similar to the LocaleResolver, but then implementing a FactoryBean using a predefined name (of course by default the ServletRequestDataBinder will be used)?? Juergen, have you got opinions about this? Alef -----Oorspronkelijk bericht----- Van: spr...@li... [mailto:spr...@li...] Namens Trevor Cook Verzonden: Friday, August 01, 2003 4:37 PM Aan: spr...@li... Onderwerp: RE: [Springframework-developer] polishing and new features - security model?????? I think Security might be too large an issue to be addressed in Spring, at least without complicating it even further. While you're idea has promise, there are so many other ways of handling it (such as with db permissions, handling only in certain layers, creating object hierarchies with different methods) that my opinion is we should leave it. Spring's philosophy (IMO) has been about providing a generic core infrastructure that does NOT intrude on the business layer, and does not enforce a specific way of coding (for example the whole JDBC vs EJB vs Hibernate vs JDO is handled seamlessly from the perspective of the business layer). I would vote against adding the sort of handling you're describing. That being said, we have run into some of the issues you're discussing in our programming over the last few months on a Spring-based web-app. We solved our problem through custom taglibs in the (jsp) web layer (this handles accessors), and you can use a custom binder (instead of the default from BindUtils) which receives the request object (so has access to security info) before processing each object. I'm not quite up-to-speed on the current codebase, so Juergen may have a "quick-tip" on how best to override the binder used. AOP also looks very promising, although I have yet to get into it. Basically, Spring provides many ways for you to handle your problem according to your needs, but I don't think we can generalize the (security) solution, only the tools (Spring) to deal with it as needed. My 2 cents. Trevor D. Cook -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Alef Arendsen (JTeam) Sent: August 1, 2003 4:24 AM To: 'Timo Verhoeven'; spr...@li... Subject: RE: [Springframework-developer] polishing and new features - security model?????? <quote> C - [ depends on project ] B - POJO Business Objects A - POJO DAO Objects (Hibernate in my case) Objects in each layer may only call other Object in the same layer or Objects in the NEXT lower layer. Given I was to build an EJB solution, layer C would be a SINGLE session facade SLSB (single because I want to avoid COSTLY inter EJB calls). For testing/QA, I would write unittests at layer C to test B and A, and maybe unittests at layer D to test the SLSB. For maintenance (developers only) I could write another POJO java-app running at C. If I wanted to CHANGE the solution-type from EJB to webinterface I could either replace the SLSB at C with servlets/jsps/etc. or write a servlet/jsp/etc. layer at D using EJB layer C. </quote> Well, this isn't very odd! It resembles the way we (and probably a lot Of other people) do things... <quote> The above appears VERY FLEXBILE to me. If I got you right, you would like to add security at layer A. This would screw up the model at various points (my problem - I do not have to use those security features). Furthermore, it might not be a good idea to have a depency in a Spring security API on SPECIFIC other security providing frameworks such as EJB and Servlets - relying on the Principal interface sort of introduces such a dependency, though. Please don't get me wrong: These are mainly my thoughts on how your proposal would affect my current model... </quote> I totally get your point. The way you're working is exactly the same as We do. We call layers A & B (they don't differ much here) the module layer here, the layer above is the component layer containing business logic... Modules can't have security, can't have io, can't have networking etctera (basically all EJB forbids)... The component layer contains transactions/security, etctera. The thing is, that the security model J2EE provides does not meet our demands when it comes to security for __parts of objects__. I'm trying to figure out something to add this. This does not mean I'm intruding on the module level (A+B). You can compare it a lot with the validation framework. We're having the commons validator included as validator for the Spring framework (just extend the validator interface and use the commons validator there). Each data object in our system has a validation.xml file (located right beside the class file, called [class].validation.xml). This means I haven't intruded on the data level, just added a descirptorfile, describing validation rules... No extra interface (I hate that ;-). Same thing holds for the Hibernate stuff... We're using a proprietary little farmework for integration of Hibernate into Spring (would rather have used Spring here, but the framework is already in place for a long time). The Hibernate files are placed right besides the data files and are called [class].hbm.xml. Right now I want to add security. HOW the security is done, is actually determine by the security-implementation (in this cause a RoleObjectPermissionsWhatever, __located at the component level (Spring + C)__, however using the descriptor files from the module level (A+B)... No extra interface or classes to extend, just an extra description. What the criteria for the permissions would be, is totally up to the implementation. In this case I need Role/Principal information, which means I either need the SessionContext/EntityContext or a ServletRequest (whatever, something using JAAS/javax.security). This means the implementation can __never__ be located at the modulelayer (A+B). Other implementations would provide time based permissions (between 2am-3am not possible to edit backup schedule, because backup is actually done then)... Anyway, I hope this clarifies things a little bit and I hope to get some more feedback and stuff (people just shouting __arghh this is ugly__ would do as well!!!)... Thanx, Alef ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ 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.502 / Virus Database: 300 - Release Date: 18/07/2003 ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2003-08-18 20:36:43
|
SGkgQXJlZiwNCiANClRoZW4gcGxlYXNlIGdvIGFoZWFkISA6LSkNCiANClRoZXJlJ3MganVzdCBv bmUgaXNzdWUgdGhhdCBJJ2QgbGlrZSB0byByZXNvbHZlOiBIb3cgZG8geW91IHNldCB1cCBUaWxl cyBvbiBzdGFydHVwPyBZb3UndmUgdXNlZCBhIFRpbGVzVmlld1Jlc29sdmVyIGJlZm9yZSB3aGlj aCBzaG91bGQgbm90IGJlIG5lY2Vzc2FyeS4gV2UndmUgZGlzY3Vzc2VkIGEgVGlsZXNDb25maWd1 cmVyLCBhbmFsb2dvdXMgdG8gdGhlIGV4aXN0aW5nIFZlbG9jaXR5Q29uZmlndXJlci4gV2hhdCBz dHJhdGVneSBkaWQgeW91IGNob29zZSBpbiB0aGUgZW5kPw0KIA0KUmVnYXJkaW5nIHRoZSBsaWJy YXJpZXM6IFBsZWFzZSBvbmx5IGluY2x1ZGUgdGhlIGNvbXBpbGUtdGltZSBkZXBlbmRlbmNpZXMs IHJlc3BlY3RpdmVseSB0aGUgb25lcyBuZWVkZWQgZm9yIGV4ZWN1dGluZyB0aGUgdGVzdCBzdWl0 ZS4gV2UgZGlkIHRoZSBzYW1lIGZvciBIaWJlcm5hdGUgdG8gYXZvaWQgdG9vIG11Y2ggYmxvYXQu IEFsbCBvZiB0aGUgbGlicmFyaWVzIHNob3VsZCBnbyBpbiBsaWIvdGlsZXMsIGFuYWxvZ291cyB0 byB0aGUgZXhpc3RpbmcgbGliL2hpYmVybmF0ZS4NCiANCkRvbid0IGZvcmdldCB0byB1c2UgdGhl IG5ldyAic3ByaW5nIiBtb2R1bGUgd2l0aCB0aGUgb3JnLnNwcmluZ2ZyYW1ld29yayBwYWNrYWdl cy4uLiA7LSkNCiANCkp1ZXJnZW4NCiANCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJp Y2h0LS0tLS0gDQoJVm9uOiBBbGVmIEFyZW5kc2VuIChKVGVhbSkgW21haWx0bzphbGVmQGp0ZWFt Lm5sXSANCglHZXNlbmRldDogTW8gMTguMDguMjAwMyAyMjoxMyANCglBbjogc3ByaW5nZnJhbWV3 b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgDQoJQ2M6IA0KCUJldHJlZmY6IFtT cHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBBZGRpbmcgVGlsZXMgdG8gQ1ZTLi4uDQoJDQoJDQoN CglIaSBhbGwsIA0KDQoJSSdtIGJhc2ljYWxseSByZWFkeSB0byBhZGQgdGhlIFRpbGVzIGZ1bmN0 aW9uYWxpdHkgdG8gdGhlIENWUy4gSXQncyB0ZXN0ZWQgYW5kIHdvcmtzIGZpbmUuIA0KDQoJV2Ug bmVlZCB0byBkZWNpZGUgbm93IHdoaWNoIGRlcGVuZGVuY2llcyB0byBpbmNsdWRlLiBTdHJ1dHMg aXMgZGVwZW5kYW50IG9uIHRoZSBmb2xsb3dpbmcgbGlicmFyaWVzLiBUaGUgb25lcyB0aGF0IGhh dmUgYW4gKiB3aXRoIHRoZW0gYXJlIHRoZSBvbmVzIHRoYXQgYXJlIGJvdGggY29tcGlsZS10aW1l IGFuZCBydW50aW1lLCBsaWJyYXJpZXMgd2l0aG91dCAqIGFyZSBvbmx5IHJ1bnRpbWUgZGVwZW5k ZW5jaWVzOg0KDQoJKmNvbW1vbnMtYmVhbnV0aWxzIA0KCSpjb21tb25zLWRpZ2VzdGVyIA0KCSpj b21tb25zLWxvZ2dpbmcgKHdlIGFscmVhZHkgaGF2ZSB0aGF0IG9uZSkgDQoJKnN0cnV0cyAob2Yg Y291cnNlKSANCgljb21tb25zLWNvbGxlY3Rpb25zIA0KCWNvbW1vbnMtbGFuZyANCgljb21tb25z LXZhbGlkYXRvciANCgljb21tb25zLWZpbGV1cGxvYWQgDQoJamFrYXJ0YS1vcm8gDQoNCglJdCdz IHF1aXRlIGEgbGlzdCwgYnV0IGZyb20gdGhlIHByZXZpb3VzIG1haWxzIEkgc2F3IG5vYm9keSBy ZWFsbHkgb2JqZWN0ZWQgdG8gaW5jbHVkaW5nIHRoZW0uIFNvIGp1c3QgYWRkIHRoZW0/Pz8gDQoN CglSZWdhcmRzLCANCg0KCUFsZWYgDQoNCgk9PSANCglKVGVhbSBCLlYuIA0KCURvbmtlciBDdXJ0 aXVzc3RyYWF0IDctNDEyIA0KCTEwNTEgSkwgIEFtc3RlcmRhbSANCglUOiArMzEgMjAgNDg2IDIw IDM2IA0KCU06ICszMSA2IDI0IDExIDE5OTYgDQoJRjogKzMxIDg0IDgzNyAwMCAwMCANCglFOiBh bGVmQGp0ZWFtLm5sIA0KCVc6IHd3dy5qdGVhbS5ubCA8ZmlsZTovL3d3dy5qdGVhbS5ubD4gIA0K DQo= |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-08-18 20:13:11
|
Hi all, I'm basically ready to add the Tiles functionality to the CVS. It's tested and works fine. We need to decide now which dependencies to include. Struts is dependant on the following libraries. The ones that have an * with them are the ones that are both compile-time and runtime, libraries without * are only runtime dependencies: *commons-beanutils *commons-digester *commons-logging (we already have that one) *struts (of course) commons-collections commons-lang commons-validator commons-fileupload jakarta-oro It's quite a list, but from the previous mails I saw nobody really objected to including them. So just add them??? Regards, Alef == JTeam B.V. Donker Curtiusstraat 7-412 1051 JL Amsterdam T: +31 20 486 20 36 M: +31 6 24 11 1996 F: +31 84 837 00 00 E: al...@jt... W: www.jteam.nl |
|
From: <rod...@in...> - 2003-08-18 19:12:03
|
Lars, I'm at an internet cafe in the Rockies, so I can't examine your specific problem, but I've used Spring extensively with WLS 8.1 and a little with WLS 7.0 and the JNDI lookup (and everything else) works just fine for me. (I've used just about every part of Spring under WLS both inside and outside the EJB container, including AOP.) Regards, Rod |
|
From: <jue...@we...> - 2003-08-18 16:40:28
|
Lars,
What JNDI name are you using - "comp/env/cxwHibernate" as indicated in =
the exception? Shouldn't that be "java:comp/env/cxwHibernate"?
Anyway, Spring's JndiObjectFactoryBean doesn't do anything magical: By =
default, it just looks up the JNDI name, prepending "java:comp/env/" if =
not already contained in the name. The latter prepending can be turned =
off by setting the "inContainer" property to false.
Try looking up the JNDI resource manually in some servlet or JSP (via =
"new InitialContext().lookup(name)"), using the same name as specified =
for JndiObjectFactoryBean. If you can make it work there, it should work =
with JndiObjectFactoryBean too.
Juergen
-----Original Message-----
From: Lars Fischer [mailto:lar...@gm...]
Sent: Monday, August 18, 2003 5:54 PM
To: spr...@li...
Subject: [Springframework-developer] Problem with DataSource and WLS 8.1
Hi all,
I have a problem with a DataSource definition in applicationContext.xml.
I've defined a connection pool and a data source with WebLogic 8.1 but=20
at deployment time Spring says:
18.08.2003 17.42 Uhr CEST> <Warning> <HTTP> <BEA-101162> <User defined
listener com.interface21.web.context.ContextLoaderListener failed:
com.interface21.context.ApplicationContextException: Cannot load =
configuration: problem
instantiating or initializing beans; nested exception is:
com.interface21.beans.FatalBeanException: afterPropertiesSet on =
with
name 'cwxDataSource' threw an exception; nested exception is:
javax.naming.NameNotFoundException: While trying to look up
comp/env/cxwHibernate in /app/webapp/springapp/22589165.; remaining name
'comp/env/cxwHibernate'.>
This may be a WebLogic issue but I can't find any good BEA documentation =
for
this issue.
Does anyone have experience configuring WebLogic JNDI with Spring ?
Thanks
Lars
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/=
01
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Lars F. <lar...@gm...> - 2003-08-18 15:54:25
|
Hi all,
I have a problem with a DataSource definition in applicationContext.xml.
I've defined a connection pool and a data source with WebLogic 8.1 but
at deployment time Spring says:
18.08.2003 17.42 Uhr CEST> <Warning> <HTTP> <BEA-101162> <User defined
listener com.interface21.web.context.ContextLoaderListener failed:
com.interface21.context.ApplicationContextException: Cannot load configuration: problem
instantiating or initializing beans; nested exception is:
com.interface21.beans.FatalBeanException: afterPropertiesSet on with
name 'cwxDataSource' threw an exception; nested exception is:
javax.naming.NameNotFoundException: While trying to look up
comp/env/cxwHibernate in /app/webapp/springapp/22589165.; remaining name
'comp/env/cxwHibernate'.>
This may be a WebLogic issue but I can't find any good BEA documentation for
this issue.
Does anyone have experience configuring WebLogic JNDI with Spring ?
Thanks
Lars
|
|
From: <jue...@we...> - 2003-08-18 12:08:09
|
Hi Lars, Petclinic doesn't use transactions yet. Thus, it only defines a single = business/data access combo object. If you'd like to do the same for = Hibernate, simply define an object analogous to = "exampleDataAccessObject" in the webapp-hibernate skeleton. Instead of a = DataSource reference like Petclinic's "clinic", you'll need a = SessionFactory reference as you want to use Hibernate. "exampleBusinessObject" in the webapp-hibernate skeleton shows how to = define a high-level business facade that doesn't perform any data access = itself but delegates that to one or more data access objects. It is = supposed to demarcate transactions, therefore it gets a = PlatformTransactionManager reference, assumably for use with = TransactionTemplate. BTW, the webapp-aop skeleton shows an example for declarative = transaction demarcation with similar application objects. Note that = "exampleBusinessObject" does not have to care about the actual = transaction strategy or the persistence strategy of the data access = objects. It is supposed to work with the generic = PlatformTransactionManager interface and equally generic DAO interfaces. Juergen -----Original Message----- From: Lars Fischer [mailto:lar...@gm...] Sent: Monday, August 18, 2003 1:29 PM To: spr...@li... Subject: [Springframework-developer] Questions about Hibernate configuration Hi to all Spring-experts, I'm trying to write a sample app with Spring and Hibernate (two new technologies for me). To get started I'm using some of the methods from Petclinic. My question is about "appicationContext.xml" where Petclinic declares (for JDBC): <!-- petclinic primary Business Object : Default implementation --> <bean id=3D"clinic" class=3D"petclinic.jdbc.HsqlClinic"> <property name=3D"dataSource"><ref bean=3D"dataSource"/></property> </bean> --> How would you declare the same functionality when using Hibernate ? This is from the "applicationContext.xml" template for Hibernate: <bean id=3D"exampleDataAccessObject" = class=3D"example.ExampleDataAccessObject"> <property name=3D"sessionFactory"><ref = bean=3D"mySessionFactory"/></property> <property name=3D"exampleParam"><value>someValue</value></property> </bean> <bean id=3D"exampleBusinessObject" = class=3D"example.ExampleBusinessObject"> <property name=3D"transactionManager"><ref bean=3D"myTransactionManager"/></property> <property name=3D"dataAccessObject"><ref bean=3D"exampleDataAccessObject"/></property> <property = name=3D"exampleParam"><value>someOtherValue</value></property> </bean> --> Do I need both of them ? Thanks a lot for your help ! Lars ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/= 01 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Lars F. <lar...@gm...> - 2003-08-18 11:41:51
|
Hi to all Spring-experts, I'm trying to write a sample app with Spring and Hibernate (two new technologies for me). To get started I'm using some of the methods from Petclinic. My question is about "appicationContext.xml" where Petclinic declares (for JDBC): <!-- petclinic primary Business Object : Default implementation --> <bean id="clinic" class="petclinic.jdbc.HsqlClinic"> <property name="dataSource"><ref bean="dataSource"/></property> </bean> --> How would you declare the same functionality when using Hibernate ? This is from the "applicationContext.xml" template for Hibernate: <bean id="exampleDataAccessObject" class="example.ExampleDataAccessObject"> <property name="sessionFactory"><ref bean="mySessionFactory"/></property> <property name="exampleParam"><value>someValue</value></property> </bean> <bean id="exampleBusinessObject" class="example.ExampleBusinessObject"> <property name="transactionManager"><ref bean="myTransactionManager"/></property> <property name="dataAccessObject"><ref bean="exampleDataAccessObject"/></property> <property name="exampleParam"><value>someOtherValue</value></property> </bean> --> Do I need both of them ? Thanks a lot for your help ! Lars |
|
From: <tri...@tr...> - 2003-08-16 20:06:39
|
Option 2 is OK by me. I'll start working on this, and unless there is a lot of opposition, I'll committ these changes early next week. Thomas > There's a similar issue with a Hibernate Session or a JDO PersistenceManager: > Data access code is not supposed close, beginTransaction, etc on them. If we > would use respective wrappers for those too, we would have to keep those > wrappers in sync with the respective interfaces. As this strategy doesn't > even deliver obvious restrictions at development time but just at runtime, I > consider it not worth the effort. > > Thus, I'm for 2 too: Just use the original objects, dissolve > ReadOnlyResultSet, and put the restrictions in JavaDoc. Thomas, if everybody > agrees with this, can you apply these changes together with the > exception/close fixes ASAP? I'm keen on releasing 1.0 M1 in two weeks at the > latest. > > Juergen > > > > -----Ursprüngliche Nachricht----- > Von: Rod Johnson [mailto:rod...@in...] > Gesendet: Sa 16.08.2003 11:12 > An: spr...@li... > Cc: Thomas Risberg > Betreff: [Springframework-developer] JdbcTemplate > > > > All, > > A user has suggested in the forums that we should have an option where the > ResultSet isn't read only in JdbcTemplate. For example, to allow the use of > updateable result sets. > > I wanted to use an Oracle-specific method recently, so I added the > getUnderlyingResultSet() method (in 0.9.1). > > However, I think there probably is a need to address this in general. > > Some thoughts on options: > > 1. Add boolean property to JdbcTemplate controlling whether to return the > real result set. Of course this would affect all uses, not just the single > case that needed it > 2. Remove ReadOnlyResultSet and give the user a ResultSet as in the > original > version. I'm not into the idea of constraining people in general, and I > wasn't specially bothered about the possibility of the user calling "bad" > methods. Maybe we could improve the Javadoc to really make it clear which > methods are acceptable. > 3. Let more methods through in ReadOnlyResultSet. Only the navigation > methods should really be off limits. > 4. Replace ReadOnlyResultSet with an AOP-advised proxy to the real result > set, which would allow a pointcut to specify which methods are allowed and > which should through UnsupportedOperationException(). This might have a > small impact on performance, and would complicate stack traces, so although > I think it would work well I doubt it's very wise. > > I'd probably chose 2 (simplicity is good!) but let's vote on it. > > Btw I think mock object based tests should give us a good way of ensuring > that our connection, statement and result set closure is correct. I think > this is also something we need to get bulletproof before 1.0. > > I'm leaving for Colorado for an Enterprise Architecture Summit this > afternoon and will be effectively offline till Wed 27th. > > Regards, > Rod > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > N¬HS^µé[)¢{(ç[ÈZÞzÞn襴4Dì׬w%¹Ø§6i©¢»lÊ&êÜxú+µ©ljwE¢»¦±ªÞjö¢¦åzz0'¶ZÉ©Ýz{^®Ú0v§\¢µb²æ¥JÛDNm§ÿÚ²ÞµÉbrK«Ê&þ > ?¦Æ´Ó]4ÓMÚ½ïÝ·µ«Z²Þ·NößMô×ý5Jâëjg°¢¹ z÷¥¢«¨¥x%ËR¦¸§úÚì(®G^½éh¥êåËl²«qç讧zØm¶?þX¬¶Ë(º· ~àzwþX¬¶ÏåËbú?²âëjg°¢¹ z÷¥¢« |
|
From: Ken K. <kk...@kk...> - 2003-08-16 18:56:16
|
FYI, Petclinic has been added/updated to CSV for org.springframework. I have also uploaded the new javadoc and tutorial.html to the Spring website. Ken |
|
From: <jue...@we...> - 2003-08-16 16:20:30
|
VGhlcmUncyBhIHNpbWlsYXIgaXNzdWUgd2l0aCBhIEhpYmVybmF0ZSBTZXNzaW9uIG9yIGEgSkRP IFBlcnNpc3RlbmNlTWFuYWdlcjogRGF0YSBhY2Nlc3MgY29kZSBpcyBub3Qgc3VwcG9zZWQgY2xv c2UsIGJlZ2luVHJhbnNhY3Rpb24sIGV0YyBvbiB0aGVtLiBJZiB3ZSB3b3VsZCB1c2UgcmVzcGVj dGl2ZSB3cmFwcGVycyBmb3IgdGhvc2UgdG9vLCB3ZSB3b3VsZCBoYXZlIHRvIGtlZXAgdGhvc2Ug d3JhcHBlcnMgaW4gc3luYyB3aXRoIHRoZSByZXNwZWN0aXZlIGludGVyZmFjZXMuIEFzIHRoaXMg c3RyYXRlZ3kgZG9lc24ndCBldmVuIGRlbGl2ZXIgb2J2aW91cyByZXN0cmljdGlvbnMgYXQgZGV2 ZWxvcG1lbnQgdGltZSBidXQganVzdCBhdCBydW50aW1lLCBJIGNvbnNpZGVyIGl0IG5vdCB3b3J0 aCB0aGUgZWZmb3J0Lg0KIA0KVGh1cywgSSdtIGZvciAyIHRvbzogSnVzdCB1c2UgdGhlIG9yaWdp bmFsIG9iamVjdHMsIGRpc3NvbHZlIFJlYWRPbmx5UmVzdWx0U2V0LCBhbmQgcHV0IHRoZSByZXN0 cmljdGlvbnMgaW4gSmF2YURvYy4gVGhvbWFzLCBpZiBldmVyeWJvZHkgYWdyZWVzIHdpdGggdGhp cywgY2FuIHlvdSBhcHBseSB0aGVzZSBjaGFuZ2VzIHRvZ2V0aGVyIHdpdGggdGhlIGV4Y2VwdGlv bi9jbG9zZSBmaXhlcyBBU0FQPyBJJ20ga2VlbiBvbiByZWxlYXNpbmcgMS4wIE0xIGluIHR3byB3 ZWVrcyBhdCB0aGUgbGF0ZXN0Lg0KIA0KSnVlcmdlbg0KIA0KIA0KDQoJLS0tLS1VcnNwcsO8bmds aWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IFJvZCBKb2huc29uIFttYWlsdG86cm9kLmpvaG5z b25AaW50ZXJmYWNlMjEuY29tXSANCglHZXNlbmRldDogU2EgMTYuMDguMjAwMyAxMToxMiANCglB bjogc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgDQoJQ2M6 IFRob21hcyBSaXNiZXJnIA0KCUJldHJlZmY6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBK ZGJjVGVtcGxhdGUNCgkNCgkNCg0KCUFsbCwNCgkNCglBIHVzZXIgaGFzIHN1Z2dlc3RlZCBpbiB0 aGUgZm9ydW1zIHRoYXQgd2Ugc2hvdWxkIGhhdmUgYW4gb3B0aW9uIHdoZXJlIHRoZQ0KCVJlc3Vs dFNldCBpc24ndCByZWFkIG9ubHkgaW4gSmRiY1RlbXBsYXRlLiBGb3IgZXhhbXBsZSwgdG8gYWxs b3cgdGhlIHVzZSBvZg0KCXVwZGF0ZWFibGUgcmVzdWx0IHNldHMuDQoJDQoJSSB3YW50ZWQgdG8g dXNlIGFuIE9yYWNsZS1zcGVjaWZpYyBtZXRob2QgcmVjZW50bHksIHNvIEkgYWRkZWQgdGhlDQoJ Z2V0VW5kZXJseWluZ1Jlc3VsdFNldCgpIG1ldGhvZCAoaW4gMC45LjEpLg0KCQ0KCUhvd2V2ZXIs IEkgdGhpbmsgdGhlcmUgcHJvYmFibHkgaXMgYSBuZWVkIHRvIGFkZHJlc3MgdGhpcyBpbiBnZW5l cmFsLg0KCQ0KCVNvbWUgdGhvdWdodHMgb24gb3B0aW9uczoNCgkNCgkxLiBBZGQgYm9vbGVhbiBw cm9wZXJ0eSB0byBKZGJjVGVtcGxhdGUgY29udHJvbGxpbmcgd2hldGhlciB0byByZXR1cm4gdGhl DQoJcmVhbCByZXN1bHQgc2V0LiBPZiBjb3Vyc2UgdGhpcyB3b3VsZCBhZmZlY3QgYWxsIHVzZXMs IG5vdCBqdXN0IHRoZSBzaW5nbGUNCgljYXNlIHRoYXQgbmVlZGVkIGl0DQoJMi4gUmVtb3ZlIFJl YWRPbmx5UmVzdWx0U2V0IGFuZCBnaXZlIHRoZSB1c2VyIGEgUmVzdWx0U2V0IGFzIGluIHRoZSBv cmlnaW5hbA0KCXZlcnNpb24uIEknbSBub3QgaW50byB0aGUgaWRlYSBvZiBjb25zdHJhaW5pbmcg cGVvcGxlIGluIGdlbmVyYWwsIGFuZCBJDQoJd2Fzbid0IHNwZWNpYWxseSBib3RoZXJlZCBhYm91 dCB0aGUgcG9zc2liaWxpdHkgb2YgdGhlIHVzZXIgY2FsbGluZyAiYmFkIg0KCW1ldGhvZHMuIE1h eWJlIHdlIGNvdWxkIGltcHJvdmUgdGhlIEphdmFkb2MgdG8gcmVhbGx5IG1ha2UgaXQgY2xlYXIg d2hpY2gNCgltZXRob2RzIGFyZSBhY2NlcHRhYmxlLg0KCTMuIExldCBtb3JlIG1ldGhvZHMgdGhy b3VnaCBpbiBSZWFkT25seVJlc3VsdFNldC4gT25seSB0aGUgbmF2aWdhdGlvbg0KCW1ldGhvZHMg c2hvdWxkIHJlYWxseSBiZSBvZmYgbGltaXRzLg0KCTQuIFJlcGxhY2UgUmVhZE9ubHlSZXN1bHRT ZXQgd2l0aCBhbiBBT1AtYWR2aXNlZCBwcm94eSB0byB0aGUgcmVhbCByZXN1bHQNCglzZXQsIHdo aWNoIHdvdWxkIGFsbG93IGEgcG9pbnRjdXQgdG8gc3BlY2lmeSB3aGljaCBtZXRob2RzIGFyZSBh bGxvd2VkIGFuZA0KCXdoaWNoIHNob3VsZCB0aHJvdWdoIFVuc3VwcG9ydGVkT3BlcmF0aW9uRXhj ZXB0aW9uKCkuIFRoaXMgbWlnaHQgaGF2ZSBhDQoJc21hbGwgaW1wYWN0IG9uIHBlcmZvcm1hbmNl LCBhbmQgd291bGQgY29tcGxpY2F0ZSBzdGFjayB0cmFjZXMsIHNvIGFsdGhvdWdoDQoJSSB0aGlu ayBpdCB3b3VsZCB3b3JrIHdlbGwgSSBkb3VidCBpdCdzIHZlcnkgd2lzZS4NCgkNCglJJ2QgcHJv YmFibHkgY2hvc2UgMiAoc2ltcGxpY2l0eSBpcyBnb29kISkgYnV0IGxldCdzIHZvdGUgb24gaXQu DQoJDQoJQnR3IEkgdGhpbmsgbW9jayBvYmplY3QgYmFzZWQgdGVzdHMgc2hvdWxkIGdpdmUgdXMg YSBnb29kIHdheSBvZiBlbnN1cmluZw0KCXRoYXQgb3VyIGNvbm5lY3Rpb24sIHN0YXRlbWVudCBh bmQgcmVzdWx0IHNldCBjbG9zdXJlIGlzIGNvcnJlY3QuIEkgdGhpbmsNCgl0aGlzIGlzIGFsc28g c29tZXRoaW5nIHdlIG5lZWQgdG8gZ2V0IGJ1bGxldHByb29mIGJlZm9yZSAxLjAuDQoJDQoJSSdt IGxlYXZpbmcgZm9yIENvbG9yYWRvIGZvciBhbiBFbnRlcnByaXNlIEFyY2hpdGVjdHVyZSBTdW1t aXQgdGhpcw0KCWFmdGVybm9vbiBhbmQgd2lsbCBiZSBlZmZlY3RpdmVseSBvZmZsaW5lIHRpbGwg V2VkIDI3dGguDQoJDQoJUmVnYXJkcywNCglSb2QNCgkNCgkNCgkNCgkNCgktLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJVGhpcyBTRi5OZXQg ZW1haWwgc3BvbnNvcmVkIGJ5OiBGcmVlIHByZS1idWlsdCBBU1AuTkVUIHNpdGVzIGluY2x1ZGlu Zw0KCURhdGEgUmVwb3J0cywgRS1jb21tZXJjZSwgUG9ydGFscywgYW5kIEZvcnVtcyBhcmUgYXZh aWxhYmxlIG5vdy4NCglEb3dubG9hZCB0b2RheSBhbmQgZW50ZXIgdG8gd2luIGFuIFhCT1ggb3Ig VmlzdWFsIFN0dWRpbyAuTkVULg0KCWh0dHA6Ly9hc3BuZXQuY2xpY2stdXJsLmNvbS9nby9wc2Ew MDEwMDAwM2F2ZS9kaXJlY3Q7YXQuYXNwbmV0XzA3MjMwM18wMS8wMQ0KCV9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJU3ByaW5nZnJhbWV3b3JrLWRldmVs b3BlciBtYWlsaW5nIGxpc3QNCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJj ZWZvcmdlLm5ldA0KCWh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZv L3NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXINCgkNCg0K |
|
From: Rod J. <rod...@in...> - 2003-08-16 09:22:24
|
All, A user has suggested in the forums that we should have an option where the ResultSet isn't read only in JdbcTemplate. For example, to allow the use of updateable result sets. I wanted to use an Oracle-specific method recently, so I added the getUnderlyingResultSet() method (in 0.9.1). However, I think there probably is a need to address this in general. Some thoughts on options: 1. Add boolean property to JdbcTemplate controlling whether to return the real result set. Of course this would affect all uses, not just the single case that needed it 2. Remove ReadOnlyResultSet and give the user a ResultSet as in the original version. I'm not into the idea of constraining people in general, and I wasn't specially bothered about the possibility of the user calling "bad" methods. Maybe we could improve the Javadoc to really make it clear which methods are acceptable. 3. Let more methods through in ReadOnlyResultSet. Only the navigation methods should really be off limits. 4. Replace ReadOnlyResultSet with an AOP-advised proxy to the real result set, which would allow a pointcut to specify which methods are allowed and which should through UnsupportedOperationException(). This might have a small impact on performance, and would complicate stack traces, so although I think it would work well I doubt it's very wise. I'd probably chose 2 (simplicity is good!) but let's vote on it. Btw I think mock object based tests should give us a good way of ensuring that our connection, statement and result set closure is correct. I think this is also something we need to get bulletproof before 1.0. I'm leaving for Colorado for an Enterprise Architecture Summit this afternoon and will be effectively offline till Wed 27th. Regards, Rod |
|
From: Rod J. <rod...@in...> - 2003-08-15 08:08:02
|
http://www.theserverside.com/discussion/thread.jsp?thread_id=20945 |
|
From: Rod J. <rod...@in...> - 2003-08-14 23:15:12
|
Thomas and all, Thanks for your efforts resolving this. Regards, Rod ----- Original Message ----- From: <tri...@tr...> To: <jp....@ti...> Cc: <rod...@in...>; <jue...@we...>; <spr...@li...> Sent: Thursday, August 14, 2003 9:13 PM Subject: Re: [Springframework-developer] New Spring module > All, > > > Jean-Pierre, can you make the projet a Java project and > > > > I made this change, and now when I check out the project from Eclipse it builds -- > right out of the box. As long as junit.jar is in the classpath for Ant Runtime, > tests now run OK inside Eclipse as well. I guess this is thanks to the > xercesImpl.jar that JeanPierre added earlier. > > Thomas > > > |
|
From: <tri...@tr...> - 2003-08-14 21:26:10
|
All, > Jean-Pierre, can you make the projet a Java project and > I made this change, and now when I check out the project from Eclipse it builds -- right out of the box. As long as junit.jar is in the classpath for Ant Runtime, tests now run OK inside Eclipse as well. I guess this is thanks to the xercesImpl.jar that JeanPierre added earlier. Thomas |
|
From: <tri...@tr...> - 2003-08-14 17:33:40
|
Rod & All, > > Our admin rights don't give us the ability to go direct into > CVS. I suggest we create a new module, "spring" (lowercase) > or "spring1". We can then ask the SourceForge folk to > clear "Spring". > > Can you please try this, as I have no CVS access today? > There is now a 'spring' (lower case s) module that hopefully has all the files including web.tags. Jean-Pierre, can you make the projet a Java project and Juergen, can you re-check in any code you checked in earlier today? I compiled and ran all tests OK on the new module. I also removed all files from the 'Spring' module - it is now an empty shell. We should have Sourceforge remove this entire directory and also rename main to i21. Thanks to Colin and everybody else who gave us good suggestions how to resolve this problem. Thomas |
|
From: <rod...@in...> - 2003-08-14 15:53:21
|
Thomas >Windows -> Linux -> CVS import is not a good combo. >Should we try this again and do it right? Rod or Juergen, can you remove everything from the Spring folder so we can start with a fresh slate. Our admin rights don't give us the ability to go direct into CVS. I suggest we create a new module, "spring" (lowercase) or "spring1". We can then ask the SourceForge folk to clear "Spring". Can you please try this, as I have no CVS access today? Thanks Rod |
1239 messages has been excluded from this view by a project administrator.
