springframework-developer — Spring Framework developers list

RE: [Springframework-developer] Any sort of defined policy w/rega rds to tab/space usage and indentation?

[Kopylenko, D. <dko...@ac...>]

I also use tabs and Eclipse supports them very well ;-)

Dmitriy.

-----Original Message-----
From: Rod Johnson [mailto:rod...@in...] 
Sent: Wednesday, October 01, 2003 3:37 AM
To: Colin Sampaleanu; jue...@we...
Cc: Spring Developers
Subject: Re: [Springframework-developer] Any sort of defined policy
w/regards to tab/space usage and indentation?


The use of tabs is historical. I'm in the minority of people who use tabs,
so the original code base had tabs and I still use them. I know most people
in open source projects hate tabs, so we might eventually need to change
this.

We did consider the use of Jalopy before check in at one point.

I'd prefer not to mess with the formatting process before 1.0 unless we
really need to.

Regards,
Rod

----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <rod...@in...>; <jue...@we...>
Cc: "Spring Developers" <spr...@li...>
Sent: Tuesday, September 30, 2003 10:14 PM
Subject: [Springframework-developer] Any sort of defined policy w/regards to
tab/space usage and indentation?


> I notice that most of the codebase in Spring uses hard tabs as opposed 
> to spaces for indentation. From looking at some comment text which 
> does have some embedded spaces, as far as I can tell the assumption is 
> that tabs equate to 4 chars, although most of the code itself does not 
> seem to make this assumption?
>
> Is there any sort of project policy or guideline on this? i.e. 
> something like 'all code must use hard tabs, and align elements only 
> with tabs', etc.? I can hopefully work with any policy, but I'd just 
> like to know if one exists... (although if I am forced to use hard 
> tabs I would actually have to set up another Eclipse workspace, right 
> now my tab key puts out spaces).
>
> fwiw, I have personally found that hard tabs are somewhat of a 
> disaster (or at least a problem) in many team environents. In my 
> teams, it's generally the one rule we apply with no exceptions, "no 
> hard tabs". The problem is that while hard tabs have the ideal benefit 
> of allowing users to indent to whatever size they like, in practice 
> people seem to not have the discipline to stick to using tabs only, or 
> their editor of the moment doesn't allow them to set the tab size to 
> something else easilly, so spaces creep in. Once that happens to any 
> extent, the code looks broken to anybody else using another tab size.
>
> Regards,
> Colin
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf 
> _______________________________________________
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Any sort of defined policy w/regards to tab/space usage and indentation?

[Rod J. <rod...@in...>]

The use of tabs is historical. I'm in the minority of people who use tabs,
so the original code base had tabs and I still use them. I know most people
in open source projects hate tabs, so we might eventually need to change
this.

We did consider the use of Jalopy before check in at one point.

I'd prefer not to mess with the formatting process before 1.0 unless we
really need to.

Regards,
Rod

----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <rod...@in...>; <jue...@we...>
Cc: "Spring Developers" <spr...@li...>
Sent: Tuesday, September 30, 2003 10:14 PM
Subject: [Springframework-developer] Any sort of defined policy w/regards to
tab/space usage and indentation?


> I notice that most of the codebase in Spring uses hard tabs as opposed
> to spaces for indentation. From looking at some comment text which does
> have some embedded spaces, as far as I can tell the assumption is that
> tabs equate to 4 chars, although most of the code itself does not seem
> to make this assumption?
>
> Is there any sort of project policy or guideline on this? i.e. something
> like 'all code must use hard tabs, and align elements only with tabs',
> etc.? I can hopefully work with any policy, but I'd just like to know if
> one exists... (although if I am forced to use hard tabs I would actually
> have to set up another Eclipse workspace, right now my tab key puts out
> spaces).
>
> fwiw, I have personally found that hard tabs are somewhat of a disaster
> (or at least a problem) in many team environents. In my teams, it's
> generally the one rule we apply with no exceptions, "no hard tabs". The
> problem is that while hard tabs have the ideal benefit of allowing users
> to indent to whatever size they like, in practice people seem to not
> have the discipline to stick to using tabs only, or their editor of the
> moment doesn't allow them to set the tab size to something else easilly,
> so spaces creep in. Once that happens to any extent, the code looks
> broken to anybody else using another tab size.
>
> Regards,
> Colin
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] wrapping an interceptor and Hibernate specific TransactionProxyFactoryBean

[<jue...@we...>]

VW5mb3J0dW5hdGVseSwgeW91J3JlIHJpZ2h0IC0gSSBoYXZlbid0IGNoZWNrZWQgaXQgaW4geWV0
IGR1ZSB0byBzb21lIGNvbnZlbmllbmNlIHJlZmluZW1lbnQgaW4gQU9QIHByb3h5IGdlbmVyYXRp
b24gdGhhdCBhbHNvIGVmZmVjdHMgdGhlIGltcGxlbWVudGF0aW9ucyBvZiB0aGUgcmVtb3Rpbmcg
cHJveGllcy4gSSdsbCBjaGVjayB0aGF0IHdob2xlIGJ1bmNoIGluIGFzIHNvb24gYXMgcG9zc2li
bGUuDQogDQpUaGUgaWRlYSB3aXRoICJwcmUiIGFuZCAicG9zdCIgaW50ZXJjZXB0b3JzIHNvdW5k
cyByZWFzb25hYmxlIC0gbWF5YmUgYSAicHJlSW50ZXJjZXB0b3JzIiBhbmQgInBvc3RJbnRlcmNl
cHRvcnMiIHByb3BlcnR5PyBXZSBuZWVkIHRvIG1ha2Ugc3VyZSB0aGF0IFRyYW5zYWN0aW9uUHJv
eHlGYWN0b3J5QmVhbiBkb2Vzbid0IGdyb3cgdG8gYSByZXBsYWNlbWVudCBvZiB0aGUgZ2VuZXJh
bCBBT1AgUHJveHlGYWN0b3J5QmVhbiBqdXN0IHdpdGggc3BlY2lhbCB0cmVhdG1lbnQgb2YgdGhl
IFRyYW5zYWN0aW9uSW50ZXJjZXB0b3IsIHRob3VnaC4NCiANCkp1ZXJnZW4NCiANCg0KCS0tLS0t
VXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJVm9uOiBDb2xpbiBTYW1wYWxlYW51IFtt
YWlsdG86Y29saW5tbDFAZXhpcy5jb21dIA0KCUdlc2VuZGV0OiBEaSAzMC4wOS4yMDAzIDIzOjE2
IA0KCUFuOiBqw7xyZ2VuIGjDtmxsZXIgW3dlcmszQVRdOyBzcHJpbmdmcmFtZXdvcmstZGV2ZWxv
cGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCANCglDYzogDQoJQmV0cmVmZjogUmU6IFtTcHJpbmdm
cmFtZXdvcmstZGV2ZWxvcGVyXSB3cmFwcGluZyBhbiBpbnRlcmNlcHRvciBhbmQgSGliZXJuYXRl
IHNwZWNpZmljIFRyYW5zYWN0aW9uUHJveHlGYWN0b3J5QmVhbg0KCQ0KCQ0KDQoJSSBzZWUgdGhp
cyBoYXNuJ3QgbWFkZSBpdCBpbnRvIGN2cyB5ZXQuIE5vIGh1cnJ5IHRoZXJlLCBidXQgSSB3YXMg
anVzdA0KCXRoaW5raW5nIHRoYXQgaW4gdGVybXMgb2YgbWFraW5nIGEgZ2VuZXJpYyBtZWNoYW5p
c20gb3V0IG9mIHRoaXMgY2xhc3MsDQoJaXQgbWF5IG1ha2UgbW9yZSBzZW5zZSB0byBhbGxvdyBi
b3RoICdwcmUnIGFuZCAncG9zdCcgaW50ZXJjZXB0b3JzDQoJYXJvdW5kIHRoZSBpbXBsaWNpdCB0
cmFuc2FjdGlvbiBpbnRlcmNlcHRvci4gU29tZSBraW5kcyBvZiBpbnRlcmNlcHRpb24sDQoJc3Vj
aCBhcyBwZXJmb3JtYW5jZSBsb2dnaW5nLCBwcm9iYWJseSBiZWxvbmcgYmVmb3JlLCBmb3IgZXhh
bXBsZS4uLg0KCQ0KCQ0KCWrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF0gd3JvdGU6DQoJDQoJPkhp
IENvbGluLA0KCT4NCgk+QWN0dWFsbHksIEkgY29tcGxldGVseSBhZ3JlZTogSXQgaXNuJ3QgZXZl
biBwb3NzaWJsZSB0byBhcHBseSBhZGRpdGlvbmFsIGludGVyY2VwdG9ycyBqdXN0IGZvciB0cmFu
c2FjdGlvbmFsIG1ldGhvZHMsIGFzIHRoZSB0cmFuc2FjdGlvbiBzZW1hbnRpY3Mgb2YgYSBtZXRo
b2QgYXJlIGRldGVybWluZWQgd2l0aGluIHRoZSBUcmFuc2FjdGlvbkludGVyY2VwdG9yIGltcGxl
bWVudGF0aW9uIHdoZXJlIHdlIGNhbid0IGhvb2sgYW55IGFkZGl0aW9uYWwgaW50ZXJjZXB0b3Jz
IGluLiBTbyBib3RoIGluIHRlcm1zIG9mIGNsZWFybmVzcyBhbmQgc2ltcGxlIGltcGxlbWVudGF0
aW9uLCBsZXQncyBpbnRyb2R1Y2UgYW4gImFkZGl0aW9uYWxJbnRlcmNlcHRvcnMiIHByb3BlcnR5
IG9mIHR5cGUgIkludGVyY2VwdG9yW10iLCBnZXR0aW5nIGFwcGxpZWQgX2FmdGVyXyB0aGUgVHJh
bnNhY3Rpb25JbnRlcmNlcHRvci4gSSd2ZSBqdXN0IGltcGxlbWVudGVkIHRoYXQ7IEknbGwgY2hl
Y2sgaXQgaW4gbGF0ZXIgdGhpcyBhZnRlcm5vb24uDQoJPg0KCT5KdWVyZ2VuDQoJPg0KCT4NCgk+
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgk+RnJvbTogQ29saW4gU2FtcGFsZWFudSBbbWFp
bHRvOmNvbGlubWwxQGV4aXMuY29tXQ0KCT5TZW50OiBTdW5kYXksIFNlcHRlbWJlciAyOCwgMjAw
MyAxMDozMCBQTQ0KCT5UbzogasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXQ0KCT5DYzogc3ByaW5n
ZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCgk+U3ViamVjdDogUmU6
IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSB3cmFwcGluZyBhbiBpbnRlcmNlcHRvciBhbmQN
Cgk+SGliZXJuYXRlIHNwZWNpZmljIFRyYW5zYWN0aW9uUHJveHlGYWN0b3J5QmVhbg0KCT4NCgk+
DQoJPkrDvHJnZW4sDQoJPg0KCT4oTm93IHRoYXQgeW91IGFyZSBiYWNrIEkgY2FuIHdyaXRlIHNv
bWUgbW9yZSAnZnJpdm9sb3VzJyBlbWFpbHMgOi0pICkuDQoJPg0KCT5XL3JlZ2FyZHMgdG8gYWRk
aW5nIGFkZGl0aW9uYWwgaW50ZXJjZXB0b3Igc3VwcG9ydCB0bw0KCT5UcmFuc2FjdGlvblByb3h5
RmFjdG9yeUJlYW4sIEknbSBub3Qgc3VyZSBJIGZ1bGx5IGFncmVlIHRoYXQgaXQncw0KCT5pbmhl
cmVudGx5IGJldHRlciBvciAnY2xlYW5lcicgdG8gYXBwbHkgdGhlc2UgdG8gdHJhbnNhY3Rpb25h
bCBtZXRob2RzDQoJPm9ubHkuIFRoYXQgaXMsIHdoZW4gdGhpbmtpbmcsICd3aGF0IGlzIFRyYW5z
YWN0aW9uUHJveHlGYWN0b3J5QmVhbiAoaW4NCgk+dGhpcyBtb2RpZmllZCB2ZXJzaW9uKT8nLCB5
b3UgY291bGQgY29uc2lkZXIgaXQgYXMgYSB2YXJpYW50IG9mDQoJPlByb3h5RmFjdG9yeUJlYW4g
dGhhdCBpbXBsaWNpdGx5IGFwcGxpZXMgYSBUcmFuc2FjdGlvbiBpbnRlcmNlcHRvcg0KCT4oYmVm
b3JlLCBhZnRlciwgb3IgaW4gYmV0d2VlbiBvdGhlciBpbnRlcmNlcHRvcnMsIGFzIHdlIGRlY2lk
ZSBtYWtlcyB0aGUNCgk+bW9zdCBzZW5zZSkuIFRob3NlIG90aGVyIGludGVyY2VwdG9ycyBjYW4g
dGhlbXNlbHZlcyBkZWNpZGUgaWYgdGhleQ0KCT5hcHBseSwgYXMgd2l0aCBQcm94eUZhY3RvcnlC
ZWFuLi4uDQoJPg0KCT5UaGVyZSBpcyBhIHVzZWNhc2UgZm9yIGNhbGxpbmcgSGliZXJuYXRlIGNv
ZGUgKG5lZWRpbmcgYSBzZXNzaW9uKSwNCgk+d2l0aG91dCBuZWVkaW5nIHRyYW5zYWN0aW9ucywg
YW5kIHRoYXQncyBtb3N0bHkgZm9yIHJlYWQtb25seSBkYXRhDQoJPih3aGVyZSB0aGVyZSBpcyBu
byBuZWVkIGZvciBpc29sYXRpb24gcHJvdmlkZWQgYnkgYSB0cmFuc2FjdGlvbikuIEkNCgk+cmVh
bGl6ZSB0aGF0IEkgY291bGQganVzdCB1c2UgYSByZWd1bGFyIFByb3h5RmFjdG9yeUJlYW4sIGJ1
dCB0aGlzIGlzDQoJPmFsbCBhYm91dCByZWR1Y2luZyBieSBtYXliZSA0MC01MCUgYSBidW5jaCBv
ZiBhbG1vc3QgaWRlbnRpY2FsIGNvbnRleHQNCgk+Y29uZmlnIGRhdGEgdG8gc2V0IHVwIHRoZSBp
bnRlcmNlcHRvcnMuIEluIGEgZGVjZW50IHNpemUgYXBwLCB0aGlzIGlzIGENCgk+bG90IG9mIGV4
dHJhIHR5cGluZyBhbmQgbWFpbnRlbmFuY2UuIElmIHRoZSBhZGRpdGlvbmFsIGludGVyY2VwdG9y
cw0KCT5hcHBsaWVkIHRvIG9ubHkgdHJhbnNhY3Rpb25hbCBtZXRob2RzLCB0aGVuIHlvdSB3b3Vs
ZCBvbiBhIGNhc2UgYnkgY2FzZQ0KCT5tZXRob2QgaGF2ZSB0byBkZWNpZGUgd2hldGhlciBvciBu
b3QgdG8gdXNlIFByb3h5RmFjdG9yeUJlYW4gb3INCgk+VHJhbnNhY3Rpb25Qcm94eUZhY3Rvcnks
IG9yIGVsc2UgYWx3YXlzIHVzZSB0aGUgJ3N1cHBvcnRzJyB0cmFuc2FjdGlvbg0KCT5hdHRyaWJ1
dGUsIHdoaWNoIGRvZXNuJ3Qgc2VlbSB0aGF0IGNsZWFuIHRvIG1lLg0KCT4NCgk+UmVnYXJkcywN
Cgk+Q29saW4NCgk+DQoJPmrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF0gd3JvdGU6DQoJPg0KCT4g
DQoJPg0KCT4+SGkgQ29saW4sDQoJPj4NCgk+PllvdXIgaXNzdWUgaXMgY2F1c2VkIGJ5IHRoZSBy
ZWxpYW5jZSBvZiB5b3VyIEhpYmVybmF0ZSBhY2Nlc3MgY29kZSBvbiBIaWJlcm5hdGVJbnRlcmNl
cHRvciBmb3IgY29ycmVjdCByZXNvdXJjZSBvcGVuaW5nIGFuZCBjbG9zaW5nLiBZb3Ugc2hvdWxk
IGFwcGx5IEhpYmVybmF0ZUludGVyY2VwdG9yIGV2ZW4gd2hlbiB1c2luZyBIaWJlcm5hdGVUcmFu
c2FjdGlvbk1hbmFnZXIsIHRvIGJlIGFibGUgdG8gc3dpdGNoIHRvIEp0YVRyYW5zYWN0aW9uTWFu
YWdlciB3aXRob3V0IGhhc3NsZS4NCgk+Pg0KCT4+Tm90ZSB0aGF0IHdoZW4gdXNpbmcgSGliZXJu
YXRlVGVtcGxhdGUgd2l0aCBhbGxvd0NyZWF0ZT10cnVlICh0aGUgZGVmYXVsdCksIGEgbmV3IFNl
c3Npb24gd2lsbCBhdXRvbWF0aWNhbGx5IGVubGlzdCBpdHNlbGYgd2l0aCB0aGUgdHJhbnNhY3Rp
b24gc3luY2hyb25pemF0aW9uIGNhcGFiaWxpdGllcyBvZiBKdGFUcmFuc2FjdGlvbk1hbmFnZXI6
IEl0IHdpbGwgYmUgY3JlYXRlZCBvbiBmaXJzdCBhY2Nlc3MsIHJldXNlZCB0aHJvdWdob3V0IHRo
ZSBjdXJyZW50IHRyYW5zYWN0aW9uLCBhbmQgY2xvc2VkIG9uIHRyYW5zYWN0aW9uIGNvbXBsZXRp
b24uIFRoaXMgZ3VhcmFudGVlcyBjb3JyZWN0IEpWTS1sZXZlbCByZWFkLXdyaXRlIGNhY2hpbmcg
d2l0aCBKVEEsIGFuZCBzZWFtbGVzcyBzd2l0Y2hpbmcgYmV0d2VlbiBIaWJlcm5hdGVUcmFuc2Fj
dGlvbk1hbmFnZXIgYW5kIEp0YVRyYW5zYWN0aW9uTWFuYWdlci4NCgk+Pg0KCT4+SW4geW91ciBj
YXNlLCBJIHdvdWxkIGluZGVlZCBoYXZlIHN1Z2dlc3RlZCB0byBnbyB0aGUgc3RhbmRhcmQgUHJv
eHlGYWN0b3J5QmVhbiByb3V0ZSBhbmQgYXBwbHkgYSBIaWJlcm5hdGVJbnRlcmNlcHRvciBhZnRl
ciB0aGUgVHJhbnNhY3Rpb25JbnRlcmNlcHRvciAoYWZ0ZXIgaXMgc2VtYW50aWNhbGx5IGNsZWFy
ZXIgdGhhbiBiZWZvcmUsIElNTykuIFByb3h5RmFjdG9yeUJlYW4gaXMgdGhlIGNvcnJlY3QgY2hv
aWNlIGZvciBhcHBseWluZyBtdWx0aXBsZSBpbnRlcmNlcHRvcnMuIFRyYW5zYWN0aW9uUHJveHlG
YWN0b3J5QmVhbiBpcyBqdXN0IG1lYW50IGZvciBkZWNsYXJhdGl2ZSB0cmFuc2FjdGlvbiBtYW5h
Z2VtZW50IHdpdGhvdXQgd29ycnlpbmcgYWJvdXQgQU9QIGNvbmNlcHRzLg0KCT4+DQoJPj5PYnZp
b3VzbHksIFRyYW5zYWN0aW9uUHJveHlGYWN0b3J5QmVhbiBjb3VsZCBiZSBleHRlbmRlZCB0byBz
dXBwb3J0IGFkZGl0aW9uYWwgaW50ZXJjZXB0b3JzIGZvciBpdHMgdGFyZ2V0IGJlYW4uIEkgd291
bGQgcmVzdHJpY3QgdGhpcyB0byB0cmFuc2FjdGlvbmFsIG1ldGhvZHMgdGhvdWdoOiBFeGVjdXRp
bmcgb3RoZXIgbWV0aG9kcyB3aXRoIGEgSGliZXJuYXRlIFNlc3Npb24gaXMgcmVhbGx5IG5vdCB0
aGUgdGFzayBvZiBUcmFuc2FjdGlvblByb3h5RmFjdG9yeSBCZWFuIC0gSSBjb25zaWRlciBhIGdl
bmVyaWMgUHJveHlGYWN0b3J5QmVhbiBhcHByb3ByaWF0ZSBoZXJlLiBBbmQgeW91IGNhbiBhbHdh
eXMgZGVmaW5lIG1ldGhvZHMgYXMgdHJhbnNhY3Rpb25hbCBidXQgd2l0aCBwcm9wYWdhdGlvbiAi
c3VwcG9ydHMiIGluc3RlYWQgb2YgInJlcXVpcmVkIi4NCgk+Pg0KCT4+U3VjaCBhIGhvb2sgaW4g
VHJhbnNhY3Rpb25Qcm94eUZhY3RvcnlCZWFuIHNob3VsZCBwcm9iYWJseSBiZSBtb2RlbGxlZCBh
cyAiYWRkaXRpb25hbEludGVyY2VwdG9ycyIgcHJvcGVydHksIHRha2luZyBhIGxpc3Qgb2YgSW50
ZXJjZXB0b3IgaW5zdGFuY2VzLCBnZXR0aW5nIGFwcGxpZWQgYWZ0ZXIgdGhlIGltcGxpY2l0IFRy
YW5zYWN0aW9uSW50ZXJjZXB0b3IgZm9yIHRyYW5zYWN0aW9uYWwgbWV0aG9kcy4gVGhpcyBjYW4g
dGFrZSBhIEhpYmVybmF0ZUludGVyY2VwdG9yIG9yIEpkb0ludGVyY2VwdG9yIG9yIHRoZSBsaWtl
LiBBZ2FpbiwgYW4gYWRkaXRpb25hbCBIaWJlcm5hdGVJbnRlcmNlcHRvcnMgZG9lc24ndCBodXJ0
IGV2ZW4gd2l0aCBIaWJlcm5hdGVUcmFuc2FjdGlvbk1hbmFnZXIgLSBpdCB3aWxsIHNpbXBseSBw
YXJ0aWNpcGF0ZSBpbiB0aGUgZXhpc3RpbmcgdGhyZWFkLWJpbmRpbmcuDQoJPj4NCgk+Pkp1ZXJn
ZW4NCgk+Pg0KCT4+DQoJPj4gICAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KCT4+ICAg
ICAgRnJvbTogQ29saW4gU2FtcGFsZWFudSBbbWFpbHRvOmNvbGlubWwxQGV4aXMuY29tXQ0KCT4+
ICAgICAgU2VudDogVGh1IDkvNC8yMDAzIDExOjEwIFBNDQoJPj4gICAgICBUbzogc3ByaW5nZnJh
bWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCgk+PiAgICAgIENjOg0KCT4+
ICAgICAgU3ViamVjdDogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIHdyYXBwaW5nIGFuIGlu
dGVyY2VwdG9yIGFuZCBIaWJlcm5hdGUgc3BlY2lmaWMgVHJhbnNhY3Rpb25Qcm94eUZhY3RvcnlC
ZWFuDQoJPj4gICAgIA0KCT4+ICAgICANCgk+Pg0KCT4+ICAgICAgSSB3YXMgdXNpbmcgdGhlIFRy
YW5zYWN0aW9uUHJveHlGYWN0b3J5QmVhbiB3aXRoIHRoZQ0KCT4+ICAgICAgSGliZXJuYXRlVHJh
bnNhY3Rpb25NYW5hZ2VyLCBidXQgd2hlbiBJIHN3aXRjaGVkIHRvIHRoZQ0KCT4+ICAgICAgSlRB
VHJhbnNhY3Rpb25NYW5hZ2VyLCBnb3QgYml0dGVuIGJ5IHRoZSBmYWN0IHRoYXQgSSBubyBsb25n
ZXIgaGFkDQoJPj4gICAgICBhbnl0aGluZyBjcmVhdGluZyBhIEhpYmVybmF0ZSBzZXNzaW9uIGFu
ZCBiaW5kaW5nIGl0IHRvIHRoZSBjdXJyZW50DQoJPj4gICAgICB0aHJlYWQsIGFzIEhpYmVybmF0
ZVRyYW5zYWN0aW9uTWFuYWdlciB1c2VkIHRvIGRvIGJ5IGRlZmF1bHQuDQoJPj4gICAgIA0KCT4+
ICAgICAgT25lIHZlcmJvc2Ugc29sdXRpb24gd291bGQgaGF2ZSBiZWVuIHRvIGhhdmUgZ29uZSBi
YWNrIHRvIHRoZSBvbGQNCgk+PiAgICAgIFByb3h5RmFjdG9yeUJlYW4gbWVjaGFuaXNtIGZvciBo
YW5kbGluZyB0cmFuc2FjdGlvbnMsIGFuZCBqdXN0IHN0YWNrIGENCgk+PiAgICAgIEhpYmVybmF0
ZUludGVyY2VwdG9yIGluIGZyb250IG9mIHRoZSB0cmFuc2FjdGlvbiBpbnRlcmNlcHRvci4NCgk+
PiAgICAgDQoJPj4gICAgICBJIGRlY2lkZWQgaW5zdGVhZCB0byBtYWtlIGEgSGliZXJuYXRlIHNw
ZWNpZmljIHZlcmlzb24gb2YNCgk+PiAgICAgIFRyYW5zYWN0aW9uUHJveHlGYWN0b3J5QmVhbi4g
QWxsIGl0IGRvZXMgaXMgdGFrZSBhIG5ldw0KCT4+ICAgICAgSGliZXJuYXRlSW50ZXJjZXB0b3Ig
cHJvcGVydHksIGFuZCBpbiBhZnRlclByb3BlcnRpZXNTZXQgYWRkIHRoZQ0KCT4+ICAgICAgaW50
ZXJjZXB0b3IgYmVmb3JlIHRoZSB0cmFuc2FjdGlvbiBvbmUgKGhvd2V2ZXIsIHVubGlrZSB0aGUg
dHJhbnNhY3Rpb24NCgk+PiAgICAgIG9uZSwgaXQgd2lsbCBleGVjdXRlIG9uIGFsbCBpbnZvY2F0
aW9ucywgc2luY2UgeW91IG1heSB3YW50IHRvIHJ1biBzb21lDQoJPj4gICAgICBtZXRob2RzIHdp
dGggYSBoaWJlcm5hdGUgc2Vzc2lvbiwgYnV0IG5vIHRyYW5zYWN0aW9ucy4NCgk+PiAgICAgICAg
ICAgICAgLy8gYWxsd2F5cyBpbnZva2UgdGhlIEhpYmVybmF0ZSBJbnRlcmNlcHRvcg0KCT4+ICAg
ICAgICAgICAgICBhZGRJbnRlcmNlcHRvcihoaWJlcm5hdGVJbnRlcmNlcHRvcik7DQoJPj4gICAg
ICAgICAgICAgIC4uLiBleGlzdGluZyBjb2RlIHRvIHNldCB1cCB0aGUgVHJhbnNhY3Rpb24gaW50
ZXJjZXB0b3INCgk+PiAgICAgDQoJPj4gICAgICBOb3cgbXkgcXVlc3Rpb25zOg0KCT4+ICAgICAg
MTogaXMgaXQgd29ydGggY2hlY2tpbmcgc29tZXRoaW5nIGxpa2UgdGhpcyBpbj8gSSBtYWRlIGEg
Y3V0IGFuZCBwYXN0DQoJPj4gICAgICBjb3B5IG9mIFRyYW5zYWN0aW9uUHJveHlGYWN0b3J5QmVh
biwgYW5kIGFkZGVkIHRoZSBuZXcgcHJvcGVydHkgYW5kDQoJPj4gICAgICBtb2RpZmllZCB0aGUg
YWZ0ZXJQcm9wZXJ0aWVzU2V0LiBPYnZpb3VzbHksIEkgY291bGQgYWxzbyBoYXZlIGp1c3QNCgk+
PiAgICAgIHN1YmNsYXNzZXMgdGhlIGV4aXN0aW5nIGNsYXNzIGFuZCBvdmVycmlkZW4gYWZ0ZXJQ
cm9wZXJ0aWVzU2V0LiBUaGF0J3MNCgk+PiAgICAgIHByb2JhYmx5IGEgYmV0dGVyIGNob2ljZSwg
YnV0IG1heWJlIGEgYml0IG1vcmUgZGFuZ2Vyb3VzIGlmIHNvbWV0aGluZw0KCT4+ICAgICAgY2hh
bmdlcyBpbiB0aGUgcGFyZW50IG1ldGhvZCB3aGljaCBpcyBubyBsb25nZXIgY2FsbGVkIGF0IGFs
bC4NCgk+PiAgICAgIDI6IGlzIHRoZXJlIGEgYmV0dGVyIHdheSBvZiBkb2luZyB0aGlzPyBJIHN1
cHBvc2VkIEkgY291bGQgaGF2ZSB3cmFwcGVkDQoJPj4gICAgICB0aGUgcHJveHkgaW4gYW5vdGhl
ciBwcm94eSB0byBhZGQgdGhlIGhpYmVybmF0ZSBpbnRlcmNlcHRvci4gVGhpcyB3b3VsZA0KCT4+
ICAgICAgbm90IGhhdmUgcmVxdWlyZWQgYW55IGNvZGUgY2hhbmdlcywgYnV0IHdvdWxkIGhhdmUg
bWFkZSBmb3IgYSBsb3QgbW9yZQ0KCT4+ICAgICAgdHlwaW5nIGluIHRoZSBjb250ZXh0LiAgQW5v
dGhlciBvcHRpb24gd291bGQgYmUgdG8gYWRkIG9wdGlvbmFsIGJlZm9yZQ0KCT4+ICAgICAgYW5k
IGFmdGVyLCAnYWx3YXlzIGludm9rZScgaW50ZXJjZXB0b3IgcHJvcGVydGllcyB0byB0aGUNCgk+
PiAgICAgIFRyYW5zYWN0aW9uUHJveHlGYWN0b3J5QmVhbiwgc28gc29tZXRoaW5nIGxpa2UgdGhp
cyBjYW4gYmUgYWRkZWQuDQoJPj4gICAgIA0KCT4+ICAgICAgUmVnYXJkcywNCgk+PiAgICAgIENv
bGluDQoJPj4gICAgIA0KCT4+DQoJPj4gICANCgk+Pg0KCT4NCgk+DQoJPg0KCT4gDQoJPg0KCQ0K
CQ0KCQ0KDQo=

Re: [Springframework-developer] wrapping an interceptor and Hibernate specific TransactionProxyFactoryBean

[Colin S. <col...@ex...>]

I see this hasn't made it into cvs yet. No hurry there, but I was just 
thinking that in terms of making a generic mechanism out of this class, 
it may make more sense to allow both 'pre' and 'post' interceptors 
around the implicit transaction interceptor. Some kinds of interception, 
such as performance logging, probably belong before, for example...


jürgen höller [werk3AT] wrote:

>Hi Colin,
>
>Actually, I completely agree: It isn't even possible to apply additional interceptors just for transactional methods, as the transaction semantics of a method are determined within the TransactionInterceptor implementation where we can't hook any additional interceptors in. So both in terms of clearness and simple implementation, let's introduce an "additionalInterceptors" property of type "Interceptor[]", getting applied _after_ the TransactionInterceptor. I've just implemented that; I'll check it in later this afternoon.
>
>Juergen
>
>
>-----Original Message-----
>From: Colin Sampaleanu [mailto:col...@ex...]
>Sent: Sunday, September 28, 2003 10:30 PM
>To: jürgen höller [werk3AT]
>Cc: spr...@li...
>Subject: Re: [Springframework-developer] wrapping an interceptor and
>Hibernate specific TransactionProxyFactoryBean
>
>
>Jürgen,
>
>(Now that you are back I can write some more 'frivolous' emails :-) ).
>
>W/regards to adding additional interceptor support to 
>TransactionProxyFactoryBean, I'm not sure I fully agree that it's 
>inherently better or 'cleaner' to apply these to transactional methods 
>only. That is, when thinking, 'what is TransactionProxyFactoryBean (in 
>this modified version)?', you could consider it as a variant of 
>ProxyFactoryBean that implicitly applies a Transaction interceptor 
>(before, after, or in between other interceptors, as we decide makes the 
>most sense). Those other interceptors can themselves decide if they 
>apply, as with ProxyFactoryBean...
>
>There is a usecase for calling Hibernate code (needing a session), 
>without needing transactions, and that's mostly for read-only data 
>(where there is no need for isolation provided by a transaction). I 
>realize that I could just use a regular ProxyFactoryBean, but this is 
>all about reducing by maybe 40-50% a bunch of almost identical context 
>config data to set up the interceptors. In a decent size app, this is a 
>lot of extra typing and maintenance. If the additional interceptors 
>applied to only transactional methods, then you would on a case by case 
>method have to decide whether or not to use ProxyFactoryBean or 
>TransactionProxyFactory, or else always use the 'supports' transaction 
>attribute, which doesn't seem that clean to me.
>
>Regards,
>Colin
>
>jürgen höller [werk3AT] wrote:
>
>  
>
>>Hi Colin,
>>
>>Your issue is caused by the reliance of your Hibernate access code on HibernateInterceptor for correct resource opening and closing. You should apply HibernateInterceptor even when using HibernateTransactionManager, to be able to switch to JtaTransactionManager without hassle.
>>
>>Note that when using HibernateTemplate with allowCreate=true (the default), a new Session will automatically enlist itself with the transaction synchronization capabilities of JtaTransactionManager: It will be created on first access, reused throughout the current transaction, and closed on transaction completion. This guarantees correct JVM-level read-write caching with JTA, and seamless switching between HibernateTransactionManager and JtaTransactionManager.
>>
>>In your case, I would indeed have suggested to go the standard ProxyFactoryBean route and apply a HibernateInterceptor after the TransactionInterceptor (after is semantically clearer than before, IMO). ProxyFactoryBean is the correct choice for applying multiple interceptors. TransactionProxyFactoryBean is just meant for declarative transaction management without worrying about AOP concepts.
>>
>>Obviously, TransactionProxyFactoryBean could be extended to support additional interceptors for its target bean. I would restrict this to transactional methods though: Executing other methods with a Hibernate Session is really not the task of TransactionProxyFactory Bean - I consider a generic ProxyFactoryBean appropriate here. And you can always define methods as transactional but with propagation "supports" instead of "required".
>>
>>Such a hook in TransactionProxyFactoryBean should probably be modelled as "additionalInterceptors" property, taking a list of Interceptor instances, getting applied after the implicit TransactionInterceptor for transactional methods. This can take a HibernateInterceptor or JdoInterceptor or the like. Again, an additional HibernateInterceptors doesn't hurt even with HibernateTransactionManager - it will simply participate in the existing thread-binding.
>>
>>Juergen
>>
>>
>>	-----Original Message----- 
>>	From: Colin Sampaleanu [mailto:col...@ex...] 
>>	Sent: Thu 9/4/2003 11:10 PM 
>>	To: spr...@li... 
>>	Cc: 
>>	Subject: [Springframework-developer] wrapping an interceptor and Hibernate specific TransactionProxyFactoryBean
>>	
>>	
>>
>>	I was using the TransactionProxyFactoryBean with the
>>	HibernateTransactionManager, but when I switched to the
>>	JTATransactionManager, got bitten by the fact that I no longer had
>>	anything creating a Hibernate session and binding it to the current
>>	thread, as HibernateTransactionManager used to do by default.
>>	
>>	One verbose solution would have been to have gone back to the old
>>	ProxyFactoryBean mechanism for handling transactions, and just stack a
>>	HibernateInterceptor in front of the transaction interceptor.
>>	
>>	I decided instead to make a Hibernate specific verison of
>>	TransactionProxyFactoryBean. All it does is take a new
>>	HibernateInterceptor property, and in afterPropertiesSet add the
>>	interceptor before the transaction one (however, unlike the transaction
>>	one, it will execute on all invocations, since you may want to run some
>>	methods with a hibernate session, but no transactions.
>>	        // allways invoke the Hibernate Interceptor
>>	        addInterceptor(hibernateInterceptor);
>>	        ... existing code to set up the Transaction interceptor
>>	
>>	Now my questions:
>>	1: is it worth checking something like this in? I made a cut and past
>>	copy of TransactionProxyFactoryBean, and added the new property and
>>	modified the afterPropertiesSet. Obviously, I could also have just
>>	subclasses the existing class and overriden afterPropertiesSet. That's
>>	probably a better choice, but maybe a bit more dangerous if something
>>	changes in the parent method which is no longer called at all.
>>	2: is there a better way of doing this? I supposed I could have wrapped
>>	the proxy in another proxy to add the hibernate interceptor. This would
>>	not have required any code changes, but would have made for a lot more
>>	typing in the context.  Another option would be to add optional before
>>	and after, 'always invoke' interceptor properties to the
>>	TransactionProxyFactoryBean, so something like this can be added.
>>	
>>	Regards,
>>	Colin
>>	
>>
>>    
>>
>
>
>
>  
>

[Springframework-developer] Any sort of defined policy w/regards to tab/space usage and indentation?

[Colin S. <col...@ex...>]

I notice that most of the codebase in Spring uses hard tabs as opposed 
to spaces for indentation. From looking at some comment text which does 
have some embedded spaces, as far as I can tell the assumption is that 
tabs equate to 4 chars, although most of the code itself does not seem 
to make this assumption?

Is there any sort of project policy or guideline on this? i.e. something 
like 'all code must use hard tabs, and align elements only with tabs', 
etc.? I can hopefully work with any policy, but I'd just like to know if 
one exists... (although if I am forced to use hard tabs I would actually 
have to set up another Eclipse workspace, right now my tab key puts out 
spaces).

fwiw, I have personally found that hard tabs are somewhat of a disaster 
(or at least a problem) in many team environents. In my teams, it's 
generally the one rule we apply with no exceptions, "no hard tabs". The 
problem is that while hard tabs have the ideal benefit of allowing users 
to indent to whatever size they like, in practice people seem to not 
have the discipline to stick to using tabs only, or their editor of the 
moment doesn't allow them to set the tab size to something else easilly, 
so spaces creep in. Once that happens to any extent, the code looks 
broken to anybody else using another tab size.

Regards,
Colin

[Springframework-developer] Nested bean bug in BugWrapperImpl

[Trevor C. <pr...@se...>]

I've finished our project conversion to the new version of Spring, and am
now doing major testing.  During this, I have found a bug in
org.springframework.beans.BeanWrapperImpl relating to how nested beans are
handled (due to caching inside the BeanWrapperImpl).

I have created special classes to handle phone numbers following our local
(Canada) standards, which are (###)###-#### so the object contains 3
properties (area code, prefix, suffix).  I also overrode equals to perform a
semantic comparison.  If all 3 fields match, the phone numbers are equal.
In our form for editing contacts, we have 2 phone numbers, one for voice, 1
for fax.  So the 2 suffix pieces are referenced as "contact.voice.suffix"
and "contact.fax.suffix".  We require a voice number, but fax numbers are
optional.

The problem arises when a new (unpopulated) form is submitted.  The values
for all the fields in both phone numbers are initialized to "".  Because
HttpServletRequest parameters are not guarenteed to be in any order, the fax
field is processed first.  The bean wrapper does not find an existing nested
bean wrapper, so creates one around the fax number.  The voice number is
then processed.  It looks in the nested bean wrapper cache for a phone
number which equals itself.  Since they are semantically equal, it retrieves
the bean wrapper for the fax number and populates it.  This means that I
have a voice number of (123)456-.... and a fax number of (...)...-7890 .
This fails validation since they are NOT proper phone numbers.

It took a while to determine exactly why this problem occured and I've
written a test which exposes it in
BeanWrapperTestSuite.testNestedBeanSetterMethod .  I'm not sure what the
best way to fix this is, so maybe someone who's familiar with the bean
package can take a look (Rod/Juergen).  Commenting out line 442 of the
BeanWrapperImpl fixes it, but it then breaks
CustomEditorTestSuite.testCustomEditorForSingleNestedProperty .

I've submitted the new test to expose the problem, but I've commented it out
since it will break the build.  Whoever is familiar with this can take a
look, but we should uncomment this test long term since it should normally
work.

Trevor D. Cook

[Springframework-developer] (no subject)

[<tri...@tr...>]

Rod & All,

Spring got a nice plugg from Gavin King in the interview on the ServerSide that
has just been posted. ( http://www.theserverside.com/events/index.jsp )

Q: One of the reasons why transparent persistence may not be getting as much
attention is because a lot people just aren’t writing domain models. Why do you
think people are not yet adopting such a good object-oriented paradigm yet?

A: Firstly, not every application needs a domain model. There are lots of
applications for which a domain model is absolute overkill. There are lots of
applications for which a view of sets of data coming out of the database is
absolutely appropriate. And there’s all kinds of good tools in Java, in the open
source community, for writing that kind of application well, things like the
Spring Framework give you great ways of getting away a bit from very messy JDBC
code, but writing those kind of applications which pull some stuff form the
database and display it on the screen, or insert a row of data into the
database. You don’t need a domain model to do those kinds of things.

Thomas

[Springframework-developer] How to implement a service?

[Rajeev K. <Ra...@cu...>]

What is the best way to implement a service in the Spring framework?  =
The service should be accessible from both the web tier and the ejb =
tier, have lifecycle methods to initialize and shutdown,  and should =
have some sort of dependency check on other services, it may need.  Has =
anyone done this using the spring framework?=20

Rajeev Kaul

Re: [Springframework-developer] Re: [Springframework-user] ClassPathXmlApplicationContext

[Colin S. <col...@ex...>]

Ughhh, please forgive the gratuitous use of StringTokenizer below, it's 
gone now. I promise most of my code does take advantage of available 
java library functions like Sring.replace()   :-)


Colin Sampaleanu wrote:

> I actually added two convenience methods to ClassLoadUtils, for making 
> this sort of stuff easier:
>
>    /**
>     * Given an input class object, returns a string which consists of 
> the class's package
>     * name as a pathname, i.e., a leading '/' is added, and all dots 
> ('.') are replaced by
>     * slashes ('/'). A trailing slash is <b>not</b> added.
>     * @param clazz the input class
>     * @return a path which represents the package name, including a 
> leading slash
>     */
>    public static String classPackageAsResourcePath(Class clazz) {
>        StringBuffer retval = new StringBuffer("/");
>        if (clazz == null)
>            return retval.toString();
>        StringTokenizer st = new 
> StringTokenizer(clazz.getPackage().getName(), ".");
>        while (st.hasMoreTokens()) {
>            retval.append(st.nextToken());
>            if (st.hasMoreTokens())
>                retval.append("/");
>        }
>        return retval.toString();
>    }
>
>
>    /**
>     * Returns a path suitable for use with {@see Class.getResource} 
> build by taking
>     * the package of the specified class file, converting all dots 
> ('.') to slashes
>     * ('/'), adding a trailing slash, and concatenating the specified 
> resource name
>     * to this. As such, this function may be used to build a path 
> suitable for loading
>     * a resource file that is in the same package as a class file.
>     * @param clazz the Class whose package will be used as the base.
>     * @param resourceName the resource name to append. A leading slash 
> is optional.
>     * @return The built-up resource path.
>     */
>    public static String addResourcePathToPackagePath(Class clazz, 
> String resourceName) {
>        if (!resourceName.startsWith("/"))
>            return classPackageAsResourcePath(clazz) + "/" + resourceName;
>        else
>            return classPackageAsResourcePath(clazz) + resourceName;
>    }
>
>
> These should make having a context definition (or any other resource) 
> that stays in the same package as a certain class trivial. E.g.
>
> import ClassLoaderUtils;
> public class MyClass {
>  private static String RESOURCE = 
> ClassLoaderUtils.addResourcePathToPackagePath(MyClass.class, 
> "myresource.xml";
>
>  ...
> }
>
>
> Regards,
> Colin
>
>
>
> Colin Sampaleanu wrote:
>
>> Yes, Class.getResourceAsStream will attempt to load out of the 
>> package where the code is executing, but don't forget, it is not your 
>> code (in your package), which would be calling getResourceAsStream, 
>> it is Spring's code, in its own package. It's actually even more 
>> complicated then that, because the call actually ends up going to 
>> Springs's ClassLoaderUtils, where the loading happens via a
>>        InputStream in = 
>> Thread.currentThread().getContextClassLoader().getResourceAsStream(name); 
>>
>> This is so that if you are in an environment such as a J2EE 
>> application server, where the context classpath has been set 
>> appropriately by the appserver in the current thread, the right 
>> classloader ends up loading the data. If Spring didn't do this, in 
>> some app server environments, a spring lib instance in the 
>> appserver's own support directory would be used as the basis of the 
>> classpath to search, and would never see the resources in the 
>> classloader farther down in the hierarchy.
>>
>> So what I would suggest doing is something like this:
>>
>> Define a utility method somewhere:
>>    /**
>>     * Given an input class object, returns a string which consists of 
>> the class's package
>>     * name as a pathname, i.e., a leading '/' is added, and all dots 
>> ('.') are replaced by
>>     * slashes ('/')
>>     * @param clazz the input class
>>     * @return a path which represents the package name, including a 
>> leading slash
>>     */
>>    public static String classPackageAsPath(Class clazz) {
>>        StringBuffer retval = new StringBuffer("/");
>>        if (clazz == null)
>>            return retval.toString();
>>        StringTokenizer st = new 
>> StringTokenizer(clazz.getPackage().getName(), ".");
>>        while (st.hasMoreTokens()) {
>>            retval.append(st.nextToken());
>>            if (st.hasMoreTokens())
>>                retval.append("/");
>>        }
>>        System.out.println("returning: " + retval.toString());
>>        return retval.toString();
>>    }
>>
>> then when you need to load resources relative to a class's package, 
>> do something like this:
>>
>>  private static final String CONTEXT =
>>    FileUtil.classPackageAsPath(BasicMappedPersistenceTest.class)
>>      + "/BasicMappedPersistenceTestContext.xml";
>>
>>   ....
>>      appContext = new ClassPathXmlApplicationContext(CONTEXT);
>>
>>
>>
>> As to whether this belongs in the user list or the dev list, it's 
>> somewhat of a grey area. That is, my explanation above definitely 
>> belongs in the user list, but this discussion could certainly have 
>> lead (or may lead) to further discussion about how to improve this 
>> area of spring, which is best handled in the dev list.
>>
>>
>> Regards,
>> Colin
>>
>>
>> Keith Donald wrote:
>>
>>> Is it correct to always prepend a "/" to a resource path passed into
>>> ClassPathXmlApplicationContext?  This behaivior forces me to hard-code
>>> fully-qualified references to my application context xml files.  
>>> Instead,
>>> I'd like to be able to pass in a relative name and have
>>> getResourceAsStream() attempt to load the resource out of the 
>>> package where
>>> the code is executing (which is the default behaivior of
>>> Class.getResourceAsStream().)
>>>
>>> For example, I have a context located in my classpath at:
>>> /com/csi/cogids/console/console-context.xml.  To load it, I must 
>>> pass that
>>> full path to ClassPathApplicationContext().  Now say two weeks later I
>>> re-factor and re-locate this code to another package--I have to make 
>>> sure I
>>> update the reference.  I'd rather just be able to say: new
>>> ClassPathApplicationContext("console-context.xml") and have it by 
>>> default
>>> look in the current executing class's package directory.
>>>
>>> Should I mail stuff like this to the developer list?
>>>
>>> Thanks,
>>> Keith
>>

[Springframework-developer] Re: [Springframework-user] ClassPathXmlApplicationContext

[Colin S. <col...@ex...>]

I actually added two convenience methods to ClassLoadUtils, for making 
this sort of stuff easier:

    /**
     * Given an input class object, returns a string which consists of 
the class's package
     * name as a pathname, i.e., a leading '/' is added, and all dots 
('.') are replaced by
     * slashes ('/'). A trailing slash is <b>not</b> added.
     * @param clazz the input class
     * @return a path which represents the package name, including a 
leading slash
     */
    public static String classPackageAsResourcePath(Class clazz) {
        StringBuffer retval = new StringBuffer("/");
        if (clazz == null)
            return retval.toString();
        StringTokenizer st = new 
StringTokenizer(clazz.getPackage().getName(), ".");
        while (st.hasMoreTokens()) {
            retval.append(st.nextToken());
            if (st.hasMoreTokens())
                retval.append("/");
        }
        return retval.toString();
    }
 
 
    /**
     * Returns a path suitable for use with {@see Class.getResource} 
build by taking
     * the package of the specified class file, converting all dots 
('.') to slashes
     * ('/'), adding a trailing slash, and concatenating the specified 
resource name
     * to this. As such, this function may be used to build a path 
suitable for loading
     * a resource file that is in the same package as a class file.
     * @param clazz the Class whose package will be used as the base.
     * @param resourceName the resource name to append. A leading slash 
is optional.
     * @return The built-up resource path.
     */
    public static String addResourcePathToPackagePath(Class clazz, 
String resourceName) {
        if (!resourceName.startsWith("/"))
            return classPackageAsResourcePath(clazz) + "/" + resourceName;
        else
            return classPackageAsResourcePath(clazz) + resourceName;
    }


These should make having a context definition (or any other resource) 
that stays in the same package as a certain class trivial. E.g.

import ClassLoaderUtils;
public class MyClass {
  private static String RESOURCE = 
ClassLoaderUtils.addResourcePathToPackagePath(MyClass.class, 
"myresource.xml";

  ...
}


Regards,
Colin



Colin Sampaleanu wrote:

> Yes, Class.getResourceAsStream will attempt to load out of the package 
> where the code is executing, but don't forget, it is not your code (in 
> your package), which would be calling getResourceAsStream, it is 
> Spring's code, in its own package. It's actually even more complicated 
> then that, because the call actually ends up going to Springs's 
> ClassLoaderUtils, where the loading happens via a
>        InputStream in = 
> Thread.currentThread().getContextClassLoader().getResourceAsStream(name);
> This is so that if you are in an environment such as a J2EE 
> application server, where the context classpath has been set 
> appropriately by the appserver in the current thread, the right 
> classloader ends up loading the data. If Spring didn't do this, in 
> some app server environments, a spring lib instance in the appserver's 
> own support directory would be used as the basis of the classpath to 
> search, and would never see the resources in the classloader farther 
> down in the hierarchy.
>
> So what I would suggest doing is something like this:
>
> Define a utility method somewhere:
>    /**
>     * Given an input class object, returns a string which consists of 
> the class's package
>     * name as a pathname, i.e., a leading '/' is added, and all dots 
> ('.') are replaced by
>     * slashes ('/')
>     * @param clazz the input class
>     * @return a path which represents the package name, including a 
> leading slash
>     */
>    public static String classPackageAsPath(Class clazz) {
>        StringBuffer retval = new StringBuffer("/");
>        if (clazz == null)
>            return retval.toString();
>        StringTokenizer st = new 
> StringTokenizer(clazz.getPackage().getName(), ".");
>        while (st.hasMoreTokens()) {
>            retval.append(st.nextToken());
>            if (st.hasMoreTokens())
>                retval.append("/");
>        }
>        System.out.println("returning: " + retval.toString());
>        return retval.toString();
>    }
>
> then when you need to load resources relative to a class's package, do 
> something like this:
>
>  private static final String CONTEXT =
>    FileUtil.classPackageAsPath(BasicMappedPersistenceTest.class)
>      + "/BasicMappedPersistenceTestContext.xml";
>
>   ....
>      appContext = new ClassPathXmlApplicationContext(CONTEXT);
>
>
>
> As to whether this belongs in the user list or the dev list, it's 
> somewhat of a grey area. That is, my explanation above definitely 
> belongs in the user list, but this discussion could certainly have 
> lead (or may lead) to further discussion about how to improve this 
> area of spring, which is best handled in the dev list.
>
>
> Regards,
> Colin
>
>
> Keith Donald wrote:
>
>> Is it correct to always prepend a "/" to a resource path passed into
>> ClassPathXmlApplicationContext?  This behaivior forces me to hard-code
>> fully-qualified references to my application context xml files.  
>> Instead,
>> I'd like to be able to pass in a relative name and have
>> getResourceAsStream() attempt to load the resource out of the package 
>> where
>> the code is executing (which is the default behaivior of
>> Class.getResourceAsStream().)
>>
>> For example, I have a context located in my classpath at:
>> /com/csi/cogids/console/console-context.xml.  To load it, I must pass 
>> that
>> full path to ClassPathApplicationContext().  Now say two weeks later I
>> re-factor and re-locate this code to another package--I have to make 
>> sure I
>> update the reference.  I'd rather just be able to say: new
>> ClassPathApplicationContext("console-context.xml") and have it by 
>> default
>> look in the current executing class's package directory.
>>
>> Should I mail stuff like this to the developer list?
>>
>> Thanks,
>> Keith
>

[Springframework-developer] added .cvsignore file

[Colin S. <col...@ex...>]

I added a proper .cvsignore file to the project root. If you add 
anything to the build which creates dirs or files in the root,  make 
sure to add a wildcard in there which excludes those dirs/files.

Regards,
Colin

RE: [Springframework-developer] Multipart committed

[Alef A. \(JTeam\) <al...@jt...>]

Sounds good,

In one of our projects I have to add fileupload functionality soon, so
as soon as I have a chance, I'll have a look at it!

Alef

-----Oorspronkelijk bericht-----
Van: spr...@li...
[mailto:spr...@li...] Namens
Trevor Cook
Verzonden: Tuesday, September 30, 2003 3:05 AM
Aan: j=FCrgen h=F6ller [werk3AT]; al...@jt...; Spring Developers
Onderwerp: [Springframework-developer] Multipart committed


I've just committed the multipart stuff to cvs.  It currently should NOT
change any existing projects.  In order to "activate" it you will need
to explicitly turn it on as outlined below. <WARNING>Note that these
procedures for enabling it are subject to change, as is the underlying
implementation.  Please consider the entire multipart implementation
highly volatile until further notice.</WARNING>

With that out of the way, I'll detail how everything works.  I've
seperated it into 3 parts, the "multipart api", changes to Spring, and
the jakarta commons fileupload implementation.  Note that I've provided
what I consider a sufficient level of documentation in the javadocs, so
if anyone referring to those finds them lacking, please let me know
(since I think improving our docs is/should be a big push right now).
I'd also appreciate any help/suggestions on how to unit test these,
since I'm not exactly sure how to proceed with them (due to how to make
mock request, etc.).


Multipart API
-------------
The api contains 3 classes and 1 exception:
- org.springframework.web.servlet.MultipartResolver
- org.springframework.web.servlet.MultipartHttpServletRequest
- org.springframework.web.servlet.MultipartFile
- org.springframework.web.servlet.MultipartException

Most of the details for these are in the javadocs.  The interfaces are
in the org.springframework.web.servlet package to follow the pattern set
by the LocaleResolver/ThemeResolver.

I made the content for the MultipartFile a byte array (byte[]) and
avoided using File/InputStream.  This seems to make it simpler and more
consistent. If you need to retrieve the original filename, you will have
to use a MultipartFile object in your bean.  Based on my personal
feelings and comments from others, I think using a File is inappropriate
(except "under the covers" when necessary), and the only other
alternative is to create some form of "NamedByteArray".  Since any
special class containing a filename will introduce a Spring dependancy,
I think MultipartFile is as good as creating an additional class.

The methods in the MultipartHttpServletRequest were designed to mimic
their HttpServletRequest parameter counterparts.  The only one not
matched currently is "getFileValues()" to cover the possiblity of a
MultipartFile array.  What are the opinions on supporting a
MultipartFile array.  I personally have never used them because they add
a ton of extra complexity. With Spring, it might not be so bad now, but
I'd have to see a need.  If we do see a potential for using them later,
we could create the interface declaration now, and use a nop exception
in the implementation until we get it working.  Personally,  I'd leave
it out, I'm mentioning it in case others see/have real uses for it.


Changes to Spring
-----------------
Just to reiterate, none of these changes should mess up any existing
Spring-based apps.  Also, all the Spring code is based on the above api.
None of it references any of the "commons" implementation, so it should
be fully pluggable for other implementations.

org.springframework.web.servlet.DispatcherServlet looks for a bean named
"multipartResolver" and if it doesn't find one, it does NOT create a
default (it uses null).  The reason for this is because we don't want to
wrap normal request's so that we can use "request instanceof
MultipartHttpServletRequest".  If it contains a multipartResolver, it
wraps the request ONLY if "multipartResolver.isMultipart(request)" is
true.  This wrapped request is then used for the balance of the
doService method, and then cleanup is performed.  This means that if no
MultipartResolver is set, no multipart wrapping/processing will occur.

org.springframework.web.bind.ServletRequestDataBinder has a new
constructor which takes the request as a parameter.  This is to allow
special multipart property editors to be assigned.  I tried various
methods of having the binder simply use the normal getParameter method
to parse the content, but it proved very clumsy and didn't meet all
needs (like getting filename).  In the end it appears that the property
editor needs access to the request so it can map "getParamater(String)"
results to "getFile(String)" results. This behaviour is documented in
the MultipartResolver.resolveMultipart(HttpServletRequest)" javadocs.
This means that wherever you currently create a ServletRequestDataBinder
you need to use the new constructor if you want it to be able to use the
multipart handling.

Unless somebody can see major flaws in using this approach or has a more
elegant solution, I would recommend deleting the current constructor and
have all methods use the new constructor which receives the request.
The way the constructor is written, if a multipartresolver isn't set,
things occur the same way they do now.  Basically, using the new
constructor won't change anything unless multipart handling is used (in
which case we need this constructor anyway).

"getMultipartResolver(HttpServletRequest)" was added to
org.springframework.web.servlet.support.RequestContextUtils.  This is
just a utility method and is only used (so far) by
ServletRequestDataBinder.

I created a few "general use" multipart classes (all of which are in the
org.springframework.web.servlet.multipart package).  The main one is
MultipartHttpServletRequestImpl.  It should work for most multipart
implementations unless someone has very special requirements (since most
"real work" occurs in the resolver).  I also created 3 property editors
(which are all used by the commons implementation, but can be used by
others as well). MultipartBytePropertyEditor supports "byte[]" and maps
the content
(MultipartFile.getBytes()) as the value.  MultipartFilePropertyEditor
supports "MultipartFile" and maps the whole MultipartFile object as the
value.  MultipartStringPropertyEditor supports String and maps the
filename
(MultipartFile.getFileName()) as the value.  All 3 are reusable for any
other multipart implementations, and it should be simple to create
custom property editors if desired (like File, etc.).

The String editor is the one I question a little, so I'd appreciate
feedback.  Basically, if you don't have a String editor, then the
"key=3Dvalue" requirement means you will get weird values in your =
objects.
Placing the file content in a String doesn't seem to make sense either.
So basically, this seemed like the "better of evils" (a great design
justification :) ).


Jakarta Commons FileUpload implementation
-----------------------------------------
The implementation only requires 2 special classes, CommonsMultipartFile
and CommonsMultipartResolver (both in
org.springframework.web.servlet.multipart
package).  CommonsMultipartFile is very basic, just a simple wrapper
around org.apache.commons.fileupload.FileItem .

CommonsMultipartResolver uses commons to process isMultipart requests,
and it registers the 3 editors mentioned above.  The actual
resolveMultipart contains special handling to check each FileItem in
order to ensure "regular field" arrays are handled correctly.  It
provides 4 configuration settings which can be set in the context file,
etc. which are specific to how the commons package works.  The default
values are outlined in the javadocs, but I'll list them here for
discussion:

maximumFileSize =3D -1 (no file size limit)
maximumInMemorySize =3D 1024 (1 kb)
temporaryFilePath =3D System.getProperty("java.io.tmpdir")

These are all consistent with the actual commons defaults.  The only
questionable one is the "maximumFileSize" being unlimited (since this
could be a DOS/DDOS hole as Colin mentioned earlier).  However, I don't
think we can choose an arbitrary default that will work for a "majority"
of uses.  I would recommend that we simply leave it as is and let the
user set it, but I'm open to suggestions.


Conclusion/Questions
--------------------
I have already converted our big app and everything works fine with
these classes, including validation (we actually check the byte[] to
make sure it is an image in one case).  Once we finalize the api and
default implementation, what should Spring's default be, either no
multipart handling or the commons implementation?  Personally, I think
having it on by default makes sense, since you'll never use it unless
you receive a form which is multipart (in which case you need it
anyway).  What does everyone else think?


Trevor D. Cook



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Multipart committed

[Trevor C. <pr...@se...>]

I've just committed the multipart stuff to cvs.  It currently should NOT
change any existing projects.  In order to "activate" it you will need to
explicitly turn it on as outlined below.
<WARNING>Note that these procedures for enabling it are subject to change,
as is the underlying implementation.  Please consider the entire multipart
implementation highly volatile until further notice.</WARNING>

With that out of the way, I'll detail how everything works.  I've seperated
it into 3 parts, the "multipart api", changes to Spring, and the jakarta
commons fileupload implementation.  Note that I've provided what I consider
a sufficient level of documentation in the javadocs, so if anyone referring
to those finds them lacking, please let me know (since I think improving our
docs is/should be a big push right now).  I'd also appreciate any
help/suggestions on how to unit test these, since I'm not exactly sure how
to proceed with them (due to how to make mock request, etc.).


Multipart API
-------------
The api contains 3 classes and 1 exception:
- org.springframework.web.servlet.MultipartResolver
- org.springframework.web.servlet.MultipartHttpServletRequest
- org.springframework.web.servlet.MultipartFile
- org.springframework.web.servlet.MultipartException

Most of the details for these are in the javadocs.  The interfaces are in
the org.springframework.web.servlet package to follow the pattern set by the
LocaleResolver/ThemeResolver.

I made the content for the MultipartFile a byte array (byte[]) and avoided
using File/InputStream.  This seems to make it simpler and more consistent.
If you need to retrieve the original filename, you will have to use a
MultipartFile object in your bean.  Based on my personal feelings and
comments from others, I think using a File is inappropriate (except "under
the covers" when necessary), and the only other alternative is to create
some form of "NamedByteArray".  Since any special class containing a
filename will introduce a Spring dependancy, I think MultipartFile is as
good as creating an additional class.

The methods in the MultipartHttpServletRequest were designed to mimic their
HttpServletRequest parameter counterparts.  The only one not matched
currently is "getFileValues()" to cover the possiblity of a MultipartFile
array.  What are the opinions on supporting a MultipartFile array.  I
personally have never used them because they add a ton of extra complexity.
With Spring, it might not be so bad now, but I'd have to see a need.  If we
do see a potential for using them later, we could create the interface
declaration now, and use a nop exception in the implementation until we get
it working.  Personally,  I'd leave it out, I'm mentioning it in case others
see/have real uses for it.


Changes to Spring
-----------------
Just to reiterate, none of these changes should mess up any existing
Spring-based apps.  Also, all the Spring code is based on the above api.
None of it references any of the "commons" implementation, so it should be
fully pluggable for other implementations.

org.springframework.web.servlet.DispatcherServlet looks for a bean named
"multipartResolver" and if it doesn't find one, it does NOT create a default
(it uses null).  The reason for this is because we don't want to wrap normal
request's so that we can use "request instanceof
MultipartHttpServletRequest".  If it contains a multipartResolver, it wraps
the request ONLY if "multipartResolver.isMultipart(request)" is true.  This
wrapped request is then used for the balance of the doService method, and
then cleanup is performed.  This means that if no MultipartResolver is set,
no multipart wrapping/processing will occur.

org.springframework.web.bind.ServletRequestDataBinder has a new constructor
which takes the request as a parameter.  This is to allow special multipart
property editors to be assigned.  I tried various methods of having the
binder simply use the normal getParameter method to parse the content, but
it proved very clumsy and didn't meet all needs (like getting filename).  In
the end it appears that the property editor needs access to the request so
it can map "getParamater(String)" results to "getFile(String)" results.
This behaviour is documented in the
MultipartResolver.resolveMultipart(HttpServletRequest)" javadocs.  This
means that wherever you currently create a ServletRequestDataBinder you need
to use the new constructor if you want it to be able to use the multipart
handling.

Unless somebody can see major flaws in using this approach or has a more
elegant solution, I would recommend deleting the current constructor and
have all methods use the new constructor which receives the request.  The
way the constructor is written, if a multipartresolver isn't set, things
occur the same way they do now.  Basically, using the new constructor won't
change anything unless multipart handling is used (in which case we need
this constructor anyway).

"getMultipartResolver(HttpServletRequest)" was added to
org.springframework.web.servlet.support.RequestContextUtils.  This is just a
utility method and is only used (so far) by ServletRequestDataBinder.

I created a few "general use" multipart classes (all of which are in the
org.springframework.web.servlet.multipart package).  The main one is
MultipartHttpServletRequestImpl.  It should work for most multipart
implementations unless someone has very special requirements (since most
"real work" occurs in the resolver).  I also created 3 property editors
(which are all used by the commons implementation, but can be used by others
as well).
MultipartBytePropertyEditor supports "byte[]" and maps the content
(MultipartFile.getBytes()) as the value.  MultipartFilePropertyEditor
supports "MultipartFile" and maps the whole MultipartFile object as the
value.  MultipartStringPropertyEditor supports String and maps the filename
(MultipartFile.getFileName()) as the value.  All 3 are reusable for any
other multipart implementations, and it should be simple to create custom
property editors if desired (like File, etc.).

The String editor is the one I question a little, so I'd appreciate
feedback.  Basically, if you don't have a String editor, then the
"key=value" requirement means you will get weird values in your objects.
Placing the file content in a String doesn't seem to make sense either.  So
basically, this seemed like the "better of evils" (a great design
justification :) ).


Jakarta Commons FileUpload implementation
-----------------------------------------
The implementation only requires 2 special classes, CommonsMultipartFile and
CommonsMultipartResolver (both in org.springframework.web.servlet.multipart
package).  CommonsMultipartFile is very basic, just a simple wrapper around
org.apache.commons.fileupload.FileItem .

CommonsMultipartResolver uses commons to process isMultipart requests, and
it registers the 3 editors mentioned above.  The actual resolveMultipart
contains special handling to check each FileItem in order to ensure "regular
field" arrays are handled correctly.  It provides 4 configuration settings
which can be set in the context file, etc. which are specific to how the
commons package works.  The default values are outlined in the javadocs, but
I'll list them here for discussion:

maximumFileSize = -1 (no file size limit)
maximumInMemorySize = 1024 (1 kb)
temporaryFilePath = System.getProperty("java.io.tmpdir")

These are all consistent with the actual commons defaults.  The only
questionable one is the "maximumFileSize" being unlimited (since this could
be a DOS/DDOS hole as Colin mentioned earlier).  However, I don't think we
can choose an arbitrary default that will work for a "majority" of uses.  I
would recommend that we simply leave it as is and let the user set it, but
I'm open to suggestions.


Conclusion/Questions
--------------------
I have already converted our big app and everything works fine with these
classes, including validation (we actually check the byte[] to make sure it
is an image in one case).  Once we finalize the api and default
implementation, what should Spring's default be, either no multipart
handling or the commons implementation?  Personally, I think having it on by
default makes sense, since you'll never use it unless you receive a form
which is multipart (in which case you need it anyway).  What does everyone
else think?


Trevor D. Cook

Re: [lists] RE: [Springframework-developer] Slogan

[Darren D. <da...@da...>]

On Monday 29 September 2003 09:55, Rod Johnson wrote:

> "The _complete_ application framework. Learn once, use anywhere.  A single,
> elegant solution everywhere."

Not sure if that was a recap of recent suggestions, or a suggested phrase in 
itself.  It reminds me of a footballer giving an interview.  ("The boys done 
good.  We just gotta take it one game at a time.  It's a marathon not a 
sprint."  etc.)

How about,

"Spring is the _complete_ Java application framework.  A single, elegant 
solution that you can learn once and use everywhere."

-- 

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

Re: [lists] RE: [Springframework-developer] Slogan

[Rod J. <rod...@in...>]

> +1 for learn once, use anywhere. It would be good to emphasise how Spring
> can fit your code which makes a welcome relief from being straitjacketed
the
> other way around. To me this was one of the most liberating aspects of
> Spring: finally someone who understood how to build frameworks, who had
> reached what I (among many) had been unsuccessfully trying to get at for a
> while.

"Spring is about your applications"? I think this is a very important point.

I think the reason that some people perceive a lack of focus is that they
expect a framework to do something in particular (like Struts). In the case
of Spring, the framework is focused not on a particular technology, but on
real applications (or on the whole of J2EE). So I've used nearly every part
of Spring in different applications this year (not Hibernate support yet,
but that's a matter of time), and have not needed any other framework. So
Spring has been a great reflection of what I've needed for several quite
different apps.

"The _complete_ application framework. Learn once, use anywhere.  A single,
elegant solution everywhere."

Where do you want to go today (oh, maybe we shouldn't use that one).

Regards,
Rod

[Springframework-developer] FW: Simple SMTP Server licensing issues

[Alef A. \(JTeam\) <al...@jt...>]

Well, that wasn't so hard. I don't know when and how he's going to
update code and website... Also, I read some comments from Juergen about
the mail functionality. I'll just wait with committing the tests until
Jason changes his license and the mail issues have been finished.

Alef

-----Oorspronkelijk bericht-----
Van: J K [mailto:lil...@ya...] 
Verzonden: Monday, September 29, 2003 2:45 AM
Aan: al...@jt...
Onderwerp: Re: Simple SMTP Server licensing issues


Hi Alef,

Thanks for your interest in the article and SMTP
server. I have no objection to moving this over to the

LGPL license.

-- Jason

Re: [Springframework-developer] Slogan

[Rod J. <rod...@in...>]

I didn't recall it at first, but now I think that that phrase _does_ come
from the book.

I think we're definitely highlighting some useful ideas. As well as a slogan
paragraph (Trevor, I'll look at your closely when I get time), I'm sure we
can use pithy soundbites in plenty of other ways.

----- Original Message ----- 
From: "Darren Davison" <da...@da...>
To: "Rod Johnson" <rod...@in...>
Cc: <spr...@li...>
Sent: Sunday, September 28, 2003 9:06 PM
Subject: Re: [Springframework-developer] Slogan


> On Sunday 28 September 2003 18:35, Rod Johnson wrote:
> > "Java application framework: learn once, use anywhere"
>
> whether it originated in the book or on the list, I'm not sure, but the
phrase
> which has stuck fast in my mind about Spring is "a single, elegant
solution
> everywhere".  It was used to describe application configuration via the
beans
> and context files, but it's a catchy, memorable phrase that I've repeated
> every time I've described Spring to someone.
>
> -- 
>
> Darren Davison
> Public Key: http://www.davison.uk.net/key.jsp
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

FW: [Springframework-developer] Mail support

[<jue...@we...>]

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT]=20
Sent: Monday, September 29, 2003 12:45 PM
To: 'Kopylenko, Dmitry'
Cc: 'Rod Johnson'
Subject: RE: [Springframework-developer] Mail support


Dmitriy,

I've just reviewed our mail support in detail. I really don't see any =
necessity for MailTemplate and MailCallback: I do not consider this a =
case for template/callback as there is no resource management involved. =
A callback doesn't add any benefits here.

Why not simply rely on MailSender in a library style, using MailSettings =
as parameter object? That gives all benefits of abstracting JavaMail, =
while completely avoiding an inner class callback implementation. I =
consider filling a parameter object as more natural here.

  MailSettings mailSettings =3D new MailSettings();
  mailSettings.setXXX(...);
  mailSender.sendMail(mailSettings);

All things considered, I strongly prefer dropping MailTemplate and =
MailCallback in favor of direct MailSender usage. I see that =
MailTemplate already has the option of setting a user-specified =
MailSettings instance, but without the option of custom callbacks =
MailSender can be used directly.

Regards,
Juergen


-----Original Message-----
From: Kopylenko, Dmitry [mailto:dko...@ac...]
Sent: Tuesday, September 23, 2003 3:16 PM
To: j=FCrgen h=F6ller [werk3AT]
Cc: 'Rod Johnson'
Subject: RE: [Springframework-developer] Mail support


And another reason would be - the MailSettings is the property of
MailTemplate and could be configured/wired through the =
ApplicationContext,
then the client's code would need to provide "an empty" implementation =
of
the MailCallback in the call to sendMail() and not worried about
MailSettings in the code. So, please forgive me if I'm way off in my
thinking :-)) (with humor)=20

Dmitriy.

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20
Sent: Tuesday, September 23, 2003 8:46 AM
To: Kopylenko, Dmitry; spr...@li...
Subject: RE: [Springframework-developer] Mail support


Just wondering from your description: Why doesn't the sendMail method =
simply
take a MailSettings parameter? The callback implementation doesn't use =
any
prepared resource like a JDBC Connection or Hibernate Session, so why =
use a
callback at all?
=20
BTW, we should definitely aim to agree on such public API before =
releasing
1.0 M2. Released APIs should stay as stable as possible.
=20
Juergen
=20

	-----Original Message-----=20
	From: Kopylenko, Dmitry [mailto:dko...@ac...]=20
	Sent: Wed 9/10/2003 9:51 PM=20
	To: 'spr...@li...'=20
	Cc:=20
	Subject: [Springframework-developer] Mail support
=09
=09

	Hello everybody,=20

	Now there is a new mail support in the package
org.springframework.mail=20

	It follows the consistent Spring's template/callback pattern. The
central component is MailTemplate which uses MailSender strategy (which
could be implemented with any email protocol/API) and MailCallback.
Typically mailSender property on the MailTemplate is set through an
ApplicationContext. MailCallback has one method configure() in which the
client's implementation would configure the MailSettings value object =
with
properties needed to send mail. Also the JavaMailSender implementation =
is
provided.

	Example usage:=20

	MailTemplate mt =3D new MailTemplate();=20
	MailSender ms =3D new JavaMailSender();=20
	mt.setMailSender(ms);=20

	mt.sendMail(new MailCallback() {=20
	        public void configure(MailSettings mailSettings) {=20
	                        mailSettings.setMailTo("xx...@ya...");=20
=09
mailSettings.setMailFrom("xx...@or...");=20
	                        mailSettings.setMailSubject("test");=20
	                        mailSettings.setMailText("test");=20
	                        mailSettings.setMailHost("localhost");=20
	                }=20
	        });=20

	Regards,=20
	Dmitriy.=20

RE: [Springframework-developer] wrapping an interceptor and Hibernate specific TransactionProxyFactoryBean

[<jue...@we...>]

SGkgQ29saW4sDQoNCkFjdHVhbGx5LCBJIGNvbXBsZXRlbHkgYWdyZWU6IEl0IGlzbid0IGV2ZW4g
cG9zc2libGUgdG8gYXBwbHkgYWRkaXRpb25hbCBpbnRlcmNlcHRvcnMganVzdCBmb3IgdHJhbnNh
Y3Rpb25hbCBtZXRob2RzLCBhcyB0aGUgdHJhbnNhY3Rpb24gc2VtYW50aWNzIG9mIGEgbWV0aG9k
IGFyZSBkZXRlcm1pbmVkIHdpdGhpbiB0aGUgVHJhbnNhY3Rpb25JbnRlcmNlcHRvciBpbXBsZW1l
bnRhdGlvbiB3aGVyZSB3ZSBjYW4ndCBob29rIGFueSBhZGRpdGlvbmFsIGludGVyY2VwdG9ycyBp
bi4gU28gYm90aCBpbiB0ZXJtcyBvZiBjbGVhcm5lc3MgYW5kIHNpbXBsZSBpbXBsZW1lbnRhdGlv
biwgbGV0J3MgaW50cm9kdWNlIGFuICJhZGRpdGlvbmFsSW50ZXJjZXB0b3JzIiBwcm9wZXJ0eSBv
ZiB0eXBlICJJbnRlcmNlcHRvcltdIiwgZ2V0dGluZyBhcHBsaWVkIF9hZnRlcl8gdGhlIFRyYW5z
YWN0aW9uSW50ZXJjZXB0b3IuIEkndmUganVzdCBpbXBsZW1lbnRlZCB0aGF0OyBJJ2xsIGNoZWNr
IGl0IGluIGxhdGVyIHRoaXMgYWZ0ZXJub29uLg0KDQpKdWVyZ2VuDQoNCg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCkZyb206IENvbGluIFNhbXBhbGVhbnUgW21haWx0bzpjb2xpbm1sMUBl
eGlzLmNvbV0NClNlbnQ6IFN1bmRheSwgU2VwdGVtYmVyIDI4LCAyMDAzIDEwOjMwIFBNDQpUbzog
asO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXQ0KQ2M6IHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJA
bGlzdHMuc291cmNlZm9yZ2UubmV0DQpTdWJqZWN0OiBSZTogW1NwcmluZ2ZyYW1ld29yay1kZXZl
bG9wZXJdIHdyYXBwaW5nIGFuIGludGVyY2VwdG9yIGFuZA0KSGliZXJuYXRlIHNwZWNpZmljIFRy
YW5zYWN0aW9uUHJveHlGYWN0b3J5QmVhbg0KDQoNCkrDvHJnZW4sDQoNCihOb3cgdGhhdCB5b3Ug
YXJlIGJhY2sgSSBjYW4gd3JpdGUgc29tZSBtb3JlICdmcml2b2xvdXMnIGVtYWlscyA6LSkgKS4N
Cg0KVy9yZWdhcmRzIHRvIGFkZGluZyBhZGRpdGlvbmFsIGludGVyY2VwdG9yIHN1cHBvcnQgdG8g
DQpUcmFuc2FjdGlvblByb3h5RmFjdG9yeUJlYW4sIEknbSBub3Qgc3VyZSBJIGZ1bGx5IGFncmVl
IHRoYXQgaXQncyANCmluaGVyZW50bHkgYmV0dGVyIG9yICdjbGVhbmVyJyB0byBhcHBseSB0aGVz
ZSB0byB0cmFuc2FjdGlvbmFsIG1ldGhvZHMgDQpvbmx5LiBUaGF0IGlzLCB3aGVuIHRoaW5raW5n
LCAnd2hhdCBpcyBUcmFuc2FjdGlvblByb3h5RmFjdG9yeUJlYW4gKGluIA0KdGhpcyBtb2RpZmll
ZCB2ZXJzaW9uKT8nLCB5b3UgY291bGQgY29uc2lkZXIgaXQgYXMgYSB2YXJpYW50IG9mIA0KUHJv
eHlGYWN0b3J5QmVhbiB0aGF0IGltcGxpY2l0bHkgYXBwbGllcyBhIFRyYW5zYWN0aW9uIGludGVy
Y2VwdG9yIA0KKGJlZm9yZSwgYWZ0ZXIsIG9yIGluIGJldHdlZW4gb3RoZXIgaW50ZXJjZXB0b3Jz
LCBhcyB3ZSBkZWNpZGUgbWFrZXMgdGhlIA0KbW9zdCBzZW5zZSkuIFRob3NlIG90aGVyIGludGVy
Y2VwdG9ycyBjYW4gdGhlbXNlbHZlcyBkZWNpZGUgaWYgdGhleSANCmFwcGx5LCBhcyB3aXRoIFBy
b3h5RmFjdG9yeUJlYW4uLi4NCg0KVGhlcmUgaXMgYSB1c2VjYXNlIGZvciBjYWxsaW5nIEhpYmVy
bmF0ZSBjb2RlIChuZWVkaW5nIGEgc2Vzc2lvbiksIA0Kd2l0aG91dCBuZWVkaW5nIHRyYW5zYWN0
aW9ucywgYW5kIHRoYXQncyBtb3N0bHkgZm9yIHJlYWQtb25seSBkYXRhIA0KKHdoZXJlIHRoZXJl
IGlzIG5vIG5lZWQgZm9yIGlzb2xhdGlvbiBwcm92aWRlZCBieSBhIHRyYW5zYWN0aW9uKS4gSSAN
CnJlYWxpemUgdGhhdCBJIGNvdWxkIGp1c3QgdXNlIGEgcmVndWxhciBQcm94eUZhY3RvcnlCZWFu
LCBidXQgdGhpcyBpcyANCmFsbCBhYm91dCByZWR1Y2luZyBieSBtYXliZSA0MC01MCUgYSBidW5j
aCBvZiBhbG1vc3QgaWRlbnRpY2FsIGNvbnRleHQgDQpjb25maWcgZGF0YSB0byBzZXQgdXAgdGhl
IGludGVyY2VwdG9ycy4gSW4gYSBkZWNlbnQgc2l6ZSBhcHAsIHRoaXMgaXMgYSANCmxvdCBvZiBl
eHRyYSB0eXBpbmcgYW5kIG1haW50ZW5hbmNlLiBJZiB0aGUgYWRkaXRpb25hbCBpbnRlcmNlcHRv
cnMgDQphcHBsaWVkIHRvIG9ubHkgdHJhbnNhY3Rpb25hbCBtZXRob2RzLCB0aGVuIHlvdSB3b3Vs
ZCBvbiBhIGNhc2UgYnkgY2FzZSANCm1ldGhvZCBoYXZlIHRvIGRlY2lkZSB3aGV0aGVyIG9yIG5v
dCB0byB1c2UgUHJveHlGYWN0b3J5QmVhbiBvciANClRyYW5zYWN0aW9uUHJveHlGYWN0b3J5LCBv
ciBlbHNlIGFsd2F5cyB1c2UgdGhlICdzdXBwb3J0cycgdHJhbnNhY3Rpb24gDQphdHRyaWJ1dGUs
IHdoaWNoIGRvZXNuJ3Qgc2VlbSB0aGF0IGNsZWFuIHRvIG1lLg0KDQpSZWdhcmRzLA0KQ29saW4N
Cg0KasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXSB3cm90ZToNCg0KPkhpIENvbGluLA0KPiANCj5Z
b3VyIGlzc3VlIGlzIGNhdXNlZCBieSB0aGUgcmVsaWFuY2Ugb2YgeW91ciBIaWJlcm5hdGUgYWNj
ZXNzIGNvZGUgb24gSGliZXJuYXRlSW50ZXJjZXB0b3IgZm9yIGNvcnJlY3QgcmVzb3VyY2Ugb3Bl
bmluZyBhbmQgY2xvc2luZy4gWW91IHNob3VsZCBhcHBseSBIaWJlcm5hdGVJbnRlcmNlcHRvciBl
dmVuIHdoZW4gdXNpbmcgSGliZXJuYXRlVHJhbnNhY3Rpb25NYW5hZ2VyLCB0byBiZSBhYmxlIHRv
IHN3aXRjaCB0byBKdGFUcmFuc2FjdGlvbk1hbmFnZXIgd2l0aG91dCBoYXNzbGUuDQo+IA0KPk5v
dGUgdGhhdCB3aGVuIHVzaW5nIEhpYmVybmF0ZVRlbXBsYXRlIHdpdGggYWxsb3dDcmVhdGU9dHJ1
ZSAodGhlIGRlZmF1bHQpLCBhIG5ldyBTZXNzaW9uIHdpbGwgYXV0b21hdGljYWxseSBlbmxpc3Qg
aXRzZWxmIHdpdGggdGhlIHRyYW5zYWN0aW9uIHN5bmNocm9uaXphdGlvbiBjYXBhYmlsaXRpZXMg
b2YgSnRhVHJhbnNhY3Rpb25NYW5hZ2VyOiBJdCB3aWxsIGJlIGNyZWF0ZWQgb24gZmlyc3QgYWNj
ZXNzLCByZXVzZWQgdGhyb3VnaG91dCB0aGUgY3VycmVudCB0cmFuc2FjdGlvbiwgYW5kIGNsb3Nl
ZCBvbiB0cmFuc2FjdGlvbiBjb21wbGV0aW9uLiBUaGlzIGd1YXJhbnRlZXMgY29ycmVjdCBKVk0t
bGV2ZWwgcmVhZC13cml0ZSBjYWNoaW5nIHdpdGggSlRBLCBhbmQgc2VhbWxlc3Mgc3dpdGNoaW5n
IGJldHdlZW4gSGliZXJuYXRlVHJhbnNhY3Rpb25NYW5hZ2VyIGFuZCBKdGFUcmFuc2FjdGlvbk1h
bmFnZXIuDQo+IA0KPkluIHlvdXIgY2FzZSwgSSB3b3VsZCBpbmRlZWQgaGF2ZSBzdWdnZXN0ZWQg
dG8gZ28gdGhlIHN0YW5kYXJkIFByb3h5RmFjdG9yeUJlYW4gcm91dGUgYW5kIGFwcGx5IGEgSGli
ZXJuYXRlSW50ZXJjZXB0b3IgYWZ0ZXIgdGhlIFRyYW5zYWN0aW9uSW50ZXJjZXB0b3IgKGFmdGVy
IGlzIHNlbWFudGljYWxseSBjbGVhcmVyIHRoYW4gYmVmb3JlLCBJTU8pLiBQcm94eUZhY3RvcnlC
ZWFuIGlzIHRoZSBjb3JyZWN0IGNob2ljZSBmb3IgYXBwbHlpbmcgbXVsdGlwbGUgaW50ZXJjZXB0
b3JzLiBUcmFuc2FjdGlvblByb3h5RmFjdG9yeUJlYW4gaXMganVzdCBtZWFudCBmb3IgZGVjbGFy
YXRpdmUgdHJhbnNhY3Rpb24gbWFuYWdlbWVudCB3aXRob3V0IHdvcnJ5aW5nIGFib3V0IEFPUCBj
b25jZXB0cy4NCj4gDQo+T2J2aW91c2x5LCBUcmFuc2FjdGlvblByb3h5RmFjdG9yeUJlYW4gY291
bGQgYmUgZXh0ZW5kZWQgdG8gc3VwcG9ydCBhZGRpdGlvbmFsIGludGVyY2VwdG9ycyBmb3IgaXRz
IHRhcmdldCBiZWFuLiBJIHdvdWxkIHJlc3RyaWN0IHRoaXMgdG8gdHJhbnNhY3Rpb25hbCBtZXRo
b2RzIHRob3VnaDogRXhlY3V0aW5nIG90aGVyIG1ldGhvZHMgd2l0aCBhIEhpYmVybmF0ZSBTZXNz
aW9uIGlzIHJlYWxseSBub3QgdGhlIHRhc2sgb2YgVHJhbnNhY3Rpb25Qcm94eUZhY3RvcnkgQmVh
biAtIEkgY29uc2lkZXIgYSBnZW5lcmljIFByb3h5RmFjdG9yeUJlYW4gYXBwcm9wcmlhdGUgaGVy
ZS4gQW5kIHlvdSBjYW4gYWx3YXlzIGRlZmluZSBtZXRob2RzIGFzIHRyYW5zYWN0aW9uYWwgYnV0
IHdpdGggcHJvcGFnYXRpb24gInN1cHBvcnRzIiBpbnN0ZWFkIG9mICJyZXF1aXJlZCIuDQo+IA0K
PlN1Y2ggYSBob29rIGluIFRyYW5zYWN0aW9uUHJveHlGYWN0b3J5QmVhbiBzaG91bGQgcHJvYmFi
bHkgYmUgbW9kZWxsZWQgYXMgImFkZGl0aW9uYWxJbnRlcmNlcHRvcnMiIHByb3BlcnR5LCB0YWtp
bmcgYSBsaXN0IG9mIEludGVyY2VwdG9yIGluc3RhbmNlcywgZ2V0dGluZyBhcHBsaWVkIGFmdGVy
IHRoZSBpbXBsaWNpdCBUcmFuc2FjdGlvbkludGVyY2VwdG9yIGZvciB0cmFuc2FjdGlvbmFsIG1l
dGhvZHMuIFRoaXMgY2FuIHRha2UgYSBIaWJlcm5hdGVJbnRlcmNlcHRvciBvciBKZG9JbnRlcmNl
cHRvciBvciB0aGUgbGlrZS4gQWdhaW4sIGFuIGFkZGl0aW9uYWwgSGliZXJuYXRlSW50ZXJjZXB0
b3JzIGRvZXNuJ3QgaHVydCBldmVuIHdpdGggSGliZXJuYXRlVHJhbnNhY3Rpb25NYW5hZ2VyIC0g
aXQgd2lsbCBzaW1wbHkgcGFydGljaXBhdGUgaW4gdGhlIGV4aXN0aW5nIHRocmVhZC1iaW5kaW5n
Lg0KPiANCj5KdWVyZ2VuDQo+IA0KPg0KPgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCj4J
RnJvbTogQ29saW4gU2FtcGFsZWFudSBbbWFpbHRvOmNvbGlubWwxQGV4aXMuY29tXSANCj4JU2Vu
dDogVGh1IDkvNC8yMDAzIDExOjEwIFBNIA0KPglUbzogc3ByaW5nZnJhbWV3b3JrLWRldmVsb3Bl
ckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgDQo+CUNjOiANCj4JU3ViamVjdDogW1NwcmluZ2ZyYW1l
d29yay1kZXZlbG9wZXJdIHdyYXBwaW5nIGFuIGludGVyY2VwdG9yIGFuZCBIaWJlcm5hdGUgc3Bl
Y2lmaWMgVHJhbnNhY3Rpb25Qcm94eUZhY3RvcnlCZWFuDQo+CQ0KPgkNCj4NCj4JSSB3YXMgdXNp
bmcgdGhlIFRyYW5zYWN0aW9uUHJveHlGYWN0b3J5QmVhbiB3aXRoIHRoZQ0KPglIaWJlcm5hdGVU
cmFuc2FjdGlvbk1hbmFnZXIsIGJ1dCB3aGVuIEkgc3dpdGNoZWQgdG8gdGhlDQo+CUpUQVRyYW5z
YWN0aW9uTWFuYWdlciwgZ290IGJpdHRlbiBieSB0aGUgZmFjdCB0aGF0IEkgbm8gbG9uZ2VyIGhh
ZA0KPglhbnl0aGluZyBjcmVhdGluZyBhIEhpYmVybmF0ZSBzZXNzaW9uIGFuZCBiaW5kaW5nIGl0
IHRvIHRoZSBjdXJyZW50DQo+CXRocmVhZCwgYXMgSGliZXJuYXRlVHJhbnNhY3Rpb25NYW5hZ2Vy
IHVzZWQgdG8gZG8gYnkgZGVmYXVsdC4NCj4JDQo+CU9uZSB2ZXJib3NlIHNvbHV0aW9uIHdvdWxk
IGhhdmUgYmVlbiB0byBoYXZlIGdvbmUgYmFjayB0byB0aGUgb2xkDQo+CVByb3h5RmFjdG9yeUJl
YW4gbWVjaGFuaXNtIGZvciBoYW5kbGluZyB0cmFuc2FjdGlvbnMsIGFuZCBqdXN0IHN0YWNrIGEN
Cj4JSGliZXJuYXRlSW50ZXJjZXB0b3IgaW4gZnJvbnQgb2YgdGhlIHRyYW5zYWN0aW9uIGludGVy
Y2VwdG9yLg0KPgkNCj4JSSBkZWNpZGVkIGluc3RlYWQgdG8gbWFrZSBhIEhpYmVybmF0ZSBzcGVj
aWZpYyB2ZXJpc29uIG9mDQo+CVRyYW5zYWN0aW9uUHJveHlGYWN0b3J5QmVhbi4gQWxsIGl0IGRv
ZXMgaXMgdGFrZSBhIG5ldw0KPglIaWJlcm5hdGVJbnRlcmNlcHRvciBwcm9wZXJ0eSwgYW5kIGlu
IGFmdGVyUHJvcGVydGllc1NldCBhZGQgdGhlDQo+CWludGVyY2VwdG9yIGJlZm9yZSB0aGUgdHJh
bnNhY3Rpb24gb25lIChob3dldmVyLCB1bmxpa2UgdGhlIHRyYW5zYWN0aW9uDQo+CW9uZSwgaXQg
d2lsbCBleGVjdXRlIG9uIGFsbCBpbnZvY2F0aW9ucywgc2luY2UgeW91IG1heSB3YW50IHRvIHJ1
biBzb21lDQo+CW1ldGhvZHMgd2l0aCBhIGhpYmVybmF0ZSBzZXNzaW9uLCBidXQgbm8gdHJhbnNh
Y3Rpb25zLg0KPgkgICAgICAgIC8vIGFsbHdheXMgaW52b2tlIHRoZSBIaWJlcm5hdGUgSW50ZXJj
ZXB0b3INCj4JICAgICAgICBhZGRJbnRlcmNlcHRvcihoaWJlcm5hdGVJbnRlcmNlcHRvcik7DQo+
CSAgICAgICAgLi4uIGV4aXN0aW5nIGNvZGUgdG8gc2V0IHVwIHRoZSBUcmFuc2FjdGlvbiBpbnRl
cmNlcHRvcg0KPgkNCj4JTm93IG15IHF1ZXN0aW9uczoNCj4JMTogaXMgaXQgd29ydGggY2hlY2tp
bmcgc29tZXRoaW5nIGxpa2UgdGhpcyBpbj8gSSBtYWRlIGEgY3V0IGFuZCBwYXN0DQo+CWNvcHkg
b2YgVHJhbnNhY3Rpb25Qcm94eUZhY3RvcnlCZWFuLCBhbmQgYWRkZWQgdGhlIG5ldyBwcm9wZXJ0
eSBhbmQNCj4JbW9kaWZpZWQgdGhlIGFmdGVyUHJvcGVydGllc1NldC4gT2J2aW91c2x5LCBJIGNv
dWxkIGFsc28gaGF2ZSBqdXN0DQo+CXN1YmNsYXNzZXMgdGhlIGV4aXN0aW5nIGNsYXNzIGFuZCBv
dmVycmlkZW4gYWZ0ZXJQcm9wZXJ0aWVzU2V0LiBUaGF0J3MNCj4JcHJvYmFibHkgYSBiZXR0ZXIg
Y2hvaWNlLCBidXQgbWF5YmUgYSBiaXQgbW9yZSBkYW5nZXJvdXMgaWYgc29tZXRoaW5nDQo+CWNo
YW5nZXMgaW4gdGhlIHBhcmVudCBtZXRob2Qgd2hpY2ggaXMgbm8gbG9uZ2VyIGNhbGxlZCBhdCBh
bGwuDQo+CTI6IGlzIHRoZXJlIGEgYmV0dGVyIHdheSBvZiBkb2luZyB0aGlzPyBJIHN1cHBvc2Vk
IEkgY291bGQgaGF2ZSB3cmFwcGVkDQo+CXRoZSBwcm94eSBpbiBhbm90aGVyIHByb3h5IHRvIGFk
ZCB0aGUgaGliZXJuYXRlIGludGVyY2VwdG9yLiBUaGlzIHdvdWxkDQo+CW5vdCBoYXZlIHJlcXVp
cmVkIGFueSBjb2RlIGNoYW5nZXMsIGJ1dCB3b3VsZCBoYXZlIG1hZGUgZm9yIGEgbG90IG1vcmUN
Cj4JdHlwaW5nIGluIHRoZSBjb250ZXh0LiAgQW5vdGhlciBvcHRpb24gd291bGQgYmUgdG8gYWRk
IG9wdGlvbmFsIGJlZm9yZQ0KPglhbmQgYWZ0ZXIsICdhbHdheXMgaW52b2tlJyBpbnRlcmNlcHRv
ciBwcm9wZXJ0aWVzIHRvIHRoZQ0KPglUcmFuc2FjdGlvblByb3h5RmFjdG9yeUJlYW4sIHNvIHNv
bWV0aGluZyBsaWtlIHRoaXMgY2FuIGJlIGFkZGVkLg0KPgkNCj4JUmVnYXJkcywNCj4JQ29saW4N
Cj4JDQo+DQoNCg0KDQo=

Re: [lists] RE: [Springframework-developer] Slogan

[Peter d. H. <pe...@de...>]

"put a spring in your step from design to deployment :)"
"will it be spring or straitjacket?"

mmm, too cheesy and nondescript perhaps.

+1 for learn once, use anywhere. It would be good to emphasise how Spring
can fit your code which makes a welcome relief from being straitjacketed the
other way around. To me this was one of the most liberating aspects of
Spring: finally someone who understood how to build frameworks, who had
reached what I (among many) had been unsuccessfully trying to get at for a
while.

 - Peter

RE: [Springframework-developer] Testing JavaMail

[Alef A. \(JTeam\) <al...@jt...>]

This is exactly where I got the simple server from! It's quite good
actually. We creating something similar at my company, but it got lost
in the trash and I don't have the time to redo it ;-)... 

I'll contact the guy who wrote it to see what the options are...

Alef

-----Oorspronkelijk bericht-----
Van: Trevor Cook [mailto:pr...@se...] 
Verzonden: Sunday, September 28, 2003 11:00 PM
Aan: al...@jt...
CC: spr...@li...
Onderwerp: RE: [Springframework-developer] Testing JavaMail


There is an article on creating a simple smtp server for unit testing at
http://www.javaworld.com/javaworld/jw-08-2003/jw-0829-smtp.html .  It
might be more work than it's worth, but it would avoid making the tests
optional/seperate download.

Trevor


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: September 28, 2003 3:36 PM
To: al...@jt...
Cc: spr...@li...
Subject: Re: [Springframework-developer] Testing JavaMail


Unfortunately we couldn't bundle it up (or any other GPL library) with
Spring, or Spring itself would have to become GPL. With GPL code (as
opposed to LGPL), this applies even if trying to use reflection to not
do direct imports of library classes; just the act of bundling the stuff
together is viral, to the best of my knowledge. However, one option
would be to provide information on where it could be pulled down, and
have that part of the testsuite become conditional.

This strategy would work with any library which is GPL and which doesn't
actually have to be referred to by Java code (ie there is no need for
imports).

It's obviously easier and cleaner to use a non-GPL alternative, if one
can be found. One other possiblity is to approach the dumbster author an
ask if he is ammenable to switching licenses from GPL to LGPL. I have
had some success with this strategy in the past.

Regards,
Colin


Alef Arendsen (JTeam) wrote:

>I've taken a look at the JavaMail package and it's tested right now. 
>However, I could not find the mailer we used internally anymore, so 
>I've snatched another mockup mailserver form the net. However, the 
>library is licensed under GPL. I've never really understood how to 
>handle GPL licenses when you're just using the library for testing 
>purposes and stuff... Any objections?
>
>Furthermore, I was wondering why not all of the properties JavaMail 
>specified can be set in the MailSetings object. For instance 
>mail.smtp.port cannot be set?
>
>Any comments?
>
>Alef
>
>P.s. the mail library is located at 
>http://sourceforge.net/projects/dumbster
>
>-----Oorspronkelijk bericht-----
>Van: spr...@li...
>[mailto:spr...@li...] Namens 
>Rod Johnson
>Verzonden: Tuesday, September 23, 2003 8:50 AM
>Aan: al...@jt...; spr...@li...
>Onderwerp: Re: [Springframework-developer] Test coverage
>
>
>I took a look and mocking JavaMail isn't really an option (superbly 
>untestable API, with static methods and final classes).
>
>So this is probably the only way to go... Thanks.
>
>Regards,
>Rod
>
>----- Original Message -----
>From: "Alef Arendsen (JTeam)" <al...@jt...>
>To: "'Rod Johnson'" <rod...@in...>; 
><spr...@li...>
>Sent: Monday, September 22, 2003 10:48 PM
>Subject: RE: [Springframework-developer] Test coverage
>
>
>
>
>>If nobody's busy doing it already, I'll see what I can do on the 
>>javamail package. I've got a devnull mailer lying around somewhere 
>>that we use for testing, maybe I can integrate it somehow...
>>
>>By the way, up to 76,7 now...
>>
>>Alef
>>
>>-----Oorspronkelijk bericht-----
>>Van: spr...@li...
>>[mailto:spr...@li...] Namens 
>>Rod Johnson
>>Verzonden: Saturday, September 20, 2003 11:17 PM
>>Aan: spr...@li...
>>Onderwerp: [Springframework-developer] Test coverage
>>
>>
>>I think one of the things that has contributed to the success and 
>>quality of Spring is our commitment to a good test suite. I've put a 
>>fair bit more work into the test suite over the weekend, with the 
>>upgrade to EasyMock 1.0 and new test suites for Velocity etc.
>>
>>I'm really pleased that everyone is emphasising tests in new coding, 
>>but there is a still a bit of catchup to do.
>>
>>With this and Alef's new tag tests, test coverage is now 75.8%. I'd 
>>like to see this go above 80% before 1.0RC1.
>>
>>So I think we should all kick in and add tests to our areas of 
>>interest. Please run the Clover analysis as a starting point.
>>
>>Current major gaps include:
>>- XSLT support. I wrote this code so I guess I really should do the 
>>tests but I'm not sure I have time. (These days I work entirely test 
>>first, but I wrote that last year.) If any of the dev team are using 
>>this, maybe they could take a look? It might require some refactoring.
>>- jdbc.core.support: No tests for incrementer support. Can the 
>>developers looking after this please try to add some tests?
>>
>>Any volunteers for these or other areas in which tests can be 
>>improved?
>>
>>Regards,
>>Rod
>>
>>
>>





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Slogan

[Darren D. <da...@da...>]

On Sunday 28 September 2003 18:35, Rod Johnson wrote:
> "Java application framework: learn once, use anywhere"

whether it originated in the book or on the list, I'm not sure, but the phrase 
which has stuck fast in my mind about Spring is "a single, elegant solution 
everywhere".  It was used to describe application configuration via the beans 
and context files, but it's a catchy, memorable phrase that I've repeated 
every time I've described Spring to someone.

-- 

Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

Re: [Springframework-developer] Slogan

[<tri...@tr...>]

How about "Spring provides a layer between your application and the J2EE
services and other services that your application uses.  This removes most of
the dependencies on a specific API and makes switching implementations very
easy.  This has the added benefit of improving the testablity of your applications."

> I was just reading a blog where someone mentioned that they couldn't work
> out a single purpose for Spring. (They were interested in IoC so looked also
> at PicoContainer.)
> 
> While the blogger clearly didn't take the time to find out what Spring
> actually does, I think we should try to think about a slogan or maybe a
> paragraph that conveys how it all hangs together. It's ironic in that in
> comparison with something like PicoContainer, which does only a part of what
> Spring does, Spring can seem to lack focus. Whereas in fact it's a focused
> solution to meet infrastructure needs of real apps.
> 
> Some ideas (for concepts not wording):
> - Spring provides _all_ the infrastructure most projects need
> - Spring addresses all architectural tiers, whether or not you choose to use
> EJB
> 
> Btw my ServerSide article should appear on October 14. I'll confirm closer
> to the time, so you can watch the thread.
> 
> Regards,
> Rod
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

RE: [Springframework-developer] Testing JavaMail

[Trevor C. <pr...@se...>]

There is an article on creating a simple smtp server for unit testing at
http://www.javaworld.com/javaworld/jw-08-2003/jw-0829-smtp.html .  It might
be more work than it's worth, but it would avoid making the tests
optional/seperate download.

Trevor


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: September 28, 2003 3:36 PM
To: al...@jt...
Cc: spr...@li...
Subject: Re: [Springframework-developer] Testing JavaMail


Unfortunately we couldn't bundle it up (or any other GPL library) with
Spring, or Spring itself would have to become GPL. With GPL code (as
opposed to LGPL), this applies even if trying to use reflection to not
do direct imports of library classes; just the act of bundling the stuff
together is viral, to the best of my knowledge. However, one option
would be to provide information on where it could be pulled down, and
have that part of the testsuite become conditional.

This strategy would work with any library which is GPL and which doesn't
actually have to be referred to by Java code (ie there is no need for
imports).

It's obviously easier and cleaner to use a non-GPL alternative, if one
can be found. One other possiblity is to approach the dumbster author an
ask if he is ammenable to switching licenses from GPL to LGPL. I have
had some success with this strategy in the past.

Regards,
Colin


Alef Arendsen (JTeam) wrote:

>I've taken a look at the JavaMail package and it's tested right now.
>However, I could not find the mailer we used internally anymore, so I've
>snatched another mockup mailserver form the net. However, the library is
>licensed under GPL. I've never really understood how to handle GPL
>licenses when you're just using the library for testing purposes and
>stuff... Any objections?
>
>Furthermore, I was wondering why not all of the properties JavaMail
>specified can be set in the MailSetings object. For instance
>mail.smtp.port cannot be set?
>
>Any comments?
>
>Alef
>
>P.s. the mail library is located at
>http://sourceforge.net/projects/dumbster
>
>-----Oorspronkelijk bericht-----
>Van: spr...@li...
>[mailto:spr...@li...] Namens
>Rod Johnson
>Verzonden: Tuesday, September 23, 2003 8:50 AM
>Aan: al...@jt...; spr...@li...
>Onderwerp: Re: [Springframework-developer] Test coverage
>
>
>I took a look and mocking JavaMail isn't really an option (superbly
>untestable API, with static methods and final classes).
>
>So this is probably the only way to go... Thanks.
>
>Regards,
>Rod
>
>----- Original Message -----
>From: "Alef Arendsen (JTeam)" <al...@jt...>
>To: "'Rod Johnson'" <rod...@in...>;
><spr...@li...>
>Sent: Monday, September 22, 2003 10:48 PM
>Subject: RE: [Springframework-developer] Test coverage
>
>
>
>
>>If nobody's busy doing it already, I'll see what I can do on the
>>javamail package. I've got a devnull mailer lying around somewhere
>>that we use for testing, maybe I can integrate it somehow...
>>
>>By the way, up to 76,7 now...
>>
>>Alef
>>
>>-----Oorspronkelijk bericht-----
>>Van: spr...@li...
>>[mailto:spr...@li...] Namens
>>Rod Johnson
>>Verzonden: Saturday, September 20, 2003 11:17 PM
>>Aan: spr...@li...
>>Onderwerp: [Springframework-developer] Test coverage
>>
>>
>>I think one of the things that has contributed to the success and
>>quality of Spring is our commitment to a good test suite. I've put a
>>fair bit more work into the test suite over the weekend, with the
>>upgrade to EasyMock 1.0 and new test suites for Velocity etc.
>>
>>I'm really pleased that everyone is emphasising tests in new coding,
>>but there is a still a bit of catchup to do.
>>
>>With this and Alef's new tag tests, test coverage is now 75.8%. I'd
>>like to see this go above 80% before 1.0RC1.
>>
>>So I think we should all kick in and add tests to our areas of
>>interest. Please run the Clover analysis as a starting point.
>>
>>Current major gaps include:
>>- XSLT support. I wrote this code so I guess I really should do the
>>tests but I'm not sure I have time. (These days I work entirely test
>>first, but I wrote that last year.) If any of the dev team are using
>>this, maybe they could take a look? It might require some refactoring.
>>- jdbc.core.support: No tests for incrementer support. Can the
>>developers looking after this please try to add some tests?
>>
>>Any volunteers for these or other areas in which tests can be
>>improved?
>>
>>Regards,
>>Rod
>>
>>
>>





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Testing JavaMail

[Colin S. <col...@ex...>]

Unfortunately we couldn't bundle it up (or any other GPL library) with 
Spring, or Spring itself would have to become GPL. With GPL code (as 
opposed to LGPL), this applies even if trying to use reflection to not 
do direct imports of library classes; just the act of bundling the stuff 
together is viral, to the best of my knowledge. However, one option 
would be to provide information on where it could be pulled down, and 
have that part of the testsuite become conditional.

This strategy would work with any library which is GPL and which doesn't 
actually have to be referred to by Java code (ie there is no need for 
imports).

It's obviously easier and cleaner to use a non-GPL alternative, if one 
can be found. One other possiblity is to approach the dumbster author an 
ask if he is ammenable to switching licenses from GPL to LGPL. I have 
had some success with this strategy in the past.

Regards,
Colin


Alef Arendsen (JTeam) wrote:

>I've taken a look at the JavaMail package and it's tested right now.
>However, I could not find the mailer we used internally anymore, so I've
>snatched another mockup mailserver form the net. However, the library is
>licensed under GPL. I've never really understood how to handle GPL
>licenses when you're just using the library for testing purposes and
>stuff... Any objections?
>
>Furthermore, I was wondering why not all of the properties JavaMail
>specified can be set in the MailSetings object. For instance
>mail.smtp.port cannot be set?
>
>Any comments?
>
>Alef
>
>P.s. the mail library is located at
>http://sourceforge.net/projects/dumbster
>
>-----Oorspronkelijk bericht-----
>Van: spr...@li...
>[mailto:spr...@li...] Namens
>Rod Johnson
>Verzonden: Tuesday, September 23, 2003 8:50 AM
>Aan: al...@jt...; spr...@li...
>Onderwerp: Re: [Springframework-developer] Test coverage
>
>
>I took a look and mocking JavaMail isn't really an option (superbly
>untestable API, with static methods and final classes).
>
>So this is probably the only way to go... Thanks.
>
>Regards,
>Rod
>
>----- Original Message ----- 
>From: "Alef Arendsen (JTeam)" <al...@jt...>
>To: "'Rod Johnson'" <rod...@in...>;
><spr...@li...>
>Sent: Monday, September 22, 2003 10:48 PM
>Subject: RE: [Springframework-developer] Test coverage
>
>
>  
>
>>If nobody's busy doing it already, I'll see what I can do on the 
>>javamail package. I've got a devnull mailer lying around somewhere 
>>that we use for testing, maybe I can integrate it somehow...
>>
>>By the way, up to 76,7 now...
>>
>>Alef
>>
>>-----Oorspronkelijk bericht-----
>>Van: spr...@li...
>>[mailto:spr...@li...] Namens 
>>Rod Johnson
>>Verzonden: Saturday, September 20, 2003 11:17 PM
>>Aan: spr...@li...
>>Onderwerp: [Springframework-developer] Test coverage
>>
>>
>>I think one of the things that has contributed to the success and 
>>quality of Spring is our commitment to a good test suite. I've put a 
>>fair bit more work into the test suite over the weekend, with the 
>>upgrade to EasyMock 1.0 and new test suites for Velocity etc.
>>
>>I'm really pleased that everyone is emphasising tests in new coding, 
>>but there is a still a bit of catchup to do.
>>
>>With this and Alef's new tag tests, test coverage is now 75.8%. I'd 
>>like to see this go above 80% before 1.0RC1.
>>
>>So I think we should all kick in and add tests to our areas of 
>>interest. Please run the Clover analysis as a starting point.
>>
>>Current major gaps include:
>>- XSLT support. I wrote this code so I guess I really should do the 
>>tests but I'm not sure I have time. (These days I work entirely test 
>>first, but I wrote that last year.) If any of the dev team are using 
>>this, maybe they could take a look? It might require some refactoring.
>>- jdbc.core.support: No tests for incrementer support. Can the 
>>developers looking after this please try to add some tests?
>>
>>Any volunteers for these or other areas in which tests can be 
>>improved?
>>
>>Regards,
>>Rod
>>
>>    
>>