Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2003-08-14 10:39:22
|
SG1tbSwgKmFsbCogc291cmNlIGZpbGVzIGhhdmUgdW5uZWNlc3NhcnkgZW1wdHkgbGluZXMgYWZ0 ZXIgZWFjaCBvcmlnaW5hbCBsaW5lLiBUaGlzIGxvb2tzIGF3ZnVsIGFuZCBkb3VibGVzIHRoZSBz aXplLiBUaGUgb25seSBleGNlcHRpb24gYXJlIHRoZSB0YWcgY2xhc3NlcyB0aGF0IEplYW4tUGll cnJlIGNoZWNrZWQgaW4uLi4gSXMgdGhpcyBzb21lIGZhbmN5IG5ldyBFY2xpcHNlIGZlYXR1cmUg b24gUm9kJ3MgaW5zdGFsbGF0aW9uLCBvciBldmVuIG9uIHB1cnBvc2U/IDstKQ0KIA0KVW5mb3J0 dW5hdGVseSwgbm90IGV2ZW4gYSBjb2RlIHJlZm9ybWF0dGluZyBoZWxwcyAoYXQgbGVhc3Qgbm90 IHdpdGggSURFQSkuIFNvIEkgZ3Vlc3Mgd2Ugd2lsbCBwcm9iYWJseSBoYXZlIHRvIHJlLWNoZWNr aW4gdGhlICplbnRpcmUqIHNvdXJjZSB0cmVlIChleGNlcHQgdGhlIHRhZyBjbGFzc2VzLCB0byBi ZSBhY2N1cmF0ZSA7LSkuIFJvZCwgVGhvbWFzLCBKZWFuLVBpZXJyZSAtIGNhbiB5b3UgdHJ5IHRv IGRlYWwgd2l0aCB0aGlzLCBhcyBJJ20gYXdheSB0aWxsIFNhdHVyZGF5IG1vcm5pbmc/DQogDQpC VFcsIFJlc291cmNlQnVuZGxlVmlld1Jlc29sdmVyVGVzdFN1aXRlIHNlZW1zIGJyb2tlbiBiZWNh dXNlIGl0IGNhbid0IHJlYWQgdGhlIHRlc3R2aWV3cy5wcm9wZXJ0aWVzIHByb3BlcnR5OiBTdGF0 aWMgYXR0cmlidXRlIGRlZmluaXRpb25zIGFyZSBub3QgcmVjb2duaXplZCBmdWxseSBiZWNhdXNl IHRoZXJlIGFyZSBlbXB0eSBsaW5lcyBpbmJldHdlZW4gdGhlbS4uLiBXZSByZWFsbHkgbmVlZCB0 byByZS1jaGVja2luLCBhcyB0aGUgcHJvcGVydGllcyBhcmUgY29uY2VybmVkIHRvby4NCiANCkp1 ZXJnZW4NCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBS b2QgSm9obnNvbiBbbWFpbHRvOnJvZC5qb2huc29uQGludGVyZmFjZTIxLmNvbV0gDQoJR2VzZW5k ZXQ6IERvIDE0LjA4LjIwMDMgMDk6NTcgDQoJQW46IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJA bGlzdHMuc291cmNlZm9yZ2UubmV0IA0KCUNjOiBqw7xyZ2VuIGjDtmxsZXIgW3dlcmszQVRdIA0K CUJldHJlZmY6IFJlOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gTmV3IFNwcmluZyBtb2R1 bGUNCgkNCgkNCg0KCUFsbCwNCgkNCglUaG9tYXMgaGFzIG5vdyBjb21wbGV0ZWQgdGhlIGpvYiBh bmQgcHV0IHRoZSBjb2RlIGluIHRoZSBleGlzdGluZyAiU3ByaW5nIg0KCW1vZHVsZS4gUGxlYXNl IHdvcmsgb24gdGhpcyBieSBwcmVmZXJlbmNlLg0KCQ0KCVRoZSBzbmFwc2hvdCB3YXMgdGFrZW4g YXQgQXVnIDEzIGF0IDA4MDAgR01UOiBhbnkgY2hhbmdlcyBzaW5jZSB0byB0aGUgbWFpbg0KCW1v ZHVsZSB3aWxsIG5lZWQgdG8gYmUgbWFudWFsbHkgcmVwbGljYXRlZC4NCgkNCglOb3RlczoNCgkN CgktIEkgaGF2ZW4ndCBpbmNsdWRlZCB0aGUgc2FtcGxlcy4gSSB0aG91Z2h0IGl0IHdvdWxkIGJl IGJldHRlciBmb3IgSlAgYW5kDQoJS2VuIHRvIGFkZCB0aGVzZSBvbmNlIHRoZXkncmUgbW9kaWZp ZWQuIENoYW5naW5nIHRoZSBpbXBvcnRzIGV0YyBpcyBlYXN5DQoJd2l0aCBzb21ldGhpbmcgbGlr ZSB0aGlzOg0KCQ0KCSAgPHJlcGxhY2UgZGlyPSJ3aGF0ZXZlciIgIHRva2VuPSJjb20uaW50ZXJm YWNlMjEiDQoJdmFsdWU9Im9yZy5zcHJpbmdmcmFtZXdvcmsiPg0KCSAgICA8ZXhjbHVkZSBuYW1l PSIqLmphciIvPg0KCSAgPC9yZXBsYWNlPg0KCQ0KCS0gSSBoYXZlbid0IG1pZ3JhdGVkIC9saXZl dGVzdC4gSSByZWFsbHkgcHJlZmVyIHRoZSBtb2NrIG9iamVjdCBhcHByb2FjaCBmb3INCglkYXRh YmFzZSB0ZXN0aW5nLiBJJ2QgbG92ZSB0byB0ZXN0IElzYWJlbGxlJ3MgY29kZSB3aXRob3V0IG5l ZWRpbmcgYQ0KCWRhdGFiYXNlLiBBbnkgdm9sdW50ZWVycz8/DQoJDQoJLSBJIGhhdmUgcHV0IGlu IGEgbmV3IC9sb2FkIHRyZWUsIHdpdGggdGhlIGxvYWQgdGVzdGluZyBjb2RlIGFuZCBzb21lDQoJ cGVyZm9ybWFuY2UgdGVzdHMgZm9yIFNwcmluZy4NCgkNCgktIFRoZSB0ZXN0cyBwYXNzLCBhbmQg d2l0aCBkZWJ1ZyBsb2dnaW5nIHdlIGhhdmUgNzUlIGNvdmVyYWdlIQ0KCQ0KCUJ0dyB3ZSBzaG91 bGQgYmUgYWJsZSB0byB1c2UgbW9jayB0ZXN0cyB0byB0ZXN0IGZvciBkaWZmZXJlbnQgZGIgcmVz b3VyY2UNCgljbG9zdXJlIGZhaWx1cmUgc2NlbmFyaW9zLg0KCQ0KCVJlZ2FyZHMsDQoJUm9kDQoJ DQoJLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KCUZyb206IDxyb2Quam9obnNvbkBpbnRl cmZhY2UyMS5jb20+DQoJVG86ICJqw7xyZ2VuIGjDtmxsZXIgW3dlcmszQVRdICIgPGp1ZXJnZW4u aG9lbGxlckB3ZXJrM2F0LmNvbT4NCglDYzogPHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlz dHMuc291cmNlZm9yZ2UubmV0Pg0KCVNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDEzLCAyMDAzIDU6 MTQgUE0NCglTdWJqZWN0OiBSRTogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIEFQSSBzaW1w bGlmaWNhdGlvbg0KCQ0KCQ0KCT4gSSd2ZSBkb25lIHRoZSBwYWNrYWdlIHJlbmFtZSBhbmQgd2ls bCBjb21taXQgaXQgdG8gYQ0KCT4gbmV3ICJzcHJpbmciIG1vZHVsZSB0b25pZ2h0Lg0KCT4NCgk+ IEknbGwgcG9zdCBtb3JlIGRldGFpbHMgd2hlbiBJJ20gZG9uZS4NCgk+DQoJPiBJJ3ZlIGJlZW4g Y29uc2lkZXJpbmcgc29tZSBwb3RlbnRpYWwgc2ltcGxpZmljYXRpb25zLiBJIGhhdGUNCgk+IGRl YWQgY29kZS0taXQgYWRkcyBibG9hdCBhbmQgbWFrZXMgZnJhbWV3b3JrcyBoYXJkZXIgdG8gdXNl Lg0KCT4gKEkndmUganVzdCBiZWVuIHdvcmtpbmcgd2l0aCBUb3BMaW5rLi4uKSBBcyB3ZSBwcm9n cmVzcyB0bw0KCT4gMS4wIGl0J3MgYSBnb29kIG9wcG9ydHVuaXR5IHRvIGN1dCBiYWNrIHRvIHRo ZQ0KCT4gZXNzZW50aWFscy4uLml0IHdpbGwgYmUgaGFyZCB0byByZW1vdmUgYW55dGhpbmcgKGhv d2V2ZXINCgk+IHVzZWxlc3MpIGFmdGVyd2FyZHMuDQoJPg0KCT4gQXMgYSBzdGFydCwgSSdtIGNv bnNpZGVyaW5nIHJlbW92aW5nIHRoZSBKYXZhQmVhbiBldmVudA0KCT4gc3VwcG9ydCBmcm9tIEJl YW5XcmFwcGVyLiBJJ3ZlIG5vdCB1c2VkIGl0IGluIGFueQ0KCT4gYXBwbGljYXRpb25zLiBIYXMg YW55b25lIGVsc2UgdXNlZCBpdD8NCgk+DQoJPiBOb3cgU3ByaW5nIGhhcyBBT1Agc3VwcG9ydCwg aXQncyBwb3NzaWJsZSB0byBhZGQgbGlzdGVuZXJzIHRvDQoJPiBwcm9wZXJ0eSBjaGFuZ2UgZXZl bnRzIHVzaW5nIGludGVyY2VwdG9ycywgcmF0aGVyIHRoYW4gdGhpcw0KCT4gcmF0aGVyIGtsdWRn eSBwYXJ0IG9mIHRoZSBKYXZhQmVhbnMgQVBJLg0KCT4NCgk+IFJlbW92aW5nIGV2ZW50IHN1cHBv cnQgd291bGQgZ2V0IHJpZCBvZiBhYm91dCAxNTAgbGluZXMgb2YNCgk+IGNvZGUgaW4gdGhlIGJl YW5zIHBhY2thZ2UsIGFuZCBzaW1wbGlmeSB0aGUgQVBJIGZvciB1c2Vycy4NCgk+DQoJPiBBbnkg dGhvdWdodHMgb24gdGhpcz8NCgk+DQoJPiBBbm90aGVyIGNhbmRpZGF0ZSBvbiBteSBwb3RlbnRp YWwgaGl0bGlzdCBpcyB0aGUgInBhc3MtDQoJPiB0aHJvdWdoIiBwcm9wZXJ0aWVzIHN1cHBvcnQg Zm9yIEZhY3RvcnlCZWFucy4gSSd2ZSBub3Qgc2VlbiBhDQoJPiBuZWVkIHRvIHVzZSB0aGlzIGlu IHByYWN0aWNlIChhbHRob3VnaCBJIGltcGxlbWVudGVkIGl0KS4NCgk+DQoJPiBSZWdhcmRzLA0K CT4gUm9kDQoJPg0KCT4NCgk+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCgk+IFRoaXMgU0YuTmV0IGVtYWlsIHNwb25zb3JlZCBieTogRnJl ZSBwcmUtYnVpbHQgQVNQLk5FVCBzaXRlcyBpbmNsdWRpbmcNCgk+IERhdGEgUmVwb3J0cywgRS1j b21tZXJjZSwgUG9ydGFscywgYW5kIEZvcnVtcyBhcmUgYXZhaWxhYmxlIG5vdy4NCgk+IERvd25s b2FkIHRvZGF5IGFuZCBlbnRlciB0byB3aW4gYW4gWEJPWCBvciBWaXN1YWwgU3R1ZGlvIC5ORVQu DQoJPg0KCWh0dHA6Ly9hc3BuZXQuY2xpY2stdXJsLmNvbS9nby9wc2EwMDEwMDAwM2F2ZS9kaXJl Y3Q7YXQuYXNwbmV0XzA3MjMwM18wMS8wMQ0KCT4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCgk+IFNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIgbWFpbGlu ZyBsaXN0DQoJPiBTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5l dA0KCT4gaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5n ZnJhbWV3b3JrLWRldmVsb3Blcg0KCT4NCgkNCgkNCgkNCg0K |
|
From: <rod...@in...> - 2003-08-14 13:55:52
|
>Hmmm, *all* source files have unnecessary empty lines after each original line. This looks awful and doubles the size. The only exception are the tag classes that Jean-Pierre checked in... Is this some fancy new Eclipse feature on Rod's installation, or even on purpose? ;-) This must have happened with Thomas's checkin, as there weren't blank lines in my source code. Unfortunately Thomas had to pick up the commit as Eclipse refused to create a new project for me last night. >Unfortunately, not even a code reformatting helps (at least not with IDEA). So I guess we will probably have to re- checkin the *entire* source tree (except the tag classes, to be accurate ;-). Rod, Thomas, Jean-Pierre - can you try to deal with this, as I'm away till Saturday morning? Thomas, can you please try again with the sources I emailed? Or pass them onto JP perhaps for him to have a go. Sorry about not being able to complete this myself... Regards, Rod |
|
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 |
|
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: <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: 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: Colin S. <col...@ex...> - 2003-08-14 13:34:04
|
In fact, it's not a normal empty line after each original line. When I check out the new repo, what I get (on my Windows system) is a <CR> <CR> <LF> at the end of each line, instead of the normal <CR> <LF> that should be there. Now what happens is that CVS on linux/unix stores end of lines as just <LF>, and then when you check out they get converted as needed for your platform. When I have seen this sort of thing happen before (and maybe what Rod did), was when a file was checked out to a windows system, so that every line has the CRLF at the end, but then mailed or transported to a Unix system, and then checked in there as is. In this case, the unix client doesn't know that it has to strip the CR at the end of each line on checking, and the checkin ends up with CRLF in the reop itself. Then when you do a subsequent checkout on the windows system, the client on the system thinks (correctly) that it has to add a CR before every incoming LF, and you end up with CRCRLF at the end of every line. (Note btw, that it's not the actual CVS client that does the end of line handling, it's really the stdio routines in the C library, which handle this appropriately for the platform). In any case, this is sort of a mess :-) jürgen höller [werk3AT] wrote: >Hmmm, *all* source files have unnecessary empty lines after each original line. This looks awful and doubles the size. The only exception are the tag classes that Jean-Pierre checked in... Is this some fancy new Eclipse feature on Rod's installation, or even on purpose? ;-) > >Unfortunately, not even a code reformatting helps (at least not with IDEA). So I guess we will probably have to re-checkin the *entire* source tree (except the tag classes, to be accurate ;-). Rod, Thomas, Jean-Pierre - can you try to deal with this, as I'm away till Saturday morning? > >BTW, ResourceBundleViewResolverTestSuite seems broken because it can't read the testviews.properties property: Static attribute definitions are not recognized fully because there are empty lines inbetween them... We really need to re-checkin, as the properties are concerned too. > >Juergen > > > -----Ursprüngliche Nachricht----- > Von: Rod Johnson [mailto:rod...@in...] > Gesendet: Do 14.08.2003 09:57 > An: spr...@li... > Cc: jürgen höller [werk3AT] > Betreff: Re: [Springframework-developer] New Spring module > > > > 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. > > > |
|
From: <tri...@tr...> - 2003-08-14 14:38:07
|
Colin, > > When I have seen this sort of thing happen before (and maybe what Rod > did), was when a file was checked out to a windows system, so that every > line has the CRLF at the end, but then mailed or transported to a Unix > system, and then checked in there as is. In this case, the unix client > doesn't know that it has to strip the CR at the end of each line on > checking, and the checkin ends up with CRLF in the reop itself. Then > when you do a subsequent checkout on the windows system, the client on > the system thinks (correctly) that it has to add a CR before every > incoming LF, and you end up with CRCRLF at the end of every line. > > (Note btw, that it's not the actual CVS client that does the end of line > handling, it's really the stdio routines in the C library, which handle > this appropriately for the platform). > > In any case, this is sort of a mess :-) > Yes, and you are right about pretty much everything else in your post :-) 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. I'll use my windows system this time to get proper CR/LF conversion. Thomas |
|
From: <tri...@tr...> - 2003-08-14 14:02:42
|
Juergen, That does sound odd - I am looking at the code I have and everything looks fine. Did a compare with BeanWrapperImpl (The one you updated) and it appears that my version and yours have not a single line in common - must be something with whitespace or linefeed conversions. Is anybody else seeing this? What is everybody using for CVS access? I'm using cvs command line on Linux as well as Eclipse on both WinXP and Linux. I can't see the extra lines. Thomas > Hmmm, *all* source files have unnecessary empty lines after each original > line. This looks awful and doubles the size. The only exception are the tag > classes that Jean-Pierre checked in... Is this some fancy new Eclipse feature > on Rod's installation, or even on purpose? ;-) > > Unfortunately, not even a code reformatting helps (at least not with IDEA). > So I guess we will probably have to re-checkin the *entire* source tree > (except the tag classes, to be accurate ;-). Rod, Thomas, Jean-Pierre - can > you try to deal with this, as I'm away till Saturday morning? > > BTW, ResourceBundleViewResolverTestSuite seems broken because it can't read > the testviews.properties property: Static attribute definitions are not > recognized fully because there are empty lines inbetween them... We really > need to re-checkin, as the properties are concerned too. > > Juergen > > > -----Ursprüngliche Nachricht----- > Von: Rod Johnson [mailto:rod...@in...] > Gesendet: Do 14.08.2003 09:57 > An: spr...@li... > Cc: jürgen höller [werk3AT] > Betreff: Re: [Springframework-developer] New Spring module > > > > 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 > > > > > > > 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: Alef A. \(JTeam\) <al...@jt...> - 2003-08-14 11:29:30
|
About the tags module... Some CVS clients (ao the Tortoise client) has = built-in filters for directories which are named 'tags'. This might be = the problem with the missing tags directory... Just to let you know. Alef -----Oorspronkelijk bericht----- Van: spr...@li... = [mailto:spr...@li...] Namens = j=C3=BCrgen h=C3=B6ller [werk3AT] Verzonden: Thursday, August 14, 2003 12:27 PM Aan: Rod Johnson; spr...@li... Onderwerp: Re: [Springframework-developer] New Spring module Hmmm, *all* source files have unnecessary empty lines after each = original line. This looks awful and doubles the size. The only exception = are the tag classes that Jean-Pierre checked in... Is this some fancy = new Eclipse feature on Rod's installation, or even on purpose? ;-) =20 Unfortunately, not even a code reformatting helps (at least not with = IDEA). So I guess we will probably have to re-checkin the *entire* = source tree (except the tag classes, to be accurate ;-). Rod, Thomas, = Jean-Pierre - can you try to deal with this, as I'm away till Saturday = morning? =20 BTW, ResourceBundleViewResolverTestSuite seems broken because it can't = read the testviews.properties property: Static attribute definitions are = not recognized fully because there are empty lines inbetween them... We = really need to re-checkin, as the properties are concerned too. =20 Juergen =20 -----Urspr=C3=BCngliche Nachricht-----=20 Von: Rod Johnson [mailto:rod...@in...]=20 Gesendet: Do 14.08.2003 09:57=20 An: spr...@li...=20 Cc: j=C3=BCrgen h=C3=B6ller [werk3AT]=20 Betreff: Re: [Springframework-developer] New Spring module =09 =09 All, =09 Thomas has now completed the job and put the code in the existing = "Spring" module. Please work on this by preference. =09 The snapshot was taken at Aug 13 at 0800 GMT: any changes since to the = main module will need to be manually replicated. =09 Notes: =09 - 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: =09 <replace dir=3D"whatever" token=3D"com.interface21" value=3D"org.springframework"> <exclude name=3D"*.jar"/> </replace> =09 - 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?? =09 - I have put in a new /load tree, with the load testing code and some performance tests for Spring. =09 - The tests pass, and with debug logging we have 75% coverage! =09 Btw we should be able to use mock tests to test for different db = resource closure failure scenarios. =09 Regards, Rod =09 ----- Original Message ----- From: <rod...@in...> To: "j=C3=BCrgen h=C3=B6ller [werk3AT] " <jue...@we...> Cc: <spr...@li...> Sent: Wednesday, August 13, 2003 5:14 PM Subject: RE: [Springframework-developer] API simplification =09 =09 > 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 > =09 =09 =09 N=18HS^=E9=9A=8A[){([ Zz=DE=9An =044D w%=D8=A76i=17l=11&=CA=99 = x+ljwE=E9=A2=BBj zz0=0E'=E5=8C=96Z=C9=A9z{^=DD=AE0=DA=8Av\=13bJ DN=1Bm = =DE=B5brK=C9=AB&=20 ?=C6=B4]4 M=DA=BD Z=DE=B7N M 5J = jg=ED=B0=AB=ED=B0=A2=1Dz=ED=BD=96=ED=B2=97x%R=CB=A6 (G^=EC=AE=BDh lq = zm=D8=B6?X (=1E~zw X b=CB=9D? jg=EB=B0=A2=1Dz=ED=BD=96=ED=B2=97 |
