springframework-developer — Spring Framework developers list

Re: [Springframework-developer] DataBinder < BindException

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

I'm aware that you didn't ask for a change - you just uncovered some =
earlier thoughts of mine :-) I've just reworked DataBinder and =
ServletRequestDataBinder to contain a BindException instead of derive =
from it. That should give the best of both worlds, i.e. exception =
functionality and non-Exception data binders.
=20
Command and form controller implementations should not have to change, =
as they're only seeing a ServletRequestDataBinder on initBinder anyway, =
where they are just supposed to call binder methods, not the formerly =
inherited BindException methods. Code that uses BindUtils should not =
have to change too.
=20
Just custom usage of ServletRequestDataBinder will have to call =
getErrors to get a BindException instance instead of just passing the =
data binder itself like before. We'll note that in the release mail.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Rim, Mark
Gesendet: Fr 14.11.2003 01:43
An: spr...@li...
Betreff: [[W3-SPAM]] - RE: [Springframework-developer] DataBinder < =
BindException - Email found in subject



i'm not asking for it to be changed. a major change like that will =
probably have to wait until after 1.0 is released. i'm trying to get a =
deeper understanding of the framework.

just from the names, it seems to me that BindException should extend =
Exception. but where i have trouble is, the justification for DataBinder =
extending BindException. does a DataBinder also need to be thrown and be =
treated as an Errors instance ? or is it convenient to re-use some of =
the BindException routines in DataBinder ?

a lot of the routines in BindException look like they'd be useful in a =
something that would bind values to beans ...



> -----Original Message-----
> From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]
> Sent: Thursday, November 13, 2003 5:36 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] DataBinder < BindException
>
>
> That's an early design decision that goes to back to Rod's
> original com.interface21 version of the framework. As far as
> I understand the rationale, BindException extends Exception
> because this allows to throw the binding status as exception
> if binding errors are to be considered fatal. The thrown
> exception can then be treated as Errors instance for
> convenient checking of the contained errors. This is of
> course a rarely used feature, as binding errors are normally
> not considered fatal.
>=20
> Unfortunately, this has the disadvantage of having not only
> BindException but also its subclasses in the "Exceptions"
> category of the generated javadoc. I'm not really happy about
> that, but the alternative of dropping the exception feature
> and thus not making BindException an Exception also involves
> the obvious need to rename that default implementation of the
> Errors interface. That in turn would mean changing the
> signatures of quite a few template methods in the command and
> form controllers, breaking current implementations.
>=20
> I'm not sure if such a change is worth the effort... What do
> others think?
>=20
> Juergen

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
This message is for the named person's use only. It may contain =
sensitive and private proprietary or legally privileged information. No =
confidentiality or privilege is waived or lost by any mistransmission. =
If you are not the intended recipient, please immediately delete it and =
all copies of it from your system, destroy any hard copies of it and =
notify the sender. You must not, directly or indirectly, use, disclose, =
distribute, print, or copy any part of this message if you are not the =
intended recipient. CREDIT SUISSE GROUP and each legal entity in the =
CREDIT SUISSE FIRST BOSTON or CREDIT SUISSE ASSET MANAGEMENT business =
units of CREDIT SUISSE FIRST BOSTON reserve the right to monitor all =
e-mail communications through its networks. Any views expressed in this =
message are those of the individual sender, except where the message =
states otherwise and the sender is authorized to state them to be the =
views of any such entity.
Unless otherwise stated, any pricing information given in this message =
is indicative  only, is subject to change and does not constitute an =
offer to deal at any price quoted. Any reference to the terms of =
executed transactions should be treated as  preliminary only and subject =
to our formal written confirmation.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D



-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Copy paste error ?

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

MethodMatchersTests fails in the current CVS version. So does =
AttributeWriterTests - still.
=20
Juergen

________________________________

Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: Mi 12.11.2003 16:37
An: spr...@li...
Cc: Kopylenko, Dmitry
Betreff: Re: [Springframework-developer] Copy paste error ?



Hang on. It's only possible to ascertain the intersection at runtime. If
it's an AND, the runtime evaluation will never happen, which will mean =
that
the part of the intersection that was dynamic won't ever be evaluated =
and
the intersection will be bigger than it should be.

So I think it's correct. This does mean that there's a cost involved in
intersections with dynamic method matchers, which are inherently =
expensive.

However, we really need to write a lot more test cases for Pointcut and
MethodMatcher unions and intersections. I'm pretty sure there are some =
bugs
in the present composition implementation, but I was keen to put the
framework in place first.

Regards,
Rod

----- Original Message -----
From: "Dmitriy Kopylenko" <dko...@ru...>
To: <spr...@li...>
Sent: Wednesday, November 12, 2003 3:27 PM
Subject: RE: [Springframework-developer] Copy paste error ?


> I'll fix that.
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
Of
> roger holbrook
> Sent: Wednesday, November 12, 2003 10:21 AM
> To: spr...@li...
> Subject: [Springframework-developer] Copy paste error ?
>
>
>
> The following code in MethodMatchers.IntersectionMethodMatcher
> looks like a candidate:
>
>     public boolean isRuntime() {
> -        return a.isRuntime() || b.isRuntime();
> +       return a.isRuntime() && b.isRuntime();
>     }
>
> Roger
>
>
>
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest developments =
in
> Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more!
> http://www.apachecon.com/ =
_______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] DataBinder < BindException

[Rim, M. <mar...@cs...>]

i'm not asking for it to be changed. a major change like that will probably =
have to wait until after 1.0 is released. i'm trying to get a deeper =
understanding of the framework.

just from the names, it seems to me that BindException should extend =
Exception. but where i have trouble is, the justification for DataBinder =
extending BindException. does a DataBinder also need to be thrown and be =
treated as an Errors instance =3F or is it convenient to re-use some of the =
BindException routines in DataBinder =3F

a lot of the routines in BindException look like they'd be useful in a =
something that would bind values to beans ...



> -----Original Message-----
> From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]
> Sent: Thursday, November 13, 2003 5:36 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] DataBinder < BindException
>=20
>=20
> That's an early design decision that goes to back to Rod's=20
> original com.interface21 version of the framework. As far as=20
> I understand the rationale, BindException extends Exception=20
> because this allows to throw the binding status as exception=20
> if binding errors are to be considered fatal. The thrown=20
> exception can then be treated as Errors instance for=20
> convenient checking of the contained errors. This is of=20
> course a rarely used feature, as binding errors are normally=20
> not considered fatal.
> =20
> Unfortunately, this has the disadvantage of having not only=20
> BindException but also its subclasses in the "Exceptions"=20
> category of the generated javadoc. I'm not really happy about=20
> that, but the alternative of dropping the exception feature=20
> and thus not making BindException an Exception also involves=20
> the obvious need to rename that default implementation of the=20
> Errors interface. That in turn would mean changing the=20
> signatures of quite a few template methods in the command and=20
> form controllers, breaking current implementations.
> =20
> I'm not sure if such a change is worth the effort... What do=20
> others think=3F
> =20
> Juergen

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
This message is for the named person's use only. It may contain sensitive and=
 =
private proprietary or legally privileged information. No confidentiality or =
privilege is waived or lost by any mistransmission. If you are not the =
intended recipient, please immediately delete it and all copies of it from =
your system, destroy any hard copies of it and notify the sender. You must =
not, directly or indirectly, use, disclose, distribute, print, or copy any =
part of this message if you are not the intended recipient. CREDIT SUISSE =
GROUP and each legal entity in the CREDIT SUISSE FIRST BOSTON or CREDIT SUISS=
E=
 ASSET MANAGEMENT business units of CREDIT SUISSE FIRST BOSTON reserve the =
right to monitor all e-mail communications through its networks. Any views =
expressed in this message are those of the individual sender, except where th=
e=
 message states otherwise and the sender is authorized to state them to be th=
e=
 views of any such entity.
Unless otherwise stated, any pricing information given in this message is =
indicative  only, is subject to change and does not constitute an offer to =
deal at any price quoted. Any reference to the terms of executed transactions=
 =
should be treated as  preliminary only and subject to our formal written =
confirmation.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D

Re: [Springframework-developer] About MVC

[Yanger <yan...@ya...>]

SSBhZ3JlZS4NCkkgY2l0ZSBwb3J0YWwganVzdCBhcyBhbiBleGFtcGxlIGZvciB0aG9zZSBhcHBs
aWNhdGlvbnMgdGhhdCBoYXZlIHNvbWUgdW5yZWxhdGVkIGNvbnRlbnQgdG8gYmUgZGlzcGxheWVk
IGluIGRpZmZlbmVudCBwYXJ0cyBvZiBTY3JlZW4uIA0KDQoJCQkNCg0KQmVzdCBSZWdhcmRzLA0K
WWFuZ2VyDQp5YW5nZXIxOTk3QHlhaG9vLmNvbS5jbg0KCQkJCQkJCTIwMDMtMTEtMTQgMDY6NDE6
MzANCg0KPT09PT09PSAyMDAzLTExLTExIDIwOjUzOjU4IFlvdXIgbWFpbCBpc6O6PT09PT09PQ0K
DQo+WW91IHNlZW0gdG8gYmUgZGVzY3JpYmluZyBhIFBvcnRhbCB3aGljaCBoYXMgdHdvIHBhcnRz
LCAxKSBQb3J0YWwgDQo+QXBwbGljYXRpb24gd2hpY2ggaXMgcmVzcG9uc2libGUgZm9yIGFnZ3Jl
Z2F0aW5nIFBvcnRsZXRzICh5b3VyIHNjcmVlbiANCj5wYXJ0cykgYW5kIHRhcmdldGluZyBhIHJl
cXVlc3QgdG8gYSBQb3J0bGV0IGFuZCAyKSBQb3J0bGV0IENvbnRhaW5lciANCj53aGljaCBpcyBy
ZXNwb25zaWJsZSBmb3IgdGhlIGxpZmVjeWxlIG9mIFBvcnRsZXRzLg0KPg0KPlNwcmluZyBjb3Vs
ZCBiZSB1c2VkIHRvIGltcGxlbWVudCB0aGUgUG9ydGFsIEFwcGxpY2F0aW9uIHdoaWNoIHdvdWxk
IGJlIA0KPnZlcnkgY2xvc2UgdG8geW91ciBTZXF1ZW5jZSBEaWFncmFtIGFuZCB3b3VsZCBjYWxs
IGRvd24gaW50byB0aGUgUG9ydGxldCANCj5Db250YWluZXIgdG8gaW52b2tlIGEgUG9ydGxldCBh
bmQgZ2V0IHRoZSBTUC4NCj4NCj5FYWNoIFBvcnRsZXQgaXMgaW4gZXNzZW5jZSBhIHNlcGFyYXRl
IHdlYiBhcHAgYW5kIGNvdWxkIHVzZSB0aGUgc3RhbmRhcmQgDQo+U3ByaW5nIE1WQyBtb2RlbCB3
aXRoIHNvbWUgc2xpZ2h0IG1vZGlmaWNhdGlvbnMgKGUuZy4gb25seSByZXR1cm4gbWFya3VwIA0K
PmZyYWdtZW50IGluc3RlYWQgb2YgYSB3aG9sZSBwYWdlKS4NCj4NCj5UYWxrIGEgbG9vayBhdCBQ
b3J0bGV0IEFQSSBhbmQgdVBvcnRhbC4NCj5odHRwOi8vd3d3LmpjcC5vcmcvYWJvdXRKYXZhL2Nv
bW11bml0eXByb2Nlc3MvcmV2aWV3L2pzcjE2OC8NCj5odHRwOi8vbWlzMTA1Lm1pcy51ZGVsLmVk
dS9qYS1zaWcvdXBvcnRhbC8NCj4NCj5sYXRlci4NCj5CaWxsDQo+DQo+DQo+eWFuZ2VyMTk5N0Bu
ZXRzY2FwZS5uZXQgd3JvdGU6DQo+DQo+PiBBbGw6DQo+PiANCj4+IEkgcmVhZCAiRXhwZXJ0IE9u
ZS1vbi1PbmUgLSBKMkVFIERlc2lnbiBhbmQgRGV2ZWxvcG1lbnQiIHJlY2VudGx5LiBJdCBpcyBv
bmUgb2YgdGhlIG1vc3QgZXhjZWxsZW50IGJvb2tzIEkgaGF2ZSBldmVyIHJlYWQgYWJvdXQgZW50
ZXJwcmlzZSBhcHAgZGVzaWduLg0KPj4gDQo+PiBCdXQsIGFzIEkgdGhpbmssIHRoZXJlIGlzIGEg
cHJvYmxlbSBpbiBpdHMgZGVjaXNpb24gb24gTVZDIGltcGxlbWVudGF0aW9uLiBUaGUgcHJvcG9z
ZWQgc29sdXRpb24gd29ya3MgdmVyeSB3ZWxsIGluIHNpbXBsZSBhcHBsaWNhdGlvbnMuIEJ1dCB3
aGVuIGl0IGNvbWVzIHRvIGNvbXBsaWNhdGVkIHJlYWwgYXBwbGljYXRpb24gcmVxdWlyZW1lbnQs
IGl0IHNlZW1zIGl0IGNhbiBub3Qgd29yayBwcm9wZXJseSBhdCBsZWFzdCBhY2NvcmRpbmcgdG8g
Y3VycmVudCBkZXNjcmlwdGlvbi4gSXQgbmVlZHMgZXh0ZW5zaW9uLg0KPj4gDQo+PiBUaGUgUHJv
YmxlbToNCj4+IEluIHN1Y2ggY29tcGxpY2F0aW9uIGFwcGxpY2F0aW9ucyBhcyBwb3J0YWwsIGV2
ZXJ5IHdlYiBwYWdlIChJIGNhbGwgaXQgIlNjcmVlbiIgaW4gY29udHJhc3Qgd2l0aCBWaWV3IGlu
IHRoZSBNVkMpIG11c3QgZGlzcGxheSBhIGxvdCBvZiBpbmZvcm1hdGlvbi4gSW5mb3JtYXRpb24g
aXMgZ3JvdXBlZCBpbiBzZXZlcmFsIGluZGVwZW5kZW50IHBhcnRzIChJIGNhbGwgaXQgYSBTY3Jl
ZW4gUGFydCwgU1ApLiBWaWV3cyBhcmUganVzdCBTUHMsIG5vdCBTY3JlZW5zLg0KPj4gV2hlbiB0
aGUgdXNlciBzdWJtaXQgYSBmb3JtIChvciBsaW5rIHRvIGFub3RoZXIgU2NyZWVuKS4gQW5vdGhl
ciBTY3JlZW4gd2lsbCBiZSBkaXNwbGF5ZWQgYXMgYSByZXNwb25zZSB0byB0aGUgaW5wdXQuIFRo
aXMgbmV3IFNjcmVlbiBtYXkgaGF2ZSBhIFNQIGRpc3BsYXkgdGhlIHJlc3VsdCBvZiB0aGUgdXNl
ciBhY3Rpb24gYW5kIG1heSBoYXZlIG90aGVyIFNQcyB1bnJlbGF0ZWQgdG8gdGhpcyB1c2VyIGFj
dGlvbi4gVGhlIHNwcmluZyBmcmFtZXdvcmsgd29ya3MgdmVyeSBnb29kIGF0IGNyZWF0aW5nIHRo
ZSByZXN1bHQgU1Agd2hpbGUgbm90IHByb3ZpZGUgZ29vZCBtZWNoYW5pc20gdG8gcHJvZHVjZSBv
dGhlciB1bnJlbGF0ZWQgU2NyZWVuLg0KPj4gSSB3aWxsIGRlc2NyaWJlIGl0IGluIGRldGFpbC4N
Cj4+IA0KPj4gMS4gTGV0J3MgZXhhbWluZSB3aGF0IHRoZSAibW9kZWwiIG1lYW5zLiANCj4+IFRo
ZSAidHJ1ZSIsIHRyYWRpdGlvbmFsIG1vZGVsIHJlZmVycyB0byBkb21haW4gbW9kZWwgKERNKS4g
DQo+PiBBcyBleHBsYWluZWQgaW4gdGhlICJUaGUgTVZDIFRyaWFkIiBwYXJ0IG9mIHRoZSBib29r
LCAiQSBtb2RlbCBjb250YWlucyBkYXRhIGRpc3BsYXllZCBieSBhIHZpZXcuIE1vZGVscyBpbiB3
ZWIgYXBwbGljYXRpb25zIChhcyBvcHBvc2VkIHRvICJ0cnVlLCIgdHJhZGl0aW9uYWwgTVZDKSBh
cmUgdXN1YWxseSBkdW1iIHN0b3JhZ2Ugb2JqZWN0cywgc3VjaCBhcyB2YWx1ZSBvYmplY3RzLCB0
aGF0IHJlcHJlc2VudCB0aGUgcmVzdWx0IG9mIGEgY29tcGxldGUgYnVzaW5lc3Mgb3BlcmF0aW9u
LiBPbmNlIGEgY29udHJvbGxlciBjb21wbGV0ZXMgaXRzIHByb2Nlc3NpbmcgYW5kIHNlbGVjdHMg
YSB2aWV3IHRvIGdlbmVyYXRlIGNvbnRlbnQsIHRoZSBtb2RlbCBzaG91bGQgY29udGFpbiBhbGwg
dGhlIGRhdGEgdG8gZGlzcGxheS4gIiAoSSBjYWxsIHRoaXMga2luZCBvZiBtb2RlbCBpbiB3ZWIg
YXBwIHZpZXcgbW9kZWwsIFZNKS4NCj4+IA0KPj4gMi4gV2hvIGNyZWF0ZSB0aGUgVk0/DQo+PiBB
cyBETSBhbHdheXMgZXhpc3RzIGluIHRoZSBiYWNrIGdyb3VuZCwgdGhlIG9ubHkgcHJvYmxlbSBy
ZW1haW4gaXMgd2hvIHNob3VsZCB0YWtlIHRoZSByZXNwb25zaWJpbGl0eSB0byBjcmVhdGUgdGhl
IFZNIGZyb20gRE0uIA0KPj4gKEFzc3VtcHRpb246IEV2ZXJ5IFZpZXcgaGFzIGEgVk0uIEV2ZXJ5
IFZNIGNvdWxkIGJlIGRpc3BsYXllZCBieSBzZXZlcmFsIGtpbmQgb2YgVmlldy4pDQo+PiBBIHVz
ZXIgYWN0aW9uIChzdWJtaXNzaW9uIGEgZm9ybSBvciBmb2xsb3dpbmcgYSBsaW5rKSBpcyBtYXBw
aW5nIHRvIGEgY29udHJvbGxlci4gRG9lcyB0aGUgY29udHJvbGxlciBrbm93IHdoYXQgdGhlIHVz
ZXIgZXhwZWN0cyB0byBzZWUgaW4gdGhlIHJlc3VsdCBTY3JlZW4/IE5vLiBUaGUgY29udHJvbGxl
ciBvbmx5IGtub3dzIHRoZSByZXN1bHQgb2YgdGhlIGFjdGlvbiAod2hpY2ggaXMgaW1wb3J0YW50
IGluIHRoZSByZXN1bHQgU2NyZWVuIHNlbGVjdGlvbikuIEl0IGRvZXNuJ3Qga25vdyBhbGwgb3Ro
ZXIgaW5mb3JtYXRpb24gdGhlIHVzZXIgZXhwZWN0aW5nIChlLmcuIGluZm9ybWF0aW9uJ3MgdW5y
ZWxhdGVkIHRvIHRoaXMgYWN0aW9uKS4gVGhhdCBpcyBhIGNvbnRyb2xsZXIgc2hvdWxkIG9ubHkg
Y3JlYXRlIHRoZSBtb2RlbCBmb3Igb25lIHZpZXcgKGEgU1AgaW4gdGhlIHJlc3VsdCBTY3JlZW4p
LiBTbyBsZXQgdGhlIGNvbnRyb2xsZXJzIGNyZWF0ZSBhbGwgdGhlIFZNIGZvciB0aGUgcmVzdWx0
IFNjcmVlbiBpcyBpbXBvc3NpYmxlLg0KPj4gDQo+PiBNeSBzb2x1dGlvbjoNCj4+IFByaW5jaXBs
ZTogU2VwZXJhdGUgdGhlIGFjdGlvbiBjb250cm9sbGVyIHdpdGggdGhlIHZpZXcgY29udHJvbGxl
ci4NCj4+IFRoZSBhY3Rpb24gY29udHJvbGxlcidzIHJlc3BvbnNpYmlsaXR5IGlzIHRvIHByb2Nl
c3MgdGhlIHVzZXIgYWN0aW9uIGFuZCByZXR1cm4gdGhlIHJlc3VsdCBtb2RlbCAoY29udGFpbnMg
b25seSBkYXRhIHJlbGF0ZWQgdG8gdGhpcyBhY3Rpb24pIGFuZCB0aGUgcmVzdWx0IFNjcmVlbiBu
YW1lLg0KPj4gVGhlIHZpZXcgY29udHJvbGxlcidzIHJlc3BvbnNpYmlsaXR5IGlzIGNyZWF0aW5n
IHRoZSBWTSBmcm9tIHRoZSBETSBmb3IgYSBTUC4NCj4+IA0KPj4gSSBhZ3JlZSB3aXRoIHRoZSBi
b29rIHRoYXQgdGhlIGNvbnRyb2xsZXIgcmV0dXJuZWQgd2l0aCBhIG1vZGVsIGFuZCBuYW1lIG9m
ICJ2aWV3Ii4gQnV0IHRoZSBtb2RlbCBzaG91bGQgb25seSBjb250YWluIGluZm9ybWF0aW9uIHJl
bGF0ZWQgdG8gdGhlIHVzZXIgYWN0aW9uLiBBbmQgdGhlIG5hbWUgb2YgInZpZXciIHNob3VsZCBi
ZSB0aGUgbmFtZSBvZiBTY3JlZW4gTW9kZWwuIEJ1dCB0aGlzIGNvbnRyb2xsZXIgaXMgb25seSBh
Y3Rpb24gY29udHJvbGxlci4gDQo+PiBUaGVuIHVzZSBhIFNjcmVlbk1vZGVsUmVzb2x2ZXIgKHJh
dGhlciB0aGFuIGEgVmlld1Jlc29sdmVyKSB0byByZXNvbHZlIHRoZSBTY3JlZW4gTW9kZWwgbmFt
ZSB0byBhIFNjcmVlbiBNb2RlbCB3aGljaCBjb250YWlucyBhIHNldCBvZiBTUCBNb2RlbC4gRXZl
cnkgU1AgaGFzIGEgdmlldyBjb250cm9sbGVyIHRvIGNyZWF0ZSB0aGUgVk0gZm9yIHRoaXMgU1Au
IFRoZSBTY3JlZW4gTW9kZWwgY2FsbHMgYWxsIFNQcycgY29udHJvbGxlciB0byBjcmVhdGUgdGhl
aXIgVk1zLg0KPj4gVGhlbiB1c2UgYSBTY3JlZW5SZXNvbHZlciB0byBnZXQgdGhlIGNvbmNyZXRl
IFNjcmVlbiBhbmQgZm9yd2FyZCB0aGUgcmVxdWVzdCB0byB0aGlzIGNvbmNyZXRlIFNjcmVlbiB0
byBjcmVhdGUgdGhlIHJlc3BvbnNlIChieSB1c2luZyBhbnkgbWVjaGFuaXNtIGRlc2NyaWJlZCBp
biB0aGUgYm9vaykgYW5kIHNlbnQgYmFjayB0byB1c2VyLg0KPj4gDQo+PiBBcyBkZXBpY3RlZCBp
biB0aGUgYXR0YWNoIGZpbGVzLg0KPj4gDQo+PiBXaGF0IGFib3V0IHlvdXIgb3Bpbmlvbj8gDQo+
PiANCj4NCj4NCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQo+VGhpcyBTRi5OZXQgZW1haWwgc3BvbnNvcmVkIGJ5OiBBcGFjaGVDb24g
MjAwMywNCj4xNi0xOSBOb3ZlbWJlciBpbiBMYXMgVmVnYXMuIExlYXJuIGZpcnN0aGFuZCB0aGUg
bGF0ZXN0DQo+ZGV2ZWxvcG1lbnRzIGluIEFwYWNoZSwgUEhQLCBQZXJsLCBYTUwsIEphdmEsIE15
U1FMLA0KPldlYkRBViwgYW5kIG1vcmUhIGh0dHA6Ly93d3cuYXBhY2hlY29uLmNvbS8NCj5fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPlNwcmluZ2ZyYW1l
d29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQo+U3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBs
aXN0cy5zb3VyY2Vmb3JnZS5uZXQNCj5odHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0
cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQo+Lg0KDQo9ID0gPSA9ID0gPSA9
ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0NCg0KDQo=

Re: [Springframework-developer] DataBinder < BindException

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

That's an early design decision that goes to back to Rod's original =
com.interface21 version of the framework. As far as I understand the =
rationale, BindException extends Exception because this allows to throw =
the binding status as exception if binding errors are to be considered =
fatal. The thrown exception can then be treated as Errors instance for =
convenient checking of the contained errors. This is of course a rarely =
used feature, as binding errors are normally not considered fatal.
=20
Unfortunately, this has the disadvantage of having not only =
BindException but also its subclasses in the "Exceptions" category of =
the generated javadoc. I'm not really happy about that, but the =
alternative of dropping the exception feature and thus not making =
BindException an Exception also involves the obvious need to rename that =
default implementation of the Errors interface. That in turn would mean =
changing the signatures of quite a few template methods in the command =
and form controllers, breaking current implementations.
=20
I'm not sure if such a change is worth the effort... What do others =
think?
=20
Juergen

________________________________

Von: spr...@li... im Auftrag =
von Rim, Mark
Gesendet: Do 13.11.2003 17:38
An: spr...@li...
Betreff: [[W3-SPAM]] - [Springframework-developer] DataBinder < =
BindException - Email found in subject



apologies if this question has been asked before (i can't figure out how =
to
search the archives).

i was curious why org.springframework.validation.DataBinder subclasses
org.springframework.validation.BindException  i just started using the
ServletRequestDataBinder and thought it was wierd that it was listed =
under
"Exception Summary" in the javadocs.

[Springframework-developer] Checkstyle

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

Hello everyone.

I could see checkstyle.xml in our CVS tree, but do we have the actual tool
(checkstyle.jar)? I couldn't find it.

Regards,
Dmitriy.

[Springframework-developer] Most build artifacts now produced under target. You need to kill build.properties file!

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

As per the previous discussion, I have changed the Ant and Eclipse 
builds to output most artifacts to somewhere under a base 'target' 
directory. The exception to this is the 'dist' and 'docs/api' contents, 
which remain unchanged.

You need to (one-time) manually remove the old top-level dirs produced 
by the build, such as
  .classes
  .testclasses
  junit-reports
etc.

PLEASE READ: The existing properties system, where build.properties was 
checked in, but people also commonly changed values to do something like 
turn off a test, was not really great, since it's never a good idea to 
modify CVS files with changes which shouldn't be checked it. The file 
will always show up as modified, and it's very easy to accidentally 
check it in. So I have made project.properties the source for all 
default properties, and build.properties only for _overriding_ these. 
This is also how Maven actually treats these files, as a bonus.

As such, if you didn't change any values in build.properties, just kill 
your existing build.properties file. If you changed one or more values, 
then only those changed values should be left in build.properties. Your 
build will almost certainly break if you just leave the existing 
build.properties there, since some properties were renamed!

For Eclipse: my Eclipse got massively confused with the move of the 
output folders. No amount of refresh or synchronization could get it to 
be happy and not think that there were conflicts in regards to the old 
output folder. The way I resolved things was to right click on the 
project, do a 'delete' (but do _not_ delete contents), then do a 
re-import of the project. And don't forget to share it again for CVS.

Regards,
Colin

[Springframework-developer] DataBinder < BindException

[Rim, M. <mar...@cs...>]

apologies if this question has been asked before (i can't figure out how to
search the archives).

i was curious why org.springframework.validation.DataBinder subclasses
org.springframework.validation.BindException  i just started using the
ServletRequestDataBinder and thought it was wierd that it was listed under
"Exception Summary" in the javadocs.


==============================================================================
This message is for the named person's use only. It may contain sensitive and
private proprietary or legally privileged information. No confidentiality or
privilege is waived or lost by any mistransmission. If you are not the
intended recipient, please immediately delete it and all copies of it from
your system, destroy any hard copies of it and notify the sender. You must
not, directly or indirectly, use, disclose, distribute, print, or copy any
part of this message if you are not the intended recipient. CREDIT SUISSE
GROUP and each legal entity in the CREDIT SUISSE FIRST BOSTON or CREDIT SUISSE
ASSET MANAGEMENT business units of CREDIT SUISSE FIRST BOSTON reserve the
right to monitor all e-mail communications through its networks. Any views
expressed in this message are those of the individual sender, except where the
message states otherwise and the sender is authorized to state them to be the
views of any such entity.
Unless otherwise stated, any pricing information given in this message is
indicative  only, is subject to change and does not constitute an offer to
deal at any price quoted. Any reference to the terms of executed transactions
should be treated as  preliminary only and subject to our formal written
confirmation.
==============================================================================

Re: [Springframework-developer] VelocityEngineFactory question

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

Velocity.init and Velocity.getTemplate use their own singleton =
underneath - but you don't need to use that part of the Velocity API, as =
VelocityEngine is an alternative to it, AFAIK. The benefit of =
VelocityEngine is that you can have multiple Velocity configurations =
within the same application, i.e. within the same class loader.

If you use a VelocityEngineFactoryBean to set up a VelocityEngine =
singleton, that VelocityEngine instance will be a real singleton in the =
Spring application context. You need to invoke getTemplate on the =
VelocityEngine instance then instead of the static getTemplate method on =
the Velocity class. We're using this ourselves for email templates; it =
does work properly.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Ivan Ristic
Sent: Thursday, November 13, 2003 5:24 PM
To: spr...@li...
Subject: [[W3-SPAM]] - Re: [Springframework-developer]
VelocityEngineFactory question - Email found in subject



> Use VelocityEngineFactoryBean - it is a subclass of
 > VelocityEngineFactory that provides exactly what you need:
 > a singleton VelocityEngine in an application context.

   It is singleton in terms of Spring bean configuration process
   but not a real singleton.

   A single call to Velocity.init(properties) is needed to initialize
   the engine as a singleton. Later in the code you simply use
   Velocity.getTemplate(templateName) to get the template.

--=20
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]



-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] VelocityEngineFactory question

[Ivan R. <iv...@we...>]

> Use VelocityEngineFactoryBean - it is a subclass of
 > VelocityEngineFactory that provides exactly what you need:
 > a singleton VelocityEngine in an application context.

   It is singleton in terms of Spring bean configuration process
   but not a real singleton.

   A single call to Velocity.init(properties) is needed to initialize
   the engine as a singleton. Later in the code you simply use
   Velocity.getTemplate(templateName) to get the template.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Re: [Springframework-developer] VelocityEngineFactory question

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

Ivan,

Use VelocityEngineFactoryBean - it is a subclass of =
VelocityEngineFactory that provides exactly what you need: a singleton =
VelocityEngine in an application context.

Regarding PDF generation: This is currently just available for views in =
Spring's web MVC framework. Like the Velocity support, we might =
eventually refactor this into a generic and a web-specific part.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Ivan Ristic
Sent: Thursday, November 13, 2003 4:48 PM
To: spr...@li...
Subject: [[W3-SPAM]] - [Springframework-developer] VelocityEngineFactory
question - Email found in subject



As part of a project, I am using Velocity to format
emails. Because my requirements are minimal, I would like to
configure Velocity in the applicationContext but use it as
a singleton after that. Looking at the source code of the
VelocityEngineFactory, I don't think it can work with a
singleton Velocity engine.

Do you think adding a parameter there to support this mode
of operation would be a good idea?

On a similar matter, I see that a support for PDF generation
is in the package web.servlet.document. This implies that PDF
generation is web-based, which is not the case.

Shouldn't there be a generic support for application output?

Or am I missing something?

--=20
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]



-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] VelocityEngineFactory question

[Ivan R. <iv...@we...>]

As part of a project, I am using Velocity to format
emails. Because my requirements are minimal, I would like to
configure Velocity in the applicationContext but use it as
a singleton after that. Looking at the source code of the
VelocityEngineFactory, I don't think it can work with a
singleton Velocity engine.

Do you think adding a parameter there to support this mode
of operation would be a good idea?

On a similar matter, I see that a support for PDF generation
is in the package web.servlet.document. This implies that PDF
generation is web-based, which is not the case.

Shouldn't there be a generic support for application output?

Or am I missing something?

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

[Springframework-developer] Spring reference on TSS

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

Another Spring reference - this time in HiveMind thread:
http://www.theserverside.com/home/thread.jsp?thread_id=22371
<http://www.theserverside.com/home/thread.jsp?thread_id=22371> 

Regards,
Dmitriy.

Re: [Springframework-developer] Exception handling within the framework

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

Fine by me.

Rod
----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Thursday, November 13, 2003 12:07 PM
Subject: [Springframework-developer] Exception handling within the framework


I've committed subtle changes to quite a few files, in an effort to
generally refine our exception throwing and handling.

Most importantly, ApplicationContextException extends FatalBeanException now
(analogous to BeanDefinitionStoreException). This finally clarifies how to
propagate exceptions through bean lifecycle methods and bean post
processors. For example, ApplicationContext.getBean throws BeansException
but ApplicationContextAware's setApplicationContext method just threw
ApplicationContextException. It now throws BeansException which covers both.
Same for quite a few other points in the framework. My main goal was to make
it clear that an ApplicationContextException should not get wrapped in a
BeansException or vice versa, as the latter is just a specialization of the
former.

Furthermore, BeanFactoryAware.setBeanFactory just throws BeansException
instead of the former Exception, just like
ApplicationContextAware.setApplicationContext already did before. The main
rationale is consistency: Just
InitializingBean.afterPropertiesSet/"init-method" and
DisposableBean.destroy/"destroy-method" are allowed to throw any exception
(the configurable reflection-based callbacks absolutely have to), every
other callback encourages a certain kind of exception. Obviously, runtime
exceptions like IllegalArgumentException and IllegalStateException can
always be thrown.

The only additional try-catch block necessary was in
AbstractPoolingInvokerInterceptor. Its setBeanFactory implementation now
wraps exceptions from the underlying pooling tool in a
BeanInitializationException. I consider it cleaner to have it the way it is
now, for consistency within the framework. If there are strong objections,
we can of course change setBeanFactory back to throw Exception. But I guess
that BeanFactoryAware is hardly used in applications anyway; and if it is
used, then mainly just for retrieving collaborating beans.

Juergen


DI Jürgen Höller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
mailto:jue...@we...
http://www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG


-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Exception handling within the framework

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

I've committed subtle changes to quite a few files, in an effort to =
generally refine our exception throwing and handling.

Most importantly, ApplicationContextException extends FatalBeanException =
now (analogous to BeanDefinitionStoreException). This finally clarifies =
how to propagate exceptions through bean lifecycle methods and bean post =
processors. For example, ApplicationContext.getBean throws =
BeansException but ApplicationContextAware's setApplicationContext =
method just threw ApplicationContextException. It now throws =
BeansException which covers both. Same for quite a few other points in =
the framework. My main goal was to make it clear that an =
ApplicationContextException should not get wrapped in a BeansException =
or vice versa, as the latter is just a specialization of the former.

Furthermore, BeanFactoryAware.setBeanFactory just throws BeansException =
instead of the former Exception, just like =
ApplicationContextAware.setApplicationContext already did before. The =
main rationale is consistency: Just =
InitializingBean.afterPropertiesSet/"init-method" and =
DisposableBean.destroy/"destroy-method" are allowed to throw any =
exception (the configurable reflection-based callbacks absolutely have =
to), every other callback encourages a certain kind of exception. =
Obviously, runtime exceptions like IllegalArgumentException and =
IllegalStateException can always be thrown.

The only additional try-catch block necessary was in =
AbstractPoolingInvokerInterceptor. Its setBeanFactory implementation now =
wraps exceptions from the underlying pooling tool in a =
BeanInitializationException. I consider it cleaner to have it the way it =
is now, for consistency within the framework. If there are strong =
objections, we can of course change setBeanFactory back to throw =
Exception. But I guess that BeanFactoryAware is hardly used in =
applications anyway; and if it is used, then mainly just for retrieving =
collaborating beans.

Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
mailto:jue...@we...
http://www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG

Re: [Springframework-developer] Class.forname

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

Robert,

Good point - just fixed it :-) We're using the same strategy in various =
other parts of the framework, so it also makes sense to have ClassEditor =
use that strategy for consistency reasons. On the occasion, I've made =
all remaining framework classes use the thread context class loader too.

Regarding the jars for building the source: There are quite a lot of =
them, unfortunately, as we integrate with numerous third-party tools. =
We've already considered offering an additional distribution zip that =
contains all jars and also the test suite, at around 17 MB instead of =
our current distro's 10 MB.

We'd need to check the licenses of all third-party librarties first, =
though, and adapt the distribution build scripts accordingly. This =
hasn't been of high priority yet; so we'll probably still ship the =
upcoming release 1.0 M3 in the current form, i.e. with one 10 MB zip. =
Watch out for the 1.0 RC1 that will follow :-)

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Robert Gothan
Sent: Tuesday, November 18, 2003 11:27 AM
To: spr...@li...
Subject: [[W3-SPAM]] - [Springframework-developer] Class.forname - Email
found in subject



In class org.springframework.beans.propertyeditor.ClassEditor

There appears to be a bug with the Class.forName().  Changing it to=20

clazz =3D Class.forName(text, true, 			    =20
Thread.currentThread().getContextClassLoader());

makes it more reliable in J2EE environments.

By the way, it would help if all the src jars were included in the =
download,=20
with a build script!

Cheers,
Robert



-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Class.forname

[Robert G. <rg...@go...>]

In class org.springframework.beans.propertyeditor.ClassEditor

There appears to be a bug with the Class.forName().  Changing it to 

clazz = Class.forName(text, true, 			     
Thread.currentThread().getContextClassLoader());

makes it more reliable in J2EE environments.

By the way, it would help if all the src jars were included in the download, 
with a build script!

Cheers,
Robert

[Springframework-developer] Indexed and mapped properties

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

I've just introduced preliminary support for indexed and mapped =
properties to BeanWrapperImpl, including test cases on the bean wrapper =
and form controller level. The current implementation is XP-style, i.e. =
"the simplest thing that might possibly work": It does not aim to offer =
a generic object graph navigation language like OGNL bur rather just the =
ability to traverse arrays, lists, and maps.

Consider a bean with the following properties, each containing 2 =
NestedBean instances:
- NestedBean[] myArray (of size 2)
- List myList (containing 2 NestedBean instances)
- Map myMap (containing 2 NestedBean values with String keys "key" and =
"key2)

NestedBean has a "name" property of type String that can then be set in =
the various instances as follows, for example as HTTP request =
parameters:
- myArray[0].name
- myArray[1].name
- myList[0].name
- myList[1].name
- myMap[key1].name
- myMap[key2].name

The map handling also supports the following alternative notations, so =
that JSP EL and OGNL syntax can be applied too:
- myMap['key1'].name
- myMap["key2"].name

Altogether, this should allow for populating a wide range of nested bean =
instances: simple nestings, arrays, lists, String-keyed maps. Note that =
it is *not* supported to *set* array/list/map elements yet: In a typical =
web app, new elements are created via special commands, not directly =
from a request parameter - but the bean properties of indexed elements =
need to populated directly from request parameters.

The beauty of it is that there are just a few lines of code in =
BeanWrapperImpl involved now, and that custom editors are nicely =
inherited. Of course we can try to add full-blown languages like OGNL =
later: I just don't see an easy way to combine this with our =
BeanWrapper's own capabilities.

Finally, a special feature for custom editor registration: You can not =
only register an editor for a property of a specific bean with an =
expression like "myArray[0].name" but also for a property of all beans =
in an array/list/map with "myArray.name". This is particularly =
convenient as it is the normal case: If a custom editor for an array =
element has to be registered, it should typically apply to all elements.

Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
mailto:jue...@we...
http://www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG

[Springframework-developer] Re: MethodMatchers and Introductions

[roger h. <apo...@sn...>]

Rod

Thanks for the clarification about InroductionAdvice.

When I've got a clearer understanding of how the new code actually works I
will try the subclassing you suggest.

Many thanks

Roger



"Rod Johnson" <rod...@in...> wrote in message
news:27e701c3a939$2b9a2c20$3800a8c0@chopin...
> The new IntroductionAdvice is the only way to add an introduction. This
has
> only a ClassFilter. It doesn't make sense for an introduction to be
> conditional by method: it's set up when the proxy is created.
>
> If an introduction interceptor wanted to let a particular method call
> through even on one of its introduced interfaces (an unusual scenario that
> you might use only if you wanted to mask some methods of a target that
also
> implemented the introduced interface) it could override invoke() and call
> proceed() on those methods.
>
> Btw, the DelegatingIntroductionInterceptor could probably be used to
achieve
> what you wanted regarding the introduction advice implementing the
interface
> (ie an abstract IntroductionAdvice that subclasses
> DelegatingIntroductionInterceptor and leaves subclasses to implement a
> single target method). I think this can be handled by subclassing, rather
> than in the core framework.
>
> Regards,
> Rod
>
> ----- Original Message -----
> From: "roger holbrook" <apo...@sn...>
> To: <spr...@li...>
> Sent: Wednesday, November 12, 2003 4:12 PM
> Subject: [Springframework-developer] MethodMatchers and Introductions
>
>
> >
> > Sorry about the copy paste error - the error was clearly mine ;)
> >
> > How does one now apply a MethodMatcher to the calls on an
> > IntroductionInterceptor ?
> >
> > Does this require a separate InterceptionAdvice ?
> >
> > Roger
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by: ApacheCon 2003,
> > 16-19 November in Las Vegas. Learn firsthand the latest
> > developments in Apache, PHP, Perl, XML, Java, MySQL,
> > WebDAV, and more! http://www.apachecon.com/
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/

Re: [Springframework-developer] Re: WebWork2 integration (was: About MVC)

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

I think it's important that we get out the message that, although Spring
does have a good MVC framework itself, it isn't a monolithic solution. From
what I've seen of it, WW is an elegant framework (unlike certain others in
its space) and, as with Hibernate, we should make it easy for users to
combine Spring and WW. Hopefully both we and the WW community can help to
support such users.

Same goes for Tapestry.

Of course Struts integration is also going to continue to come up, and it's
good that there's another project out there focusing on it. Although we
should encourage Struts users to look at Spring MVC.

We probably need a "Using Spring with Struts" article or tutorial, as
numerous people have asked.

Regards,
Rod

----- Original Message ----- 
From: "Cameron Braid" <ca...@da...>
To: <spr...@li...>
Sent: Wednesday, November 12, 2003 3:51 PM
Subject: Re: [Springframework-developer] Re: WebWork2 integration (was:
About MVC)


> This sounds fantastic.  I am really keen to see this in action.
>
> Any idea of when it may be availible ?  If it is likely to be more than a
week, and if you have the time, could you send me a patchfile against xwork
head, and I'll apply it to a snapshot here.
>
> Thanks.
>
> Cameron
>
> Mike Cannon-Brookes wrote:
>
> The <ref>/ReferenceResolver idea should be easy to add to XWork, after
all.
> XWork already has reflection-based setting of <param> parameters; <ref>
> references could use the very same mechanism. A
> SpringServletContextReferenceResolver for WebWork2 could fetch the
> ServletContext from a ThreadLocal, grab the root WebApplicationContext
from
> the ServletContext, and resolve the reference name as bean name. A non-web
> SpringClassPathReferenceResolver could access a pre-loaded
> ClassPathXmlApplicationContext from a ThreadLocal, and resolve the
reference
> name as bean name there.
>     Wow - I should read the whole thread before replying :)
>
> As said, Ross has finished this now - we're just testing and integrating
> into the application before committing it back to XWork.
>
> At the moment it works as follows (please correct me if I've got anything
> wrong Ross).
>
> There is an ExternalEntityResolver defined on a per package level, so that
> you can have different resolvers for different packages (if needed). These
> are hierarchically looked up too, so if you specify one for the default
> package, it will filter down to all other packages.
>
> Each action can then specify external references to be resolved, as
follows:
>
> <package name="admin" namespace="/admin" extends="default"
>   external-ref-resolver="com.foo.SpringExternalReferenceResolver">
>   <action name="update" class="com.Foo">
>     <external-ref name="pageManager">myPageManager</external-ref>
>   </action>
>
> There is then a single XWork interceptor for all resolver implementations
>
(com.opensymphony.xwork.interceptors.ExternalReferenceResolutionInterceptor?
> ). This hands off to the resolver implementation to actually do the
> resolution (ie look up "myPageManager" from the Spring context, and then
set
> it using setPageManager(object) on the action instance).
>
> I believe there were a few modifications to the XWork core needed to make
it
> work nicely (such as being able to retrieve a PackageConfig from an
> ActionConfig to lookup the resolver), but it all hangs together very
nicely.
>
> The benefit of resolution being in an interceptor, like all the Xwork
> interceptors, is that you can then as the developer control the order in
> which your action is setup (ie external references, XWork IoC components,
> static parameters, web parameters etc).
>
>   I would be delighted to see that approach being adopted in
XWork/WebWork2, as
> it would allow for a really nice and straightforward combination. In terms
of
> timing, it would be good to settle that before both Spring 1.0 final (end
of
> December) and WebWork2 final (any timeframe there?). I'm happy to help on
the
> Spring side of things, but I guess we won't need any changes in Spring to
> allow for that kind of reference support in XWork.
>
> The only thing I think we decided that would be handy from the Spring side
> (that doesn't exist) is the ability to autoconfigure an existing object?
>
> This would consist of giving an object and a series of names (or other
> objects?) to the context, and it then working out how they are best
> autowired together. This would mean you wouldn't necessarily need the
> name="" in the external reference (at the cost of a little speed I
suppose)
> - but useful for lots of resolutions.
>
> Hope it makes sense.
>
> Cheers,
> Mike
>
>   Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf Of
> Cameron Braid
> Sent: Wednesday, November 12, 2003 12:36 PM
> To: spr...@li...
> Subject: [[W3-SPAM]] - Re: [Springframework-developer] Re: WebWork2
> integration (was: About MVC) - Email found in subject
>
>
> jürgen höller [werk3AT] wrote:
>
> Hi Lars,
>
> Cameron Braid has been working on XWork/WebWork2 integration and obviously
> been pleased with it (you can search our mailing list archives for the
whole
> thread).
>
> <quote>
> The bean/@id attribute relaxing is fantastic thanks!
>
> I can now use the Spring Framework as an Action Factory for
> Xwork/WebWork with no duplcation of configuration, using spring to
> define business related interceptors : components, transactions,
> security and webwork to provide web/view oriented interceptors :
> request-params, validation
>
> xwork.xml snippet :
>
> <package name="admin" namespace="/admin" extends="default">
> <action name="update" class="com.project.AdminUpdateAction"
method="txUpdate">
>   <result name="redirect">read.action?id=${id}</result>
> </action>
> </package>
>
> applicationContext.xml snippet :
>
> <bean name="/admin/update"
> class="com.datacodex.spring.webwork.WebworkActionFactoryBean">
> <property name="sessionFactory">
>   <ref local="sessionFactory"/>
> </property>
> <property name="transactionManager">
>   <ref local="transactionManager"/>
> </property>
> <property name="transactionAttributes">
>   <ref local="defaultActionTransactionAttributes"/>
> </property>
> </bean>
>
> very simple, neat and clean !
>
> Thanks guys for your fantastic framework.
>
> Cameron.
> </quote>
>
> I don't know how his integration approach works in detail but it looks
> promising. Cameron, can you give any in-depth insights? I assume the
> WebworkActionFactoryBean creates the action, being given the class name
from
> the XWork definition? How does XWork know that it needs to delegate to the
> corresponding WebWorkActionFactoryBean - I guess via some custom XWork
action
> factory? How does that action factory look up the Spring application
context?
>
>
> I have made a few posts on the webwork mailing list.
>
> See
>
http://www.mail-archive.com/ope...@li.../msg0591
> 9.html to start the thread - since then I have attempted to implement some
of
> these ideas.
>
> A basic summary :
>
> I extended the WebWork ServletDispatcher, writing a new
> SpringServletDispatcher, it makes a call to the static
> ActionProxyFactory.setFactory(new
> SpringActionProxyFactory()).
>
> SpringActionProxyFactory extends the DefaultActionProxyFactory which
overrides
> createActionInvocation to use
> a SpringActionInvocation
>
> SpringActionInvocation extends DefaultActionInvocation which overrides
> createAction to delegate to
>
WebApplicationContextUtils.getWebApplicationContext(servletContext).getBean(
be
> anName)
> to use the factory within spring to contruct this action.
>
> The servletContext is obtained using a webwork static helper that
retrieves it
> from the action context (threadlocal)
>
> This level of integration is only required if you want to use spring as
the
> action factory.
>
> Most often you will only want to use spring to provide the components that
the
> actions use, which I think is a better soloution.
>
>
> As an alternative, I still see value in extending XWork's XML action
> definition format with a <ref> tag, in addition to the existing <param>
tag.
> Those ref tags could then get resolved via a ReferenceResolver interface,
> possibly with a SpringReferenceResolver implementation that looks up the
> reference names in an application context. I've suggested that a while
ago,
> but I don't think that anyone has adopted the idea yet, as it involves an
> extension of the XWork core.
>
>
> I really like your idea of supporting an external ref type tag as core in
> xwork/webwork since it offers the simplest, and most elegent soloution.
>
> <action name="listAccounts" class="project.controller.ListAccounts">
>  ...
>   <ref name="accountsDao">accountsDao</ref>
>  ...
> </action>
> Using one of these later ideas means that the action and refrences are
totally
> defined in the webwork configuration, and components are defined in
spring,
> which is a good separation in my mind.
>
> When using spring as the action facory I was starting to find it difficult
to
> see what was going on in regards to the actions since some configuration
was
> done in xwork.xml and some in the spring context.
>
> I can have a go at adding <ref> support to the xwork configuration code -
in
> my snadbox.  In the meantime we can discuss further and see what the other
> webwork developers think.
>
> Before reading about this idea, I implemented a simple prototype (not
> production ready) system to get components from spring using a webwork
> interceptor.
>
> What happens here is you configure the interceptor in the xwork.xml file
just
> like any other webwork interceptor, using parameter to provide a mapping
of
> action proeprty to spring bean name.
>
> see
>
http://www.mail-archive.com/ope...@li.../msg0595
> 7.html
>
> A basic summary :
>
> <action name="listAccounts" class="project.controller.ListAccounts">
>  ...
>   <interceptor-ref name="springComponent">
>      <param name="mapping">
>           accountsDao=accountsDao
>      </param>
>  </interceptor-ref>
>  ...
> </action>
> this example reflectively invokes
>
action.setAccountsDao(WebApplicationContextUtils.getWebApplicationContext(se
rv
> letContext).getBean(beanName))
> obtaining the servlet context from the action context.
>
> I would prefer to use the <ref> tag since it is a lot more meaningful, and
> allows for plugable RefrenceResolvers .
>
> Thanks,
>
> Cameron
>
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Lars Fischer
> Sent: Wednesday, November 12, 2003 11:32 AM
> To: spr...@li...
> Subject: [[W3-SPAM]] - RE: [Springframework-developer] About MVC - Email
> found in subject
>
>
> I think it would be a good idea to put a focus on WebWork 2 integration.
> WebWork is a very popular framework and I think Spring would gain
> further popularity when providing a way to integrate WebWork "out of the
> box".
>
> IMO the main advantage of WebWork is that it's very easy to understand
even
> with missing documentation. Spring MVC maybe technically superior
> (I don't know) but it's too complicated to get started with.
>
> The combination of Spring as Container and WebWork 2 as MVC framework
> is very powerful.
>
> What do you think about this ?
>
> Regards,
> Lars
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -- 
> Any damn fool can write code that a computer can understand...
> The trick is to write code that humans can understand.
> [Martin Fowler
http://www.martinfowler.com/distributedComputing/refactoring.pdf]------------------------------------------------------- 
This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas.
Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java,
MySQL, WebDAV, and more! http://www.apachecon.com/
_______________________________________________ Springframework-developer
mailing list Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] MethodMatchers and Introductions

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

The new IntroductionAdvice is the only way to add an introduction. This has
only a ClassFilter. It doesn't make sense for an introduction to be
conditional by method: it's set up when the proxy is created.

If an introduction interceptor wanted to let a particular method call
through even on one of its introduced interfaces (an unusual scenario that
you might use only if you wanted to mask some methods of a target that also
implemented the introduced interface) it could override invoke() and call
proceed() on those methods.

Btw, the DelegatingIntroductionInterceptor could probably be used to achieve
what you wanted regarding the introduction advice implementing the interface
(ie an abstract IntroductionAdvice that subclasses
DelegatingIntroductionInterceptor and leaves subclasses to implement a
single target method). I think this can be handled by subclassing, rather
than in the core framework.

Regards,
Rod

----- Original Message ----- 
From: "roger holbrook" <apo...@sn...>
To: <spr...@li...>
Sent: Wednesday, November 12, 2003 4:12 PM
Subject: [Springframework-developer] MethodMatchers and Introductions


>
> Sorry about the copy paste error - the error was clearly mine ;)
>
> How does one now apply a MethodMatcher to the calls on an
> IntroductionInterceptor ?
>
> Does this require a separate InterceptionAdvice ?
>
> Roger
>
>
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] Fw: [ springframework-Bugs-840442 ] [junit] testDateTimeElement does not pass!!!

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

Forwarded from Rod:

The user who submitted the bug has added some more comments. He thinks =
he's
figured it out:

http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D840442&group=
_id=3D73357&atid=3D537539


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of dar...@hs...
Sent: Wednesday, November 12, 2003 9:32 AM
To: spr...@li...
Subject: [[W3-SPAM]] - Re: [Springframework-developer] Fw: [
springframework-Bugs-840442 ] [junit] testDateTimeElement does not
pass!!! - Email found in subject



<Juergen>
Does anyone mind if I just uncomment that test method? It gets on my
nerves, it really does - I've got more important stuff to worry about =
;-)
Of course, if someone else wants to look at it, have a try... Darren =
maybe?
</Juergen>

I don't really mind - I quickly knocked up the tests a while back when
doing some XSLT views and they always worked for me (and I guess Rod
judging by the CVS version history) because we're both in the UK.

Possibly more concerning is whether some dodgy Locale handling adversely
affects anything else, so yes, I'll try to have a look and see what's =
wrong
with it.

Darren.




_____________________________________________________

This transmission has been issued by a member of the HSBC Group=20
"HSBC" for the information of the addressee only and should not be=20
reproduced and / or distributed to any other person. Each page attached=20
hereto must be read in conjunction with any disclaimer which forms part=20
of it. Unless otherwise stated, this transmission is neither an offer =
nor the=20
solicitation of an offer to sell or purchase any investment. Its =
contents are=20
based on information obtained from sources believed to be reliable but
HSBC makes no representation and accepts no responsibility or liability =
as=20
to its completeness or accuracy.



-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] when using TransactionProxyFactoryBean, I need to proxy the target class

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

Simply set TransactionProxyFactoryBean's "proxyInterfacesOnly" property =
to "false", it should then automatically create a CGLIB proxy for the =
full target class.

ProxyFactoryBean's "proxyTargetClass" is just there to enforce a CGLIB =
proxy even with explicit specification of interfaces, like in the case =
of introductions. As TransactionProxyFactoryBean does not support =
introductions anyway, I see no need to offer that property there.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Cameron Braid
Sent: Wednesday, November 12, 2003 5:02 PM
To: spr...@li...
Subject: [[W3-SPAM]] - [Springframework-developer] when using
TransactionProxyFactoryBean, I need to proxy the target class - Email
found in subject


I need to somehow get TransactionProxyFactoryBean to allow proxying of=20
the target class.

revently a method proxyFactory.setProxyTargetClass(true) was introduced, =

though there is no way to get the TransactionProxyFactoryBean to make=20
this call.

maybe something like a new boolean parameter called proxyTargetClass to=20
pass on the hint ?

Thanks.

Cameron

--=20
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler =
http://www.martinfowler.com/distributedComputing/refactoring.pdf]





-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] MethodMatchers and Introductions

[roger h. <apo...@sn...>]

Sorry about the copy paste error - the error was clearly mine ;)

How does one now apply a MethodMatcher to the calls on an
IntroductionInterceptor ?

Does this require a separate InterceptionAdvice ?

Roger

[Springframework-developer] when using TransactionProxyFactoryBean, I need to proxy the target class

[Cameron B. <ca...@da...>]

I need to somehow get TransactionProxyFactoryBean to allow proxying of 
the target class.

revently a method proxyFactory.setProxyTargetClass(true) was introduced, 
though there is no way to get the TransactionProxyFactoryBean to make 
this call.

maybe something like a new boolean parameter called proxyTargetClass to 
pass on the hint ?

Thanks.

Cameron

-- 
Any damn fool can write code that a computer can understand...
The trick is to write code that humans can understand.
[Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf]