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: Rod J. <rod...@in...> - 2003-05-11 17:40:35
|
Guys, As you know I'm pretty big on test coverage and (ideally) test-first development. I've added a few more tests over the weekend, and I've just achieved a significant boost in coverage by writing an introspection-driven test suite that achieves 100% coverage of Tony's 2000 line ObjectArrayUtils, in little more than 100 lines of test case. I guess it goes to show that where there's a will there's a way, where testing is concerned. (There weren't any bugs in it, by the way.) This raises overall test coverage from just on 50% (after my other test additions), to 56%. Regards, Rod |
|
From: Isabelle M. <isa...@me...> - 2003-05-10 18:29:01
|
and another module called uml please Isabelle -- Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com |
|
From: Isabelle M. <isa...@me...> - 2003-05-10 18:27:35
|
Hi everyone, Could someone with the required access please create a new module, at the same level as main, called for ex. tutorial. I'm currently backing up to CD, but that's a lot of unnecessary work. And I don't want to put the tutorial stuff under main. TIA, Isabelle -- Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com |
|
From: JP P. <jp....@ti...> - 2003-05-10 16:13:30
|
Hi Isabelle, I have replaced with your fix in the three classes. I have no more time = now, but I will try to found why the original code don't ran beginning = next week. Jean-Pierre > -----Message d'origine----- > De : spr...@li... > [mailto:spr...@li...] De la = part > de Isabelle Muszynski > Envoy=C3=A9 : samedi 10 mai 2003 17:47 > =C3=80 : JP Pawlak > Cc : spr...@li... > Objet : Re: RE : [Springframework-developer] MySqlMaxValueIncrementer >=20 > Sorry, sent you the wrong piece. Here it is. >=20 > Isabelle >=20 > On Sat, May 10, 2003 at 05:14:10PM +0200, JP Pawlak wrote: > > Hi Isabelle, > > > > I don't see any difference in your snippet with the actual code. Is = this > > the right snippet? What is the bug? > > I will have to go out of home for the rest of the week-end, but I = will > > take the time for testing in real before. > > > > > > > -----Message d'origine----- > > > De=C3=82 : spr...@li... > > > [mailto:spr...@li...] De = la > > part > > > de Isabelle Muszynski > > > Envoy=C3=83=C2=A9=C3=82 : samedi 10 mai 2003 15:55 > > > =C3=83=E2=82=AC=C3=82 : JP PAWLAK(Tiscali) > > > Cc=C3=82 : spr...@li... > > > Objet=C3=82 : Re: [Springframework-developer] = MySqlMaxValueIncrementer > > > > > > Hi JP, > > > > > > I found a bug in your code for MySQLMaxValueIncrementer (assuming = that > > an > > > Integer could be cast to a long). I've got some problemes with CVS > > right > > > now, so here is my fix. > > > > > > Isabelle > > > > > > -- > > > Isabelle Muszynski > > > Software Engineer > > > Zandweellaan 4 > > > 2660 Antwerpen > > > Belgium > > > Tel. 32-(0)3-830 18 54 > > > Mobile: 32-(0)485 49 50 89 > > > Email: isa...@me... > > > Website: www.meta-logix.com > > > > > > > > > > ------------------------------------------------------- > > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa = Clara > > The only event dedicated to issues related to Linux enterprise = solutions > > www.enterpriselinuxforum.com > > > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > = https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > >=20 > -- > Isabelle Muszynski > Software Engineer > Zandweellaan 4 > 2660 Antwerpen > Belgium > Tel. 32-(0)3-830 18 54 > Mobile: 32-(0)485 49 50 89 > Email: isa...@me... > Website: www.meta-logix.com |
|
From: <jue...@we...> - 2003-05-10 16:11:19
|
RG1pdHJpeSwgUm9kLA0KIA0KVGhlcmUgd2VyZSBzaWduaWZpY2FudCAyIGNoYW5nZXM6DQoxLiBJ bnRyb2R1Y2luZyBUcmFuc2FjdGlvbkRlZmluaXRpb24gdG8gcmVwbGFjZSBQbGF0Zm9ybVRyYW5z YWN0aW9uTWFuYWdlcidzIGdldFRyYW5zYWN0aW9uKGludCxpbnQpIHdpdGggZ2V0VHJhbnNhY3Rp b24oVHJhbnNhY3Rpb25EZWZpbml0aW9uKSwgYW5kIG1ha2luZyBib3RoIFRyYW5zYWN0aW9uVGVt cGxhdGUgYW5kIFRyYW5zYWN0aW9uQXR0cmlidXRlIGltcGxlbWVudCByZXNwLiBleHRlbmQgaXQu DQoyLiBJbnRyb2R1Y2luZyBzdXBwb3J0IGZvciB0cmFuc2FjdGlvbiB0aW1lb3V0cywgdmlhIGEg ZnVydGhlciBwcm9wZXJ0eSBvZiBUcmFuc2FjdGlvbkRlZmluaXRpb24uDQogDQpUaGUgbGF0dGVy IGlzIHByb2JhYmx5IHRoZSBjYXVzZSBmb3IgeW91ciBwcm9ibGVtOiBUSU1FT1VUX0RFRkFVTFQg aXMgLTEsIG1lYW5pbmcgbm8gdGltZW91dCBhdCBhbGwuIERhdGFTb3VyY2VUcmFuc2FjdGlvbk1h bmFnZXIgYW5kIEhpYmVybmF0ZVRyYW5zYWN0aW9uTWFuYWdlciBvbmx5IGFjY2VwdCB0aGlzIHZh bHVlLCBhcyB0aGV5IGRvbid0IHN1cHBvcnQgY3VzdG9tIHRpbWVvdXRzLg0KIA0KSnRhVHJhbnNh Y3Rpb25NYW5hZ2VyIGRlbGVnYXRlcyB0byB0aGUgSnRhU2VydmljZXMuYmVnaW4gdmVyc2lvbiB3 aXRoIHRpbWVvdXQgcGFyYW1ldGVyLCBidXQgdGhpcyBtZXRob2QgaGFzIGEgYnJva2VuIGRlZmF1 bHQgY2hlY2s6IEl0IHNldHMgYW55IG90aGVyIHZhbHVlIHRoYW4gMCB0byB0aGUgVXNlclRyYW5z YWN0aW9uLCBidXQgaXQgc2hvdWxkIG9ubHkgc2V0IGFsbCB2YWx1ZXMgPj0wLiBUaGlzIGNhbiBj YXVzZSB0aGUgYWN0dWFsIEpUQSBpbXBsZW1lbnRhdGlvbiB0byBzaG93IHVucHJlZGljdGFibGUg YmVoYXZpb3I6IFNvbWUgaWdub3JlIHN1Y2ggdmFsdWVzIChsaWtlIFR5cmV4KSwgb3IgaW4gZmFj dCBhbnkgdGltZW91dCB2YWx1ZXMgKGxpa2UgUmVzaW4pLCBidXQgc29tZSBvYnZpb3VzbHkgdHJl YXQgaXQgYXMgImV4cGlyZSBpbW1lZGlhdGVseSIgKGxpa2UgSkJvc3MpIC0gc2V0dGluZyB0aGUg dHJhbnNhY3Rpb24gcm9sbGJhY2stb25seSByaWdodCBhdCB0aGUgYmVnaW5uaW5nLg0KIA0KVGh1 cywgZml4aW5nIEp0YVNlcnZpY2VzIGFwcHJvcHJpYXRlbHkgc2hvdWxkIHNvbHZlIHRoZSBpc3N1 ZSAtIEknbGwgY2hlY2sgdGhpcyBvbiBNb25kYXkuIEluIHRoZSBtZWFudGltZSwgc2V0dGluZyB0 aGUgInRpbWVvdXQiIHByb3BlcnR5IG9uIFRyYW5zYWN0aW9uRGVmaW5pdGlvbiByZXNwLiBUcmFu c2FjdGlvblRlbXBsYXRlIHJlc3AuIFRyYW5zYWN0aW9uQXR0cmlidXRlIHNob3VsZCBoZWxwLCBz cGVjaWZ5aW5nICIwIiBmb3IgdGhlIEpUQSBkZWZhdWx0IHZhbHVlLCBvciBhbnkgbnVtYmVyIG9m IHNlY29uZHMuDQogDQpSZWdhcmRzLA0KSnVlcmdlbg0KIA0KUC5TLg0KQXMgdGhlIGFjdHVhbCBi ZWhhdmlvciBkZXBlbmRzIG9uIHRoZSBKVEEgaW1wbGVtZW50YXRpb24sIHVuaXQtdGVzdGluZyB3 aWxsIG9ubHkgYmUgYWJsZSB0byBjb3ZlciBtb3N0IGlzc3Vlcy4gT24gdGhlIG90aGVyIGhhbmQs IHRoZXJlIGlzbid0IGFueSBKdGFTZXJ2aWNlcyByZXNwLiBKdGFUcmFuc2FjdGlvbk1hbmFnZXIg dW5pdCB0ZXN0IHlldC4gT24gdGhlIG9jY2FzaW9uLCBJIHdpbGwgd3JpdGUgYXBwcm9wcmlhdGUg dW5pdCB0ZXN0cywgdXNpbmcgYSBtb2NrIEpOREkgZW52aXJvbm1lbnQgdG8gcHJvdmlkZSBhIG1v Y2sgVXNlclRyYW5zYWN0aW9uIGluc3RhbmNlLiBJJ2xsIHRyeSB0byBtYWtlIHRoaXMgdHJhbnNh Y3Rpb24gb2JqZWN0IHN0cmljdGx5IGJlaGF2ZSBhY2NvcmRpbmcgdG8gdGhlIEpUQSBzcGVjaWZp Y2F0aW9uLg0KIA0KIA0KDQoJLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLSANCglW b246IEtvcHlsZW5rbywgRG1pdHJ5IFttYWlsdG86ZGtvcHlsZW5rb0BhY3MucnV0Z2Vycy5lZHVd IA0KCUdlc2VuZGV0OiBGciAwOS4wNS4yMDAzIDE2OjU4IA0KCUFuOiAnc3ByaW5nLWRldi1saXN0 JyANCglDYzogDQoJQmV0cmVmZjogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIFRyYW5zYWN0 aW9uIGluZnJhc3RydWN0dXJlIGRvZXMgbm90IHdvcmshISENCgkNCgkNCg0KCUp1ZXJnZW4sIFJv ZCwNCgkNCglhZnRlciBnZXR0aW5nIHRoZSBsYXRlc3Qgc291cmNlcyB0aGlzIG1vcm5pbmcgYW5k IHRyeWluZyBpdCBvdXQsIHRoZQ0KCXRyYW5zYWN0aW9uIGluZnJhc3RydWN0dXJlIGRvZXMgbm90 IHdvcmsgYW55bW9yZS4gSXQgdGhyb3dzIGFuIGV4Y2VwdGlvbg0KCXdoZW5ldmVyIHRoZSBjb2Rl IHRyaWVzIHRvIHVzZSB0aGUgdHJhbnNhY3Rpb24gKHVzaW5nDQoJVHJhbnNhY3Rpb25JbnRlcmNl cHRvcikuIFRoZSBzYW1lIGNvZGUgd29ya3MgcGVyZmVjdGx5IHdpdGggdGhlIHByZXZpb3VzDQoJ dmVyc2lvbiBvZiBTcHJpbmcncyBjb2RlLiBKdWVyZ2VuLCBJJ3ZlIG5vdGljZWQgdGhhdCB5b3Un dmUgZG9uZSBzb21lDQoJcmVmYWN0b3JpbmdzIGluIHRoZSB0cmFuc2FjdGlvbiBwYWNrYWdlcyBh bmQgYWxzbyB5b3UndmUgY2hhbmdlZCB0aGUNCglUcmFuc2FjdGlvbkludGVyY2VwdG9yLiBDb3Vs ZCB5b3UgcGxlYXNlIHRlbGwgbWUgd2hhdCBtaWdodCBiZSBjYXVzaW5nIHRoZQ0KCXByb2JsZW0u IEhlcmUgaXMgdGhlIHBhcnRpYWwgc3RhY2sgdHJhY2U6DQoJDQoJMjAwMy0wNS0wOSAxMDo0NToz NCw2NTggSU5GTyAgW1RyYW5zYWN0aW9uSW50ZXJjZXB0b3JdIENyZWF0aW5nIHRyYW5zYWN0aW9u DQoJZm9yIG1ldGhvZCAnYWRkUHJvZ3JhbUlucXVpcnknDQoJMjAwMy0wNS0wOSAxMDo0NTozNCw3 MzggRVJST1IgW1RyYW5zYWN0aW9uSW50ZXJjZXB0b3JdIFJPTExJTkcgQkFDSw0KCXRyYW5zYWN0 aW9uIG9uIG1ldGhvZCAnYWRkUHJvZ3JhbUlucXVpcnknIGR1ZSB0byB0aHJvd2FibGU6IERhdGFT b3VyY2UNCglvcmcuamJvc3MucmVzb3VyY2UuYWRhcHRlci5qZGJjLldyYXBwZXJEYXRhU291cmNl QDYzM2Q1MTsgbmVzdGVkIGV4Y2VwdGlvbg0KCWlzOg0KCSAgICAgICAgb3JnLmpib3NzLnV0aWwu TmVzdGVkU1FMRXhjZXB0aW9uOiBDb3VsZCBub3QgZW5saXN0IGluIHRyYW5zYWN0aW9uDQoJb24g ZW50ZXJpbmcgbWV0YS1hd2FyZSBvYmplY3QhamF2YXgudHJhbnNhY3Rpb24uU3lzdGVtRXhjZXB0 aW9uOiBDb3VsZCBub3QNCglyZWdpc3RlciBzeW5jaHJvbml6YXRpb24gd2l0aCB0eDogamF2YXgu dHJhbnNhY3Rpb24uUm9sbGJhY2tFeGNlcHRpb246DQoJQWxyZWFkeSBtYXJrZWQgZm9yIHJvbGxi YWNrOyAtIG5lc3RlZCB0aHJvd2FibGU6DQoJKGphdmF4LnJlc291cmNlLlJlc291cmNlRXhjZXB0 aW9uOiBDb3VsZCBub3QgZW5saXN0IGluIHRyYW5zYWN0aW9uIG9uDQoJZW50ZXJpbmcgbWV0YS1h d2FyZSBvYmplY3QhamF2YXgudHJhbnNhY3Rpb24uU3lzdGVtRXhjZXB0aW9uOiBDb3VsZCBub3QN CglyZWdpc3RlciBzeW5jaHJvbml6YXRpb24gd2l0aCB0eDogamF2YXgudHJhbnNhY3Rpb24uUm9s bGJhY2tFeGNlcHRpb246DQoJQWxyZWFkeSBtYXJrZWQgZm9yIHJvbGxiYWNrKQ0KCTIwMDMtMDUt MDkgMTA6NDU6MzQsNzM4IEVSUk9SIFtDb250cm9sbGVyU2VydmxldF0gVW5leHBlY3RlZCBydW50 aW1lDQoJZXhjZXB0aW9uDQoJY29tLmludGVyZmFjZTIxLmpkYmMuZGF0YXNvdXJjZS5DYW5ub3RH ZXRKZGJjQ29ubmVjdGlvbkV4Y2VwdGlvbjogRGF0YVNvdXJjZQ0KCW9yZy5qYm9zcy5yZXNvdXJj ZS5hZGFwdGVyLmpkYmMuV3JhcHBlckRhdGFTb3VyY2VANjMzZDUxOyBuZXN0ZWQgZXhjZXB0aW9u DQoJaXM6DQoJICAgICAgICBvcmcuamJvc3MudXRpbC5OZXN0ZWRTUUxFeGNlcHRpb246IENvdWxk IG5vdCBlbmxpc3QgaW4gdHJhbnNhY3Rpb24NCglvbiBlbnRlcmluZyBtZXRhLWF3YXJlIG9iamVj dCFqYXZheC50cmFuc2FjdGlvbi5TeXN0ZW1FeGNlcHRpb246IENvdWxkIG5vdA0KCXJlZ2lzdGVy IHN5bmNocm9uaXphdGlvbiB3aXRoIHR4OiBqYXZheC50cmFuc2FjdGlvbi5Sb2xsYmFja0V4Y2Vw dGlvbjoNCglBbHJlYWR5IG1hcmtlZCBmb3Igcm9sbGJhY2s7IC0gbmVzdGVkIHRocm93YWJsZToN CgkoamF2YXgucmVzb3VyY2UuUmVzb3VyY2VFeGNlcHRpb246IENvdWxkIG5vdCBlbmxpc3QgaW4g dHJhbnNhY3Rpb24gb24NCgllbnRlcmluZyBtZXRhLWF3YXJlIG9iamVjdCFqYXZheC50cmFuc2Fj dGlvbi5TeXN0ZW1FeGNlcHRpb246IENvdWxkIG5vdA0KCXJlZ2lzdGVyIHN5bmNocm9uaXphdGlv biB3aXRoIHR4OiBqYXZheC50cmFuc2FjdGlvbi5Sb2xsYmFja0V4Y2VwdGlvbjoNCglBbHJlYWR5 IG1hcmtlZCBmb3Igcm9sbGJhY2spDQoJb3JnLmpib3NzLnV0aWwuTmVzdGVkU1FMRXhjZXB0aW9u OiBDb3VsZCBub3QgZW5saXN0IGluIHRyYW5zYWN0aW9uIG9uDQoJZW50ZXJpbmcgbWV0YS1hd2Fy ZSBvYmplY3QhamF2YXgudHJhbnNhY3Rpb24uU3lzdGVtRXhjZXB0aW9uOiBDb3VsZCBub3QNCgly ZWdpc3RlciBzeW5jaHJvbml6YXRpb24gd2l0aCB0eDogamF2YXgudHJhbnNhY3Rpb24uUm9sbGJh Y2tFeGNlcHRpb246DQoJQWxyZWFkeSBtYXJrZWQgZm9yIHJvbGxiYWNrOyAtIG5lc3RlZCB0aHJv d2FibGU6DQoJKGphdmF4LnJlc291cmNlLlJlc291cmNlRXhjZXB0aW9uOiBDb3VsZCBub3QgZW5s aXN0IGluIHRyYW5zYWN0aW9uIG9uDQoJZW50ZXJpbmcgbWV0YS1hd2FyZSBvYmplY3QhamF2YXgu dHJhbnNhY3Rpb24uU3lzdGVtRXhjZXB0aW9uOiBDb3VsZCBub3QNCglyZWdpc3RlciBzeW5jaHJv bml6YXRpb24gd2l0aCB0eDogamF2YXgudHJhbnNhY3Rpb24uUm9sbGJhY2tFeGNlcHRpb246DQoJ QWxyZWFkeSBtYXJrZWQgZm9yIHJvbGxiYWNrKQ0KCSAgICAgICAgYXQNCglvcmcuamJvc3MucmVz b3VyY2UuYWRhcHRlci5qZGJjLldyYXBwZXJEYXRhU291cmNlLmdldENvbm5lY3Rpb24oV3JhcHBl ckRhdGFTDQoJb3VyY2UuamF2YToxMDYpDQoJICAgICAgICBhdA0KCWNvbS5pbnRlcmZhY2UyMS5q ZGJjLmRhdGFzb3VyY2UuRGF0YVNvdXJjZVV0aWxzLmdldENvbm5lY3Rpb24oRGF0YVNvdXJjZVV0 aWwNCglzLmphdmE6OTgpDQoJICAgICAgICBhdA0KCWNvbS5pbnRlcmZhY2UyMS5qZGJjLmNvcmUu U1FMRXhjZXB0aW9uVHJhbnNsYXRlckZhY3RvcnkuZ2V0RGVmYXVsdFRyYW5zbGF0ZXINCgkoU1FM RXhjZXB0aW9uVHJhbnNsYXRlckZhY3RvcnkuamF2YToxMDkpDQoJICAgICAgICBhdA0KCWNvbS5p bnRlcmZhY2UyMS5qZGJjLmNvcmUuSmRiY1RlbXBsYXRlLnNldERhdGFTb3VyY2UoSmRiY1RlbXBs YXRlLmphdmE6MTUzKQ0KCSAgICAgICAgYXQNCgljb20uaW50ZXJmYWNlMjEuamRiYy5jb3JlLkpk YmNUZW1wbGF0ZS48aW5pdD4oSmRiY1RlbXBsYXRlLmphdmE6MTI3KQ0KCSAgICAgICAgYXQNCglj b20uaW50ZXJmYWNlMjEuamRiYy5vYmplY3QuU3FsT3BlcmF0aW9uLmNvbXBpbGVJbnRlcm5hbChT cWxPcGVyYXRpb24uamF2YTo3DQoJOSkNCgkgICAgICAgIGF0DQoJY29tLmludGVyZmFjZTIxLmpk YmMub2JqZWN0LlJkYm1zT3BlcmF0aW9uLmNvbXBpbGUoUmRibXNPcGVyYXRpb24uamF2YToyMDgp DQoJLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLg0KCS4uLi4uLi4uLi4uDQoJDQoJVGhhbmtzLA0KCURtaXRy aXkuDQoJDQoJDQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KCUVudGVycHJpc2UgTGludXggRm9ydW0gQ29uZmVyZW5jZSAmIEV4cG8sIEp1 bmUgNC02LCAyMDAzLCBTYW50YSBDbGFyYQ0KCVRoZSBvbmx5IGV2ZW50IGRlZGljYXRlZCB0byBp c3N1ZXMgcmVsYXRlZCB0byBMaW51eCBlbnRlcnByaXNlIHNvbHV0aW9ucw0KCXd3dy5lbnRlcnBy aXNlbGludXhmb3J1bS5jb20NCgkNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KCVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQoJ U3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCglodHRwczov L2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2 ZWxvcGVyDQoJDQoNCg== |
|
From: Isabelle M. <isa...@me...> - 2003-05-10 15:47:12
|
Sorry, sent you the wrong piece. Here it is. Isabelle On Sat, May 10, 2003 at 05:14:10PM +0200, JP Pawlak wrote: > Hi Isabelle, > > I don't see any difference in your snippet with the actual code. Is this > the right snippet? What is the bug? > I will have to go out of home for the rest of the week-end, but I will > take the time for testing in real before. > > > > -----Message d'origine----- > > De : spr...@li... > > [mailto:spr...@li...] De la > part > > de Isabelle Muszynski > > Envoyé : samedi 10 mai 2003 15:55 > > à: JP PAWLAK(Tiscali) > > Cc : spr...@li... > > Objet : Re: [Springframework-developer] MySqlMaxValueIncrementer > > > > Hi JP, > > > > I found a bug in your code for MySQLMaxValueIncrementer (assuming that > an > > Integer could be cast to a long). I've got some problemes with CVS > right > > now, so here is my fix. > > > > Isabelle > > > > -- > > Isabelle Muszynski > > Software Engineer > > Zandweellaan 4 > > 2660 Antwerpen > > Belgium > > Tel. 32-(0)3-830 18 54 > > Mobile: 32-(0)485 49 50 89 > > Email: isa...@me... > > Website: www.meta-logix.com > > > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com > > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > -- Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com |
|
From: JP P. <jp....@ti...> - 2003-05-10 15:13:56
|
Hi Isabelle, I don't see any difference in your snippet with the actual code. Is this the right snippet? What is the bug?=20 I will have to go out of home for the rest of the week-end, but I will take the time for testing in real before. > -----Message d'origine----- > De=A0: spr...@li... > [mailto:spr...@li...] De la part > de Isabelle Muszynski > Envoy=E9=A0: samedi 10 mai 2003 15:55 > =C0=A0: JP PAWLAK(Tiscali) > Cc=A0: spr...@li... > Objet=A0: Re: [Springframework-developer] MySqlMaxValueIncrementer >=20 > Hi JP, >=20 > I found a bug in your code for MySQLMaxValueIncrementer (assuming that an > Integer could be cast to a long). I've got some problemes with CVS right > now, so here is my fix. >=20 > Isabelle >=20 > -- > Isabelle Muszynski > Software Engineer > Zandweellaan 4 > 2660 Antwerpen > Belgium > Tel. 32-(0)3-830 18 54 > Mobile: 32-(0)485 49 50 89 > Email: isa...@me... > Website: www.meta-logix.com |
|
From: Isabelle M. <isa...@me...> - 2003-05-10 13:55:25
|
Hi JP, I found a bug in your code for MySQLMaxValueIncrementer (assuming that an Integer could be cast to a long). I've got some problemes with CVS right now, so here is my fix. Isabelle -- Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com |
|
From: Isabelle M. <isa...@me...> - 2003-05-10 10:53:20
|
Hello Jean-Pierre, All you need to run the livetests are a MySql database named test with user test, password test. Isabelle On Sat, May 10, 2003 at 12:48:24PM +0200, JP PAWLAK(Tiscali) wrote: > Hello Isabelle, > > Now the javadoc is in order. It was mainly a matter of cutting/pasting > via a simple editor (notepad) to ensure that no character set nor > special characters were used. > > Can you explain the best way to run the livetests, please? > > Best regards, > > ---------------------------- > Jean-Pierre Pawlak > jp....@ti... > > > > > -- Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com |
|
From: Rod J. <rod...@in...> - 2003-05-10 10:52:31
|
I would prefer that livetests ran on HSQL than MySQL if possible. Ideally I would prefer that we could do this with mock objects (no livetests), but I know there were time constraints for Isabelle, who is taking a lot of work on. I might possibly have time to look at modifying the JdbcTemplate test suite to use mock objects to test the new insertion functionality this weekend. Regards, Rod ----- Original Message ----- From: "JP PAWLAK(Tiscali)" <jp....@ti...> To: "Isabelle Muszynski" <isa...@me...> Cc: "Spring Developers" <spr...@li...> Sent: Saturday, May 10, 2003 11:48 AM Subject: [Springframework-developer] javadoc and livetests Hello Isabelle, Now the javadoc is in order. It was mainly a matter of cutting/pasting via a simple editor (notepad) to ensure that no character set nor special characters were used. Can you explain the best way to run the livetests, please? Best regards, ---------------------------- Jean-Pierre Pawlak jp....@ti... ------------------------------------------------------- Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara The only event dedicated to issues related to Linux enterprise solutions www.enterpriselinuxforum.com _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: JP PAWLAK\(Tiscali\) <jp....@ti...> - 2003-05-10 10:48:05
|
Hello Isabelle, Now the javadoc is in order. It was mainly a matter of cutting/pasting via a simple editor (notepad) to ensure that no character set nor special characters were used. Can you explain the best way to run the livetests, please? Best regards, ---------------------------- Jean-Pierre Pawlak jp....@ti... =A0 |
|
From: Isabelle M. <isa...@me...> - 2003-05-10 09:14:32
|
Hmm. on my system it's even worse, Javadoc stops with a fatal error (Red Hat 9 and SDK 1.4.1_02) Isabelle On Sat, May 10, 2003 at 09:10:16AM +0200, JP PAWLAK(Tiscali) wrote: > Hello, > > A little devil seems trouble the javadoc generation on the class level > doc of the MySql, Oracle and Rdbms MaxValueIncrementers classes. > I dont understand why here the lines are simply copied without the > CR/LF in the javadoc and dont treated really. The most effect is the > including of the line beginning stars in the javadoc. > If anyone knows better what can trouble javadoc > > Regards > > --------------------------------------------- > Jean-Pierre Pawlak > jp....@ti... > > > > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com > > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > -- Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com |
|
From: JP PAWLAK\(Tiscali\) <jp....@ti...> - 2003-05-10 07:09:58
|
Hello, A little devil seems trouble the javadoc generation on the class level doc of the MySql, Oracle and Rdbms MaxValueIncrementers classes. I don=92t understand why here the lines are simply copied without the CR/LF in the javadoc and don=92t treated really. The most effect is the including of the line beginning stars in the javadoc. If anyone knows better what can trouble javadoc=85 Regards ---------------------------------------------=20 Jean-Pierre Pawlak jp....@ti... =A0 |
|
From: JP PAWLAK\(Tiscali\) <jp....@ti...> - 2003-05-09 22:39:23
|
Hi everybody, The excel view and its library are added. The SqlFunction handled yet also longs. The DataFieldMaxValueIncrementer and its implementations are reworked to handle long returns and picking keys by bunches. For now, don't use the Oracle implementation with an INCREMENT_BY value greater than one unless you have asked manually a nextval on the sequence. I will fix this beginning next week. To J=FCergen: I have seen that you updated recently the MaxValueIncrementers but I don't seen what change you made apart inserting a blank line between each line. As these classes had to be remodelled, I didn't take care of the existing classes. Tell me about if I squeezed change. Regards ---------------------------------=A0 Jean-Pierre Pawlak jp....@ti... =A0 |
|
From: JP PAWLAK\(Tiscali\) <jp....@ti...> - 2003-05-09 18:45:08
|
Hello everybody, As I have not for now the commit access (Normally it will come soon), I send the source of the AbstractExcelView. It has to be in a new package "com.interface21.web.servlet.view.excel". In addition "jakarta-poi-1.10.0-dev-20030222.jar" has to be picked up from Jakarta site and put in "lib/poi" for compilation and in the "WEB-INF/lib" of the application for running. The view definition has only one optional parameter: the url of an existing Excel document without the extension. Without this parameter, a from scratch document is provided. In addition, it can append a localisation like properties on the document name provided. The ".xls" extension must be mapped to the Spring servlet in web.xml. An example is provided in the source, the best is to generate the javadoc after integrating it. Regards --------------------------------=A0 Jean-Pierre Pawlak jp....@ti... =A0 |
|
From: Kopylenko, D. <dko...@ac...> - 2003-05-09 14:58:20
|
Juergen, Rod, after getting the latest sources this morning and trying it out, the transaction infrastructure does not work anymore. It throws an exception whenever the code tries to use the transaction (using TransactionInterceptor). The same code works perfectly with the previous version of Spring's code. Juergen, I've noticed that you've done some refactorings in the transaction packages and also you've changed the TransactionInterceptor. Could you please tell me what might be causing the problem. Here is the partial stack trace: 2003-05-09 10:45:34,658 INFO [TransactionInterceptor] Creating transaction for method 'addProgramInquiry' 2003-05-09 10:45:34,738 ERROR [TransactionInterceptor] ROLLING BACK transaction on method 'addProgramInquiry' due to throwable: DataSource org.jboss.resource.adapter.jdbc.WrapperDataSource@633d51; nested exception is: org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!javax.transaction.SystemException: Could not register synchronization with tx: javax.transaction.RollbackException: Already marked for rollback; - nested throwable: (javax.resource.ResourceException: Could not enlist in transaction on entering meta-aware object!javax.transaction.SystemException: Could not register synchronization with tx: javax.transaction.RollbackException: Already marked for rollback) 2003-05-09 10:45:34,738 ERROR [ControllerServlet] Unexpected runtime exception com.interface21.jdbc.datasource.CannotGetJdbcConnectionException: DataSource org.jboss.resource.adapter.jdbc.WrapperDataSource@633d51; nested exception is: org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!javax.transaction.SystemException: Could not register synchronization with tx: javax.transaction.RollbackException: Already marked for rollback; - nested throwable: (javax.resource.ResourceException: Could not enlist in transaction on entering meta-aware object!javax.transaction.SystemException: Could not register synchronization with tx: javax.transaction.RollbackException: Already marked for rollback) org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!javax.transaction.SystemException: Could not register synchronization with tx: javax.transaction.RollbackException: Already marked for rollback; - nested throwable: (javax.resource.ResourceException: Could not enlist in transaction on entering meta-aware object!javax.transaction.SystemException: Could not register synchronization with tx: javax.transaction.RollbackException: Already marked for rollback) at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataS ource.java:106) at com.interface21.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtil s.java:98) at com.interface21.jdbc.core.SQLExceptionTranslaterFactory.getDefaultTranslater (SQLExceptionTranslaterFactory.java:109) at com.interface21.jdbc.core.JdbcTemplate.setDataSource(JdbcTemplate.java:153) at com.interface21.jdbc.core.JdbcTemplate.<init>(JdbcTemplate.java:127) at com.interface21.jdbc.object.SqlOperation.compileInternal(SqlOperation.java:7 9) at com.interface21.jdbc.object.RdbmsOperation.compile(RdbmsOperation.java:208) ............................................................................ ........... Thanks, Dmitriy. |
|
From: Travis C. <tra...@le...> - 2003-05-09 14:55:51
|
Is there anyway to change the console logging level without have to = rebuild the entire core package. I want to use Spring but can not get = the CVS port opened up here at work so I have to use the original = framework from the book. Once there is a release I could use Spring. thanks, *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~ Travis L. Chase Microsoft Certified Solutions Developer (MCSD) Senior Programmer Analyst Leggett & Platt, Inc. tra...@le... 417-358-8131 ext.3865 ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* "A dead thing can go with the stream, but only a living=20 thing can go against it." - G. K. Chesterton "Impartiality is a pompous name for indifference, which=20 is an elegant name for ignorance." - G. K. Chesterton =20 |
|
From: JP PAWLAK\(Tiscali\) <jp....@ti...> - 2003-05-09 08:24:43
|
Hello everybody, As in my last message, it was not clear that I have added comments inside Rod's part, I send it again, but without olds included messages. Regards, Jean-Pierre Pawlak When we will reach the 0.8 stage, will be it from interest to contact sites like http://www.waferproject.org to be registered? =20 > -----Message d'origine----- > De=A0: spr...@li... > [mailto:spr...@li...] De la part > de Rod Johnson > Envoy=E9=A0: jeudi 8 mai 2003 09:40 > =C0=A0: j=FCrgen h=F6ller [werk3AT]; Spring Developers (E-mail) > Objet=A0: Re: [Springframework-developer] View technologies >=20 > I'll put iText back. >=20 ------------------------------------------------------ > JP, do you want to contribute POI view? As you've been interested/involved > in this project since before we went to SourceForge, I'm happy to give you > commit access if you are likely to make ongoing contributions. (JPP)=20 Yes, I will be happy also. I'm not focusing on a particular part of the framework, but writing what I need for my applications and not being currently available. Just tell me about the commit policy for the changes, will I have to ask someone before committing changes? Concerning the POI view, I will clean the documentation and have some minor changes to make in order to use the Spring localisation. I have forgotten to say that the Excel template can be a set of localised templates. I have also in the pocket a useful helper for paged tabular data. It is not an all cases wizard, but for not huge collections it is very useful. Letting the class in the user session and putting it in the view model, it provides the possibility of page changes, sorting, filtering and providing all information like number of pages/records, current page and so on. It is not bound to a particular view technology or framework (could so good be used in Struts). It can be a general use as it uses a callback method for retrieving the data to populate when necessary the collection to display. Therefore, it need to be maintained (ie in the user session) and contains the whole collection to display, not only the data to display on the current page. ----------------------------------------------------- >=20 > I would really like to have some form of XML/XSLT support, so I might > refactor the old one to remove the present conversion library and leave it > an abstract class. The developer would need to subclass it to generate the > actual XML from the model, using Castor or whatever. Does this sound > reasonable? (JPP) Living without XML will be difficult. Your proposal seems to be clean. But another point to this: for an effective use, it is useful to chain two XSLT transformations. The first having to create a cohesive XML from the template and the view model, the second for making the rendering. I dream also of a bridge to Cocoon. |
|
From: Rod J. <rod...@in...> - 2003-05-09 02:02:17
|
I've added an abstract XSLT view. Mostly the same code as before, but now an abstract class deferring the creation of the XML DOM node to subclasses. So no dependency on domify...users can choose to use Castor/whatever. I've restored iText PDF. I've also added a simple JdbcBeanFactory in beans.factory.support, for those who, like my workmates, are keen to store their config in the database. Regards, Rod ----- Original Message ----- From: "JP PAWLAK(Tiscali)" <jp....@ti...> To: "Spring Developers (E-mail)" <spr...@li...> Sent: Thursday, May 08, 2003 12:57 AM Subject: [Springframework-developer] View technologies Hello, I have noticed that only JSP and velocity are for now available on the Spring framework, as in Rod's book a larger tour was made. I have used for special uses a few of these with the original i21 framework. - XML/XSLT: this one was not really a requested feature. The cyclic java architecture, even in core objects, was really a problem (example: a Locale has a defaultLocale property which is itself a Locale.). This problem was noticed by Rod, but worked not as good as expected, the source of the patched jar being not available and the original library didn't be aware of this problem. My feel is that in real world a product like Castor will certainly be better, even if it's more complex at the beginning. - XMLC: I had no reason for testing it and don't like too much the approach. -PDF-iText: I had to render queries results in PDF format for friendly printing and emailing the results as one clean document. I had no time to search on others ways like FOP having in a sense a more attractive approach. But iText was simple to learn and the result is good. The only drawback is the servlet-style writing hand-coded presentation. -Excel-POI: It was not in Rod's book, but always the same data had to be reworked by users, so an Excel document was a good choice. Having the velocity and iText views source, it was simple to write an ExcelView class using Jakarta's POI. This class loads an Excel template (it can also generate a blank document), completes it before serving. Also a nice result. The same drawback as for iText can be addressed. I am aware that using iText or POI links to their code the specialized View class and launches once more the discussion about the external libraries, but, at least marginally, it's useful. My question in this context is: is the re-introducing of alternative views planned or will we consider this has to rest a user development? Regards, Jean-Pierre Pawlak jp....@ti... ------------------------------------------------------- Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara The only event dedicated to issues related to Linux enterprise solutions www.enterpriselinuxforum.com _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2003-05-08 19:01:22
|
I've recently discovered something in jboss-service.xml:
<!-- Preload all custom editors for VMs that don't use the thread
context class loader when searching for PropertyEditors. =
Uncomment
if your JDK 1.3.0 VM fails to find JBoss PropertyEditors.
<mbean code=3D"org.jboss.varia.property.PropertyEditorManagerService"
name=3D"jboss:type=3DService,name=3DBootstrapEditors">
<attribute name=3D"BootstrapEditors">
=
java.math.BigDecimal=3Dorg.jboss.util.propertyeditor.BigDecimalEditor
java.lang.Boolean=3Dorg.jboss.util.propertyeditor.BooleanEditor
java.lang.Class=3Dorg.jboss.util.propertyeditor.ClassEditor
java.util.Date=3Dorg.jboss.util.propertyeditor.DateEditor
java.io.File=3Dorg.jboss.util.propertyeditor.FileEditor
=
java.net.InetAddress=3Dorg.jboss.util.propertyeditor.InetAddressEditor
java.lang.Integer=3Dorg.jboss.util.propertyeditor.IntegerEditor
=
javax.management.ObjectName=3Dorg.jboss.util.propertyeditor.ObjectNameEdi=
tor
=
java.util.Properties=3Dorg.jboss.util.propertyeditor.PropertiesEditor
=
[Ljava.lang.String;=3Dorg.jboss.util.propertyeditor.StringArrayEditor
java.net.URL=3Dorg.jboss.util.propertyeditor.URLEditor
</attribute>
</mbean>
-->
Looks like certain VMs don't use the thread context call loader for =
PropertyEditor lookup, and thus can't find our Spring ones. We should =
probably register our default ones explicitly instead of relying on the =
package-level lookup, to avoid any standard issues on such VMs.
Juergen
-----Original Message-----
From: Bruno THOMAS [mailto:bt...@al...]
Sent: Thursday, April 10, 2003 4:35 PM
To: sri...@co...
Cc: j=FCrgen h=F6ller [werk3AT]
Subject: Re: [Springframework-developer] Properties editor in
BeanWrapperImpl
Hello=20
> This problem might occur depending on the security policy setting on =
the
> JVM on which your app server is running. If you making the =
appropriate
> JVM setting this problem will be solved.
> Hope this helps
Thanks a lot for your answers. I don't want to waste you time, But I =
really=20
don't have a clue about the PropertiesEditor...
I've seen the bug of request-id 718794, and the warning about security =
in the=20
API doc for setEditorSearchPath. But the security policy is very low in =
my=20
jre, and I haven't a java.security.AccessControlException of whaterver =
about=20
security. The thing is that it could not find a PropertiesEditor. In the =
logs=20
we can see that :
218043 DEBUG [HttpProcessor[8180][2]] beans.BeanWrapperImpl - Convert: =
string=20
to class java.util.Properties
218044 DEBUG [HttpProcessor[8180][2]] beans.BeanWrapperImpl - Using =
property=20
editor [null]
> Well, PropertiesEditor isn't in sun.beans.editors but in=20
> com.interface21.beans.propertyeditors, so the rt.jar contents are =
fine.=20
Yes, if I had read entirely the setEditorSearchPath line, I should have=20
noticed the com.interface21.beans.propertyeditors package. It was a dumb =
remark, hope I'm doing better today...
> I don't understand why=20
> com.interface21.beans.propertyeditors.PropertiesEditor=20
> doesn't get registered automatically in your case... It definitely =
does on=20
> my installation (with a current Spring version).
Neither do I. I've got the current CVS Spring version, the =20
com.interface21.beans.propertyeditors.PropertiesEditor.class is in the=20
spring-full-0.8.jar, and the jar in the WEB-INF/lib. I dont think it's a =
problem of classpath. My env isn't that baroque :
- tomcat 4.0.3
- IBM J2RE 1.3.0=20
- apache 1.3.26 (well I dont think is has to do something..)
And voila, I'm gonna have a further look on it and if I can't find, I =
will=20
let the=20
PropertyEditorManager.registerEditor(Properties.class,PropertiesEditor.cl=
ass)
Regards
Bruno
|
|
From: <jue...@we...> - 2003-05-08 19:01:20
|
Hi web MVC users, As you may already have noticed, I've applied quite extensive = refactorings to the web MVC hierarchy. There are new hooks for = customization (BaseCommandController's initBinder and onBindAndValidate) = that required restructured internals, and a clearer and stricter use of = "final". On every level, subclasses can now only override the methods = that are actually meant to be overridden by application classes. A main addition is AbstractWizardFormController, supporting a = wizard-style workflow via a pages property (a String array of view = names) and abstract validatePage, processFinish, and processCancel = methods. It also offers appropriate onBindAndValidate and referenceData = methods with page parameter. Please consult its JavaDoc for details. In the course of introducing the wizard controller, I've rearchitected = the form controllers. There's AbstractFormController now, providing = abstract showForm and processSubmit methods, being the common superclass = of both AbstractWizardFormController and SimpleFormController. The = latter is basically what FormController and SessionFormController were = before, offering formView and successView properties, and various = onSubmit methods for convenient overriding. Apropos, session handling is = now integrated into AbstractFormController, configurable via the = "sessionForm" property. There's some effort involved in migration existing classes depending on = the version that came with Rod's book, or earlier Spring CVS snapshots. = The necessary changes should be straightforward, so I hope that they = don't cause too much hassle. Of course, I will assist in any problems = that might occur. Juergen DI J=FCrgen H=F6ller Senior System Architect ______________________________________ werk3ATS - division systementwicklung part of werk3AT internetmedien oeg europaplatz 4 A - 4020 linz t. +43 (0) 732 71 65 29 502 f. +43 (0) 732 71 65 29 3 jue...@we... www.werk3at.com ______________________________________ werk3ATS - WIR ENTWICKELN ERFOLG |
|
From: Thomas R. <tri...@tr...> - 2003-05-08 16:48:58
|
Jürgen, I think Hibernate/JDO support is great. Looking forward to trying it out. >> P.P.S.: An obvious follow-up is similar support for JDO: a JdoTemplate, a JdoTransactionManager for JDO-only access to a single database, a LocalPersistenceManagerFactory and a JndiPersistenceManagerFactory. I _might_ look at this myself some time, but I've invested quite a lot of time on the stuff above, so it would definitely take a while. Any volunteers? :-) I have been meaning to try JDO for a while. This will give me an excuse to get around to it, but I don't really know how soon. I'll keep you posted. Thomas Risberg |
|
From: <jue...@we...> - 2003-05-08 10:18:39
|
Hi transaction fans, I've just changed the approach for mixing Hibernate and plain JDBC = access within one transaction: Using DataSourceTransactionManager = required feeding Hibernate a Spring-looked-up JDBC connection (supported = via HibernateTemplate), and didn't support Hibernate's transactional = caching. I've removed this custom-JDBC-connection-for-Hibernate stuff = completely, both from SessionFactoryUtils and HibernateTemplate. There's a better solution: HibernateTransactionManager is now able to = register Hibernate's JDBC Connection just like = DataSourceTransactionManager does. This means that plain JDBC code = automatically takes part in transactions managed by = HibernateTransactionManager! Of course, the application code has to = stick to the required JDBC connection lookup = (DataSourceUtils.getConnection), just like with = DataSourceTransactionManager. But it doesn't need to be aware of = Hibernate at all! That way, mixing transactional services that can use either Hibernate or = plain JDBC internally is possible without restrictions (i.e. including = transactional caching) - with perfect reusability of the latter in = non-Hibernate environments. Regards, Juergen -----Original Message----- From: j=FCrgen h=F6ller [werk3AT]=20 Sent: Wednesday, May 07, 2003 1:44 PM To: spr...@li... Subject: [Springframework-developer] Hibernate support and DataSource transactions Hi everybody, I've just checked the Hibernate stuff in, including the Hibernate = libraries that are necessary for executing the test suite (not enough = for full usage by applications). It's in com.interface21.orm.hibernate. = Most of it should be pretty self-evident and extensively documented, for = people who already know Hibernate's basics. A special issue is handling a Hibernate SessionFactory: I've provided 2 = classes named LocalSessionFactory and JndiSessionFactory. Being = FactoryBeans, they behave like a Hibernate SessionFactory when used as = bean reference. This allows for setting up a SessionFactory in an = application context, and handing it to = HibernateTemplate/HibernateTransactionManager's "sessionFactory" = property as bean reference (or to any custom services having a = SessionFactory-type property). This way, changing from a locally built = SessionFactory to a JNDI one (when using the J2EE Connector) is just a = matter of configuration. For convenience, = HibernateTemplate/HibernateTransactionManager also provide a property = "sessionFactoryName", for direct JDNI lookup. I've also reworked our DataSourceUtils and our DataSource = implementations (DriverManagerDataSource and = SingleConnectionDataSource), reusing code as far as possible, and = allowing for bean-style configuration. All the DataSource-related stuff = is now in com.interface21.jdbc.datasource, taking some classes from = jdbc.core and jdbc.mock (jdbc.mock doesn't exist anymore). On the = occasion, I've introduced a JndiDataSource class that applies the = FactoryBean setup approach to DataSource (as elaborated above regarding = Hibernate). This allows for setting up a DataSource bean in an = application context, either = DriverManagerDataSource/SingleConnectionDataSource or the JndiDataSource = factory, all of them representing a DataSource when given as bean = reference, e.g. to JdbcTemplate, DataSourceTransactionManager, or = HibernateTemplate. Changing from a JNDI DataSource to a local DataSource = is just a matter of configuration, which is nice for test or standalone = environments. Of course, we still support mock JNDI with our = com.interface21.jndi.mock too. Apropos: There's a DataSourceTransactionManager now, an implementation = of PlatformTransactionManager capable of handling transactions for a = single DataSource. It allows applications that just access a single = database to use high-level transaction demarcation, either via = TransactionTemplate or the AOP transaction interceptor - without = requiring JTA support in the container! HibernateTransactionManager = applies the same approach to a single Hibernate SessionFactory, for = applications that access their single database just via Hibernate, = allowing for Hibernate's transactional caching. If the latter isn't = required, DataSourceTransactionManager can be used with Hibernate too, = with the requirement that the Hibernate Sessions must be fed with a = custom DataSourceUtils-looked-up JDBC connection. HibernateTemplate = conveniently supports this with its dataSource/dataSourceName property. = With this approach, direct JDBC access is supported too, while other = code can leverage Hibernate on the same DataSource - within one = transaction! We're already using that stuff in a new product we're developing at = werk3AT, and are pleased with it so far. Have a look at it, I'm looking = forward to your feedback! Regards, Juergen P.S.: In contrast to standard JTA and thus our JtaTransactionManager, both = DataSourceTransactionManager and HibernateTransactionManager do support = isolation levels! P.P.S.: An obvious follow-up is similar support for JDO: a JdoTemplate, a = JdoTransactionManager for JDO-only access to a single database, a = LocalPersistenceManagerFactory and a JndiPersistenceManagerFactory. I = _might_ look at this myself some time, but I've invested quite a lot of = time on the stuff above, so it would definitely take a while. Any = volunteers? :-) DI J=FCrgen H=F6ller Senior System Architect ______________________________________ werk3ATS - division systementwicklung part of werk3AT internetmedien oeg europaplatz 4 A - 4020 linz t. +43 (0) 732 71 65 29 502 f. +43 (0) 732 71 65 29 3 jue...@we... www.werk3at.com ______________________________________ werk3ATS - WIR ENTWICKELN ERFOLG ------------------------------------------------------- Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara The only event dedicated to issues related to Linux enterprise solutions www.enterpriselinuxforum.com _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Isabelle M. <isa...@me...> - 2003-05-08 09:15:31
|
Hi everyone, An advantage of putting back in XSLT is that it becomes possible to use FOP. As for the tutorial/docs : I'm hoping to do the beans tutorial this weekend. The rate that is feasible for me is about one package a week. I'm simultaneously working on the UML model, so there again it's about one package a week. I'll post waht I already have on my web-site in a minute. By the way, let's please try to keep name changes to a minimum from now on, it's not that easy to refactor the UML model :-(( I'm all for giving JP commit access, he has written the sequence code anyway, so why not let him do it. Isabelle On Thu, May 08, 2003 at 08:40:00AM +0100, Rod Johnson wrote: > I'll put iText back. > > JP, do you want to contribute POI view? As you've been interested/involved > in this project since before we went to SourceForge, I'm happy to give you > commit access if you are likely to make ongoing contributions. > > I would really like to have some form of XML/XSLT support, so I might > refactor the old one to remove the present conversion library and leave it > an abstract class. The developer would need to subclass it to generate the > actual XML from the model, using Castor or whatever. Does this sound > reasonable? > > Let's leave XMLC for now. Maybe put in documentation that we can offer > support, to let people ask for it if they want it. > > I've also written a simple JdbcBeanFactory that I'll add before 0.8. > > ==================== > So what do we think is outstanding between now and 0.8? Remember this isn't > 1.0... > > As far as my work goes, I want to > - put iText view back > - remove Attrib4j dependency for now, as Attrib4j support isn't usable yet > and the properties tx interceptor format is the way to go for now > - add JdbcBeanFactory > - I was going to remove DynamicProxy and the ejb.access package, but I'm not > sure I have time to do this in the next few days. Might look at it today if > I get time. > > We will need some examples, and preferably a web site. > > Regards, > Rod > > > ----- Original Message ----- > From: "jürgen höller [werk3AT]" <jue...@we...> > To: "Spring Developers (E-mail)" > <spr...@li...> > Sent: Thursday, May 08, 2003 8:14 AM > Subject: RE: [Springframework-developer] View technologies > > > JP and Rod, > > I'd also like to see the iText view back in Spring, and POI support sounds > interesting too. I'm not too fond of XMLC personally, but I wouldn't mind > including it in Spring too. > > Regarding third-party dependencies: As this issue only affects developers if > we separate the libraries during deployment, I don't consider it a problem > at all. Such libraries don't change on a daily basis, so they only create > overhead on initial checkout/update but not on consecutive updates. We > shouldn't worry about them too much. > > At least they are not redundant, like including numerous WARs and EARs in a > distribution - containing the same libraries again and again. I mean the > Struts/WebWork style, unnecessarily producing distributions larger than 20 > MB. If we use a simpler approach for Spring distributions, even including > all docs and tutorials, we will still not exceed the 10 MB threshold, > probably clock in way below. > > Apropos up-to-date libraries: We should probably care for newest JARs in our > lib directory before 0.8, i.e. Log4J 1.2.8, Velocity 1.3.1 final, Clover > 1.1.1. I volunteer to check these at the beginning of next week. > > Regards, > Juergen > > > -----Original Message----- > From: Rod Johnson [mailto:rod...@in...] > Sent: Thursday, May 08, 2003 8:42 AM > To: JP PAWLAK(Tiscali); Spring Developers (E-mail) > Subject: Re: [Springframework-developer] View technologies > > > JP, > > Good point. > > - XML/XSLT: this one was not really a requested feature. The cyclic java > architecture, even in core objects, was really a problem (example: a > Locale has a defaultLocale property which is itself a Locale.). This > problem was noticed by Rod, but worked not as good as expected, the > source of the patched jar being not available and the original library > didn't be aware of this problem. My feel is that in real world a product > like Castor will certainly be better, even if it's more complex at the > beginning. > > I agree. I think Castor is a better approach. However, I think having > support for transforms in Spring would be good: might have to put the onus > on the user to provide the doument. > > - XMLC: I had no reason for testing it and don't like too much the > approach. > > XMLC is amazingly fast and, while a bit weird, it has some things going for > it. Unfortunately the XmlcView brings in about 2 Mb of XMLC dependencies, so > it would be a real problem with third party libs. Although I guess that > affects only developers. > > > -PDF-iText: I had to render queries results in PDF format for friendly > printing and emailing the results as one clean document. I had no time > to search on others ways like FOP having in a sense a more attractive > approach. But iText was simple to learn and the result is good. The only > drawback is the servlet-style writing hand-coded presentation. > > RJ - This depends on only one Jar. Maybe we should put it back in Spring. > > -Excel-POI: It was not in Rod's book, but always the same data had to be > reworked by users, so an Excel document was a good choice. Having the > velocity and iText views source, it was simple to write an ExcelView > class using Jakarta's POI. This class loads an Excel template (it can > also generate a blank document), completes it before serving. Also a > nice result. The same drawback as for iText can be addressed. > > RJ - Could be useful to have this in Spring. > > I think we should put XML on the todo list, put PDF (iText) back in, and add > JP's Excel view. > > If there's agreement on this I'll add the PDF view shortly. > > Regards, > Rod > > > > > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com > > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com > > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com > > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > -- Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com |
|
From: JP PAWLAK\(Tiscali\) <jp....@ti...> - 2003-05-08 09:12:59
|
When we will reach the 0.8 stage, will be it from interest to contact sites like http://www.waferproject.org/index.html to be registered? =20 > -----Message d'origine----- > De=A0: spr...@li... > [mailto:spr...@li...] De la part > de Rod Johnson > Envoy=E9=A0: jeudi 8 mai 2003 09:40 > =C0=A0: j=FCrgen h=F6ller [werk3AT]; Spring Developers (E-mail) > Objet=A0: Re: [Springframework-developer] View technologies >=20 > I'll put iText back. >=20 > JP, do you want to contribute POI view? As you've been interested/involved > in this project since before we went to SourceForge, I'm happy to give you > commit access if you are likely to make ongoing contributions. (JPP)=20 Yes, I will be happy also. I'm not focusing on a particular part of the framework, but writing what I need for my applications and not being currently available. Just tell me about the commit policy for the changes, will I have to ask someone before committing changes? Concerning the POI view, I will clean the documentation and have some minor changes to make in order to use the Spring localisation. I have forgotten to say that the Excel template can be a set of localised templates. I have also in the pocket a useful helper for paged tabular data. It is not an all cases wizard, but for not huge collections it is very useful. Letting the class in the user session and putting it in the view model, it provides the possibility of page changes, sorting, filtering and providing all information like number of pages/records, current page and so on. It is not bound to a particular view technology or framework (could so good be used in Struts). It can be a general use as it uses a callback method for retrieving the data to populate when necessary the collection to display. Therefore, it need to be maintained (ie in the user session) and contains the whole collection to display, not only the data to display on the current page. >=20 > I would really like to have some form of XML/XSLT support, so I might > refactor the old one to remove the present conversion library and leave it > an abstract class. The developer would need to subclass it to generate the > actual XML from the model, using Castor or whatever. Does this sound > reasonable? (JPP) Living without XML will be difficult. Your proposal seems to be clean. But another point to this: for an effective use, it is useful to chain two XSLT transformations. The first having to create a cohesive XML from the template and the view model, the second for making the rendering. I dream also of a bridge to Cocoon. >=20 > Let's leave XMLC for now. Maybe put in documentation that we can offer > support, to let people ask for it if they want it. >=20 > I've also written a simple JdbcBeanFactory that I'll add before 0.8. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > So what do we think is outstanding between now and 0.8? Remember this > isn't > 1.0... >=20 > As far as my work goes, I want to > - put iText view back > - remove Attrib4j dependency for now, as Attrib4j support isn't usable yet > and the properties tx interceptor format is the way to go for now > - add JdbcBeanFactory > - I was going to remove DynamicProxy and the ejb.access package, but I'm > not > sure I have time to do this in the next few days. Might look at it today > if > I get time. >=20 > We will need some examples, and preferably a web site. >=20 > Regards, > Rod >=20 >=20 > ----- Original Message ----- > From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...> > To: "Spring Developers (E-mail)" > <spr...@li...> > Sent: Thursday, May 08, 2003 8:14 AM > Subject: RE: [Springframework-developer] View technologies >=20 >=20 > JP and Rod, >=20 > I'd also like to see the iText view back in Spring, and POI support sounds > interesting too. I'm not too fond of XMLC personally, but I wouldn't mind > including it in Spring too. >=20 > Regarding third-party dependencies: As this issue only affects developers > if > we separate the libraries during deployment, I don't consider it a problem > at all. Such libraries don't change on a daily basis, so they only create > overhead on initial checkout/update but not on consecutive updates. We > shouldn't worry about them too much. >=20 > At least they are not redundant, like including numerous WARs and EARs in > a > distribution - containing the same libraries again and again. I mean the > Struts/WebWork style, unnecessarily producing distributions larger than 20 > MB. If we use a simpler approach for Spring distributions, even including > all docs and tutorials, we will still not exceed the 10 MB threshold, > probably clock in way below. >=20 > Apropos up-to-date libraries: We should probably care for newest JARs in > our > lib directory before 0.8, i.e. Log4J 1.2.8, Velocity 1.3.1 final, Clover > 1.1.1. I volunteer to check these at the beginning of next week. >=20 > Regards, > Juergen >=20 >=20 > -----Original Message----- > From: Rod Johnson [mailto:rod...@in...] > Sent: Thursday, May 08, 2003 8:42 AM > To: JP PAWLAK(Tiscali); Spring Developers (E-mail) > Subject: Re: [Springframework-developer] View technologies >=20 >=20 > JP, >=20 > Good point. >=20 > - XML/XSLT: this one was not really a requested feature. The cyclic java > architecture, even in core objects, was really a problem (example: a > Locale has a defaultLocale property which is itself a Locale.). This > problem was noticed by Rod, but worked not as good as expected, the > source of the patched jar being not available and the original library > didn't be aware of this problem. My feel is that in real world a product > like Castor will certainly be better, even if it's more complex at the > beginning. >=20 > I agree. I think Castor is a better approach. However, I think having > support for transforms in Spring would be good: might have to put the onus > on the user to provide the doument. >=20 > - XMLC: I had no reason for testing it and don't like too much the > approach. >=20 > XMLC is amazingly fast and, while a bit weird, it has some things going > for > it. Unfortunately the XmlcView brings in about 2 Mb of XMLC dependencies, > so > it would be a real problem with third party libs. Although I guess that > affects only developers. >=20 >=20 > -PDF-iText: I had to render queries results in PDF format for friendly > printing and emailing the results as one clean document. I had no time > to search on others ways like FOP having in a sense a more attractive > approach. But iText was simple to learn and the result is good. The only > drawback is the servlet-style writing hand-coded presentation. >=20 > RJ - This depends on only one Jar. Maybe we should put it back in Spring. >=20 > -Excel-POI: It was not in Rod's book, but always the same data had to be > reworked by users, so an Excel document was a good choice. Having the > velocity and iText views source, it was simple to write an ExcelView > class using Jakarta's POI. This class loads an Excel template (it can > also generate a blank document), completes it before serving. Also a > nice result. The same drawback as for iText can be addressed. >=20 > RJ - Could be useful to have this in Spring. >=20 > I think we should put XML on the todo list, put PDF (iText) back in, and > add > JP's Excel view. >=20 > If there's agreement on this I'll add the PDF view shortly. >=20 > Regards, > Rod >=20 >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com >=20 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 >=20 > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com >=20 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com >=20 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
1239 messages has been excluded from this view by a project administrator.
