Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2003-08-13 19:47:15
|
UmVtb3ZpbmcgdGhlIGJlYW4gZXZlbnQgc3VwcG9ydCBpcyBmaW5lIHdpdGggbWUuIFNhbWUgZm9y IHRoZSBGYWN0b3J5QmVhbiBwYXNzLXRocm91Z2ggcHJvcGVydGllcy4gSSBhbHNvIHdvbmRlciBh Ym91dCB0aGUgc2hhcmVkT2JqZWN0IHN1cHBvcnQgaW4gQXBwbGljYXRpb25Db250ZXh0OiBJIGhh dmVuJ3Qgc2VlbiB0aGF0IGluIGFjdGlvbiBlaXRoZXIuDQogDQpCVFcsIGhhdmUgeW91IG1pZ3Jh dGVkIHRoZSBwYWNrYWdlIG5hbWVzIG9mIENvdW50cmllcyBhbmQgUGV0Y2xpbmljIHRvbz8NCiAN Ckp1ZXJnZW4NCiANCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJ Vm9uOiByb2Quam9obnNvbkBpbnRlcmZhY2UyMS5jb20gW21haWx0bzpyb2Quam9obnNvbkBpbnRl cmZhY2UyMS5jb21dIA0KCUdlc2VuZGV0OiBNaSAxMy4wOC4yMDAzIDE4OjE0IA0KCUFuOiBqw7xy Z2VuIGjDtmxsZXIgW3dlcmszQVRdIA0KCUNjOiBzcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxp c3RzLnNvdXJjZWZvcmdlLm5ldCANCglCZXRyZWZmOiBSRTogW1NwcmluZ2ZyYW1ld29yay1kZXZl bG9wZXJdIEFQSSBzaW1wbGlmaWNhdGlvbg0KCQ0KCQ0KDQoJSSd2ZSBkb25lIHRoZSBwYWNrYWdl IHJlbmFtZSBhbmQgd2lsbCBjb21taXQgaXQgdG8gYQ0KCW5ldyAic3ByaW5nIiBtb2R1bGUgdG9u aWdodC4NCgkNCglJJ2xsIHBvc3QgbW9yZSBkZXRhaWxzIHdoZW4gSSdtIGRvbmUuDQoJDQoJSSd2 ZSBiZWVuIGNvbnNpZGVyaW5nIHNvbWUgcG90ZW50aWFsIHNpbXBsaWZpY2F0aW9ucy4gSSBoYXRl DQoJZGVhZCBjb2RlLS1pdCBhZGRzIGJsb2F0IGFuZCBtYWtlcyBmcmFtZXdvcmtzIGhhcmRlciB0 byB1c2UuDQoJKEkndmUganVzdCBiZWVuIHdvcmtpbmcgd2l0aCBUb3BMaW5rLi4uKSBBcyB3ZSBw cm9ncmVzcyB0bw0KCTEuMCBpdCdzIGEgZ29vZCBvcHBvcnR1bml0eSB0byBjdXQgYmFjayB0byB0 aGUNCgllc3NlbnRpYWxzLi4uaXQgd2lsbCBiZSBoYXJkIHRvIHJlbW92ZSBhbnl0aGluZyAoaG93 ZXZlcg0KCXVzZWxlc3MpIGFmdGVyd2FyZHMuDQoJDQoJQXMgYSBzdGFydCwgSSdtIGNvbnNpZGVy aW5nIHJlbW92aW5nIHRoZSBKYXZhQmVhbiBldmVudA0KCXN1cHBvcnQgZnJvbSBCZWFuV3JhcHBl ci4gSSd2ZSBub3QgdXNlZCBpdCBpbiBhbnkNCglhcHBsaWNhdGlvbnMuIEhhcyBhbnlvbmUgZWxz ZSB1c2VkIGl0Pw0KCQ0KCU5vdyBTcHJpbmcgaGFzIEFPUCBzdXBwb3J0LCBpdCdzIHBvc3NpYmxl IHRvIGFkZCBsaXN0ZW5lcnMgdG8NCglwcm9wZXJ0eSBjaGFuZ2UgZXZlbnRzIHVzaW5nIGludGVy Y2VwdG9ycywgcmF0aGVyIHRoYW4gdGhpcw0KCXJhdGhlciBrbHVkZ3kgcGFydCBvZiB0aGUgSmF2 YUJlYW5zIEFQSS4NCgkNCglSZW1vdmluZyBldmVudCBzdXBwb3J0IHdvdWxkIGdldCByaWQgb2Yg YWJvdXQgMTUwIGxpbmVzIG9mDQoJY29kZSBpbiB0aGUgYmVhbnMgcGFja2FnZSwgYW5kIHNpbXBs aWZ5IHRoZSBBUEkgZm9yIHVzZXJzLg0KCQ0KCUFueSB0aG91Z2h0cyBvbiB0aGlzPw0KCQ0KCUFu b3RoZXIgY2FuZGlkYXRlIG9uIG15IHBvdGVudGlhbCBoaXRsaXN0IGlzIHRoZSAicGFzcy0NCgl0 aHJvdWdoIiBwcm9wZXJ0aWVzIHN1cHBvcnQgZm9yIEZhY3RvcnlCZWFucy4gSSd2ZSBub3Qgc2Vl biBhDQoJbmVlZCB0byB1c2UgdGhpcyBpbiBwcmFjdGljZSAoYWx0aG91Z2ggSSBpbXBsZW1lbnRl ZCBpdCkuDQoJDQoJUmVnYXJkcywNCglSb2QNCgkNCg0K |
|
From: <rod...@in...> - 2003-08-14 03:22:23
|
I've done the package rename and will commit it to a new "spring" module tonight. I'll post more details when I'm done. I've been considering some potential simplifications. I hate dead code--it adds bloat and makes frameworks harder to use. (I've just been working with TopLink...) As we progress to 1.0 it's a good opportunity to cut back to the essentials...it will be hard to remove anything (however useless) afterwards. As a start, I'm considering removing the JavaBean event support from BeanWrapper. I've not used it in any applications. Has anyone else used it? Now Spring has AOP support, it's possible to add listeners to property change events using interceptors, rather than this rather kludgy part of the JavaBeans API. Removing event support would get rid of about 150 lines of code in the beans package, and simplify the API for users. Any thoughts on this? Another candidate on my potential hitlist is the "pass- through" properties support for FactoryBeans. I've not seen a need to use this in practice (although I implemented it). Regards, Rod |
|
From: Rod J. <rod...@in...> - 2003-08-14 08:07:45
|
All,
Thomas has now completed the job and put the code in the existing "Spring"
module. Please work on this by preference.
The snapshot was taken at Aug 13 at 0800 GMT: any changes since to the main
module will need to be manually replicated.
Notes:
- I haven't included the samples. I thought it would be better for JP and
Ken to add these once they're modified. Changing the imports etc is easy
with something like this:
<replace dir="whatever" token="com.interface21"
value="org.springframework">
<exclude name="*.jar"/>
</replace>
- I haven't migrated /livetest. I really prefer the mock object approach for
database testing. I'd love to test Isabelle's code without needing a
database. Any volunteers??
- I have put in a new /load tree, with the load testing code and some
performance tests for Spring.
- The tests pass, and with debug logging we have 75% coverage!
Btw we should be able to use mock tests to test for different db resource
closure failure scenarios.
Regards,
Rod
----- Original Message -----
From: <rod...@in...>
To: "jürgen höller [werk3AT] " <jue...@we...>
Cc: <spr...@li...>
Sent: Wednesday, August 13, 2003 5:14 PM
Subject: RE: [Springframework-developer] API simplification
> I've done the package rename and will commit it to a
> new "spring" module tonight.
>
> I'll post more details when I'm done.
>
> I've been considering some potential simplifications. I hate
> dead code--it adds bloat and makes frameworks harder to use.
> (I've just been working with TopLink...) As we progress to
> 1.0 it's a good opportunity to cut back to the
> essentials...it will be hard to remove anything (however
> useless) afterwards.
>
> As a start, I'm considering removing the JavaBean event
> support from BeanWrapper. I've not used it in any
> applications. Has anyone else used it?
>
> Now Spring has AOP support, it's possible to add listeners to
> property change events using interceptors, rather than this
> rather kludgy part of the JavaBeans API.
>
> Removing event support would get rid of about 150 lines of
> code in the beans package, and simplify the API for users.
>
> Any thoughts on this?
>
> Another candidate on my potential hitlist is the "pass-
> through" properties support for FactoryBeans. I've not seen a
> need to use this in practice (although I implemented it).
>
> 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
>
|
|
From: Ken K. <kk...@kk...> - 2003-08-13 22:35:21
|
Rod, I have some reservations about your proposed deletions. I've been considering a non-J2EE Spring project that would need to use property change listeners and am not sure about going down the AOP route for this. The FactoryBean "pass- through" properties support also sounds useful for this project. Sorry I can't be more certain about needing these features at this time as I just don't have the time right now to look into it more deeply. BTW, got any good reading material recommendations for getting started with AOP ? Regards, Ken >I've done the package rename and will commit it to a > new "spring" module tonight. > > I'll post more details when I'm done. > > I've been considering some potential simplifications. I hate > dead code--it adds bloat and makes frameworks harder to use. > (I've just been working with TopLink...) As we progress to > 1.0 it's a good opportunity to cut back to the > essentials...it will be hard to remove anything (however > useless) afterwards. > > As a start, I'm considering removing the JavaBean event > support from BeanWrapper. I've not used it in any > applications. Has anyone else used it? > > Now Spring has AOP support, it's possible to add listeners to > property change events using interceptors, rather than this > rather kludgy part of the JavaBeans API. > > Removing event support would get rid of about 150 lines of > code in the beans package, and simplify the API for users. > > Any thoughts on this? > > Another candidate on my potential hitlist is the "pass- > through" properties support for FactoryBeans. I've not seen a > need to use this in practice (although I implemented it). > > Regards, > Rod > > > |
