springframework-developer — Spring Framework developers list

RE : [Springframework-developer] Spring bean factory XML format

[JP P. <jp....@ti...>]

Hi Rod, J=C3=BCrgen,

I agree that formalism gains to be changed.
Mapping properties and CSV looked always strange.=20
We can keep compatibility, but release 0.8=20
before fixing the new one would be a bad beginning.

I'm not an XML expert, but worked with. I have some remarks:

First, attributes "name", "class" and "singleton" are straightforward =
and clean.
The "beanref" as a boolean had poor value and changed the meaning of the =
body! Avoiding this will be safer.
The main isuue is with organizing the "value" part.

Single values:
If anything is allowed in the body, the meaning shall always be the =
same. We can consider it will be the litteral value.
My proposition will be:
 	<property name=3D"xxx">yyy</bean>
An alternative could be accepted:
 	<property name=3D"xxx" value=3D"yyy"/>

If the unique value is a bean reference, the body has to be empty:
 	<property name=3D"xxx" ref=3D"zzz"/>

Multiple values:
I don't like=20
 	 <property name=3D"jumble">
 	   <ref name=3D"david"/>
 	   <value>literal</value>
 	   <ref name=3D"jenny" />
 	 </property>

The ref name=3D"xxx" has a poor value, we have two entities for only one =
information.

Because of different tag names. "ref" and "value" are both data in the =
collection.
I prefer such as:
 	 <property name=3D"jumble">
 	   <data ref=3D"david"/>
 	   <data value=3D"literal"/>
 	   <data>literal2</data>
 	   <data ref=3D"jenny" />
 	 </property>

The "data" element could have a better name.

So we could have a consistent definition, both in property and data:
The value is either the body either the value attribute.
The bean reference is always the ref attribute.

The property element could only have in its body a text(the sole =
litteral value) or a data elements collection.


Regards,
Jean-Pierre


> -----Message d'origine-----
> De : spr...@li...=20
> [mailto:spr...@li...]
>  De la part de j=C3=BCrgen h=C3=B6ller [werk3AT]
> Envoy=C3=A9 : mercredi 28 mai 2003 07:33
> =C3=80 : Rod Johnson; spr...@li...
> Objet : Re: [Springframework-developer] Spring bean factory XML format
>=20
>=20
> Hi Rod,
> =20
> I agree that the new format makes sense. I didn't think about=20
> validating the XML before, but to my understanding you're=20
> right about the pitfalls. Keeping backwards compatibility for=20
> the moment makes sense, as each and every application context=20
> definition will be affected (admittedly in a straightforward way).
> =20
> So besides the <ref> tag, there's a <value> tag now, for=20
> mixed collections. I guess it can also be used with a single=20
> value property like this:
> =20
> <property name=3D"name"><value>Rod</value></property>
>=20
> Do you recommend this syntax for such properties too? Does it=20
> add any value in terms of validation? We should definitely=20
> stick to one recommended syntax, to avoid confusion.
>=20
> Regarding beans that expose CSV properties: I've already=20
> tried to clean many of the exposed bean properties within=20
> Spring (e.g. both commandClass and commandClassName, now only=20
> the former because of the ClassEditor), we should try to=20
> continue this for multiple value properties. I guess if=20
> choice doesn't add real value, it rather causes confusion.
> =20
> I'm not an XML expert, so I can't really help in terms of=20
> further improvements. Does anyone else have some thoughts on this?
>=20
> Regards,
> Juergen
> =20
> =20
>=20
> 	-----Urspr=C3=BCngliche Nachricht-----=20
> 	Von: Rod Johnson [mailto:rod...@in...]=20
> 	Gesendet: Di 27.05.2003 22:19=20
> 	An: spr...@li...=20
> 	Cc:=20
> 	Betreff: Re: [Springframework-developer] Spring bean=20
> factory XML format
> =09
> =09
>=20
> 	I've successfully prototyped this idea.
> =09
> 	The new format looks like:
> =09
> 	<bean name=3D"rod" class=3D"com.interface21.beans.TestBean">
> 	 <property name=3D"name">Rod</property>
> 	 <property name=3D"age">32</property>
> 	 <property name=3D"friends">
> 	  <ref name=3D"jenny"/>
> 	  <ref name=3D"david"/>
> 	 </property>
> 	</bean>
> =09
> 	<!--
> 	 Try setting a collection property to a single value
> 	-->
> 	<bean name=3D"loner" class=3D"com.interface21.beans.TestBean">
> 	 <property name=3D"name">loner</property>
> 	 <property name=3D"age">26</property>
> 	 <property name=3D"friends">
> 	  <ref name=3D"david"/>
> 	 </property>
> 	</bean>
> =09
> 	<bean name=3D"jumble"
> 	class=3D"com.interface21.beans.factory.xml.MixedCollectionBean">
> 	 <property name=3D"jumble">
> 	   <ref name=3D"david"/>
> 	   <value>literal</value>
> 	   <ref name=3D"jenny" />
> 	 </property>
> 	</bean>
> =09
> 	I haven't dropped backward compatibility, or checked=20
> anything in.
> =09
> 	If we agree this is an improvement, I'll check in these=20
> changes this week. I
> 	guess I don't need to drop backward compatibility right=20
> now (beanRef), but
> 	I think it should be dropped before 1.0.
> =09
> 	I'm open to suggestions as to how to improve the XML further.
> =09
> 	Regards,
> 	Rod
> =09
> 	----- Original Message -----
> 	From: "Rod Johnson" <rod...@in...>
> 	To: <spr...@li...>
> 	Sent: Tuesday, May 27, 2003 6:20 PM
> 	Subject: [Springframework-developer] Spring bean=20
> factory XML format
> =09
> =09
> 	> Guys,
> 	>
> 	> I've just been thinking about an important potential issue.
> 	>
> 	> The current XML bean-reference syntax looks like:
> 	> <property name=3D"foo" beanRef=3D"true">myFooBean</property>
> 	>
> 	> and, for lists etc (where a bean exposes a "CSV" property)
> 	> <property name=3D"foos">a,b,c</property>
> 	>
> 	> While this syntax is concise, I think there are some=20
> issues we should
> 	> discuss.
> 	>
> 	> a. It's hard to validate this. There's no validatable=20
> reference to another
> 	> bean element id. It would be great if an XML editor=20
> could help us in this
> 	> regard.
> 	> b. It's inelegant. The use of the CDATA in the=20
> property element as a
> 	string
> 	> value or a reference (depending on the presence of an=20
> attribute) is a bit
> 	> messy.
> 	> c. The CSV format is really a hack, that I used once=20
> and then reused. Not
> 	> only does the CSV make no sense to an XML editor=20
> (analogous to putting CSV
> 	> data in an RDBMS), it places the onus on each class=20
> to parse the CSV and
> 	> look up the necessary beans. This makes classes=20
> exposing CSV properties
> 	> dependent on the owning BeanFactory, lessening the=20
> value of Spring's
> 	> transparence. (Admittedly this is concealed in=20
> framework classes, so it
> 	> doesn't really affect developers.) With the proposed=20
> new way, any
> 	> application code could benefit from collection &=20
> array support.
> 	> d. The new way would make it easy to write XSLT that=20
> showed relationships
> 	> among Spring beans. This could be handy for=20
> generating documentation about
> 	> Spring apps.
> 	>
> 	> So I've been thinking of changes along the lines of:
> 	>
> 	> <property name=3D"foo">
> 	>     <ref name=3D"myFooBean" />
> 	> </property>
> 	>
> 	> and
> 	>
> 	> <property name=3D"foos">
> 	>     <ref name=3D"a" />
> 	>     <ref name=3D"b"/>
> 	>     <ref name=3D"c"/>
> 	> </property>
> 	>
> 	> In this case the foos bean class would expose a=20
> Collection or array
> 	> property, and the bean factory would no how to=20
> populate that from the
> 	> runtime references. No dependence on the fw even for=20
> managing collection
> 	> properties.
> 	>
> 	> I've already prototyped the idea of a <ref>=20
> subelement, and that was
> 	pretty
> 	> simple to implement.  I'll experiment with=20
> collections tonight.
> 	>
> 	> Apart from changing XML files, the flow-on effect=20
> would mean that anything
> 	> that exposed a CSV property (like the AOP interceptor=20
> proxy) would change
> 	to
> 	> exposing a Collection or array.
> 	>
> 	> What do you think? I'd like thoughts on the following=20
> questions:
> 	>
> 	> 1. Does everyone agree that this is worth doing?
> 	>
> 	> 2. To support a collection including literal values,=20
> should we introduce a
> 	> new <value> element, meaning that simple properties=20
> would become
> 	> <property name=3D"foo"><value>canConvert this=20
> string</value></property>.
> 	More
> 	> verbose, but more elegant.
> 	>
> 	> 3. Is there a way to help XML enforce the references=20
> automatically? E.g.
> 	> change bean "name" to "id" and use a <href> instead=20
> of a <ref>? I haven't
> 	> had a chance to explore this yet, but hopefully=20
> someone knows XML better
> 	> than I do.
> 	>
> 	> 4. If this is worth doing, should we do it in 0.8,=20
> even if it delays the
> 	> release  (as it would)? On the one hand, we should=20
> try to release ASAP. On
> 	> the other hand, this change would break all existing=20
> applications. Even
> 	> though they'd be easy to fix, it might irritate=20
> users. So the choice is:
> 	> - release now with a likely incompatible change in store
> 	> - accept a delay
> 	>
> 	> We'd also have to introduce analogous support for the=20
> properties format,
> 	> which couldn't benefit from XML capabilities. The=20
> properties format would
> 	> probably change very little.
> 	>
> 	> Regards,
> 	> Rod
> 	>
> 	>
> 	>
> 	>
> 	> -------------------------------------------------------
> 	> This SF.net email is sponsored by: ObjectStore.
> 	> If flattening out C++ or Java code to make your=20
> application fit in a
> 	> relational database is painful, don't do it! Check=20
> out ObjectStore.
> 	> Now part of Progress Software.=20
> http://www.objectstore.net/sourceforge
> 	>=20
> _______________________________________________
> 	> Springframework-developer mailing list
> 	> Spr...@li...
> 	>=20
> > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> =09
> =09
> =09
> =09
> 	-------------------------------------------------------
> 	This SF.net email is sponsored by: ObjectStore.
> 	If flattening out C++ or Java code to make your=20
> application fit in a
> 	relational database is painful, don't do it! Check out=20
> ObjectStore.
> 	Now part of Progress Software.=20
> http://www.objectstore.net/sourceforge
> =09
> _______________________________________________
> 	Springframework-developer mailing list
> 	Spr...@li...
> =09
> > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> =09
>=20
> N=18HYX=E9=8A=B2un7+~V=20
> /u=EB=99=A9=CA=8Bj=C6=8Aj=D8=B7j=D8=9Djj vv
> =17=E8=92=8B9r=D4=A2
> >=DA=BAJ   y=CB=B6=EB=B2=8Bq =E7=AE=A6 G j)	=D4=AE)~{
> zZz=D7=B9=DB=A2y =1B=E9=B6=A6=CF=96+=CA=AD=C7=A2+=EB=96=B3 ~ G
>=20

Re: [Springframework-developer] Spring bean factory XML format

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

Juergen,

> I agree that the new format makes sense. I didn't think about validating
the XML before, but to my understanding you're right about the pitfalls.
Keeping backwards compatibility for the moment makes sense, as each and
every application context definition will be affected (admittedly in a
straightforward way).

Unless there are objections, I'll just check in the changes today. It's 100%
backward compatible, so all existing tests pass, and the existing test suite
covers all XML functionality.

I'll have to introduce support in properties format as well, but that's
really an enhancement, and doesn't affect existing use.

> So besides the <ref> tag, there's a <value> tag now, for mixed
collections. I guess it can also be used with a single value property like
this:
>
> <property name="name"><value>Rod</value></property>
>
> Do you recommend this syntax for such properties too? Does it add any
value in terms of validation? We should definitely stick to one recommended
syntax, to avoid confusion.

The new version accepts this, as well as the old form. I can't see great
validation superiority in the more verbose form. I agree it's best to have
only one approach. The only downside is the verbosity. I don't have any
strong views on this verbosity/consistency tradeoff. The <value> syntax
might be better in XML editors: you can see that you can have multiple
choices of ref or value elements within a property.

Also, Isabelle asked for a DTD. With the new format (overall) this should be
more meaningful.

> Regarding beans that expose CSV properties: I've already tried to clean
many of the exposed bean properties within Spring (e.g. both commandClass
and commandClassName, now only the former because of the ClassEditor), we
should try to continue this for multiple value properties. I guess if choice
doesn't add real value, it rather causes confusion.

Yes. CSV properties should go. I'll start with the AOP stuff.

> I'm not an XML expert, so I can't really help in terms of further
improvements. Does anyone else have some thoughts on this?

I think the "name" attribute may need to become "id" for validation, and my
new "ref" element maybe should be "href"? Anyway, it's trivial to change the
names of the XML, so I don't need to do this all at once.

Regards,
Rod

Re: [Springframework-developer] Spring bean factory XML format

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

SGkgUm9kLA0KIA0KSSBhZ3JlZSB0aGF0IHRoZSBuZXcgZm9ybWF0IG1ha2VzIHNlbnNlLiBJIGRp
ZG4ndCB0aGluayBhYm91dCB2YWxpZGF0aW5nIHRoZSBYTUwgYmVmb3JlLCBidXQgdG8gbXkgdW5k
ZXJzdGFuZGluZyB5b3UncmUgcmlnaHQgYWJvdXQgdGhlIHBpdGZhbGxzLiBLZWVwaW5nIGJhY2t3
YXJkcyBjb21wYXRpYmlsaXR5IGZvciB0aGUgbW9tZW50IG1ha2VzIHNlbnNlLCBhcyBlYWNoIGFu
ZCBldmVyeSBhcHBsaWNhdGlvbiBjb250ZXh0IGRlZmluaXRpb24gd2lsbCBiZSBhZmZlY3RlZCAo
YWRtaXR0ZWRseSBpbiBhIHN0cmFpZ2h0Zm9yd2FyZCB3YXkpLg0KIA0KU28gYmVzaWRlcyB0aGUg
PHJlZj4gdGFnLCB0aGVyZSdzIGEgPHZhbHVlPiB0YWcgbm93LCBmb3IgbWl4ZWQgY29sbGVjdGlv
bnMuIEkgZ3Vlc3MgaXQgY2FuIGFsc28gYmUgdXNlZCB3aXRoIGEgc2luZ2xlIHZhbHVlIHByb3Bl
cnR5IGxpa2UgdGhpczoNCiANCjxwcm9wZXJ0eSBuYW1lPSJuYW1lIj48dmFsdWU+Um9kPC92YWx1
ZT48L3Byb3BlcnR5Pg0KDQpEbyB5b3UgcmVjb21tZW5kIHRoaXMgc3ludGF4IGZvciBzdWNoIHBy
b3BlcnRpZXMgdG9vPyBEb2VzIGl0IGFkZCBhbnkgdmFsdWUgaW4gdGVybXMgb2YgdmFsaWRhdGlv
bj8gV2Ugc2hvdWxkIGRlZmluaXRlbHkgc3RpY2sgdG8gb25lIHJlY29tbWVuZGVkIHN5bnRheCwg
dG8gYXZvaWQgY29uZnVzaW9uLg0KDQpSZWdhcmRpbmcgYmVhbnMgdGhhdCBleHBvc2UgQ1NWIHBy
b3BlcnRpZXM6IEkndmUgYWxyZWFkeSB0cmllZCB0byBjbGVhbiBtYW55IG9mIHRoZSBleHBvc2Vk
IGJlYW4gcHJvcGVydGllcyB3aXRoaW4gU3ByaW5nIChlLmcuIGJvdGggY29tbWFuZENsYXNzIGFu
ZCBjb21tYW5kQ2xhc3NOYW1lLCBub3cgb25seSB0aGUgZm9ybWVyIGJlY2F1c2Ugb2YgdGhlIENs
YXNzRWRpdG9yKSwgd2Ugc2hvdWxkIHRyeSB0byBjb250aW51ZSB0aGlzIGZvciBtdWx0aXBsZSB2
YWx1ZSBwcm9wZXJ0aWVzLiBJIGd1ZXNzIGlmIGNob2ljZSBkb2Vzbid0IGFkZCByZWFsIHZhbHVl
LCBpdCByYXRoZXIgY2F1c2VzIGNvbmZ1c2lvbi4NCiANCkknbSBub3QgYW4gWE1MIGV4cGVydCwg
c28gSSBjYW4ndCByZWFsbHkgaGVscCBpbiB0ZXJtcyBvZiBmdXJ0aGVyIGltcHJvdmVtZW50cy4g
RG9lcyBhbnlvbmUgZWxzZSBoYXZlIHNvbWUgdGhvdWdodHMgb24gdGhpcz8NCg0KUmVnYXJkcywN
Ckp1ZXJnZW4NCiANCiANCg0KCS0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0gDQoJ
Vm9uOiBSb2QgSm9obnNvbiBbbWFpbHRvOnJvZC5qb2huc29uQGludGVyZmFjZTIxLmNvbV0gDQoJ
R2VzZW5kZXQ6IERpIDI3LjA1LjIwMDMgMjI6MTkgDQoJQW46IHNwcmluZ2ZyYW1ld29yay1kZXZl
bG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KCUNjOiANCglCZXRyZWZmOiBSZTogW1Nwcmlu
Z2ZyYW1ld29yay1kZXZlbG9wZXJdIFNwcmluZyBiZWFuIGZhY3RvcnkgWE1MIGZvcm1hdA0KCQ0K
CQ0KDQoJSSd2ZSBzdWNjZXNzZnVsbHkgcHJvdG90eXBlZCB0aGlzIGlkZWEuDQoJDQoJVGhlIG5l
dyBmb3JtYXQgbG9va3MgbGlrZToNCgkNCgk8YmVhbiBuYW1lPSJyb2QiIGNsYXNzPSJjb20uaW50
ZXJmYWNlMjEuYmVhbnMuVGVzdEJlYW4iPg0KCSA8cHJvcGVydHkgbmFtZT0ibmFtZSI+Um9kPC9w
cm9wZXJ0eT4NCgkgPHByb3BlcnR5IG5hbWU9ImFnZSI+MzI8L3Byb3BlcnR5Pg0KCSA8cHJvcGVy
dHkgbmFtZT0iZnJpZW5kcyI+DQoJICA8cmVmIG5hbWU9Implbm55Ii8+DQoJICA8cmVmIG5hbWU9
ImRhdmlkIi8+DQoJIDwvcHJvcGVydHk+DQoJPC9iZWFuPg0KCQ0KCTwhLS0NCgkgVHJ5IHNldHRp
bmcgYSBjb2xsZWN0aW9uIHByb3BlcnR5IHRvIGEgc2luZ2xlIHZhbHVlDQoJLS0+DQoJPGJlYW4g
bmFtZT0ibG9uZXIiIGNsYXNzPSJjb20uaW50ZXJmYWNlMjEuYmVhbnMuVGVzdEJlYW4iPg0KCSA8
cHJvcGVydHkgbmFtZT0ibmFtZSI+bG9uZXI8L3Byb3BlcnR5Pg0KCSA8cHJvcGVydHkgbmFtZT0i
YWdlIj4yNjwvcHJvcGVydHk+DQoJIDxwcm9wZXJ0eSBuYW1lPSJmcmllbmRzIj4NCgkgIDxyZWYg
bmFtZT0iZGF2aWQiLz4NCgkgPC9wcm9wZXJ0eT4NCgk8L2JlYW4+DQoJDQoJPGJlYW4gbmFtZT0i
anVtYmxlIg0KCWNsYXNzPSJjb20uaW50ZXJmYWNlMjEuYmVhbnMuZmFjdG9yeS54bWwuTWl4ZWRD
b2xsZWN0aW9uQmVhbiI+DQoJIDxwcm9wZXJ0eSBuYW1lPSJqdW1ibGUiPg0KCSAgIDxyZWYgbmFt
ZT0iZGF2aWQiLz4NCgkgICA8dmFsdWU+bGl0ZXJhbDwvdmFsdWU+DQoJICAgPHJlZiBuYW1lPSJq
ZW5ueSIgLz4NCgkgPC9wcm9wZXJ0eT4NCgk8L2JlYW4+DQoJDQoJSSBoYXZlbid0IGRyb3BwZWQg
YmFja3dhcmQgY29tcGF0aWJpbGl0eSwgb3IgY2hlY2tlZCBhbnl0aGluZyBpbi4NCgkNCglJZiB3
ZSBhZ3JlZSB0aGlzIGlzIGFuIGltcHJvdmVtZW50LCBJJ2xsIGNoZWNrIGluIHRoZXNlIGNoYW5n
ZXMgdGhpcyB3ZWVrLiBJDQoJZ3Vlc3MgSSBkb24ndCBuZWVkIHRvIGRyb3AgYmFja3dhcmQgY29t
cGF0aWJpbGl0eSByaWdodCBub3cgKGJlYW5SZWYpLCBidXQNCglJIHRoaW5rIGl0IHNob3VsZCBi
ZSBkcm9wcGVkIGJlZm9yZSAxLjAuDQoJDQoJSSdtIG9wZW4gdG8gc3VnZ2VzdGlvbnMgYXMgdG8g
aG93IHRvIGltcHJvdmUgdGhlIFhNTCBmdXJ0aGVyLg0KCQ0KCVJlZ2FyZHMsDQoJUm9kDQoJDQoJ
LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KCUZyb206ICJSb2QgSm9obnNvbiIgPHJvZC5q
b2huc29uQGludGVyZmFjZTIxLmNvbT4NCglUbzogPHNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJA
bGlzdHMuc291cmNlZm9yZ2UubmV0Pg0KCVNlbnQ6IFR1ZXNkYXksIE1heSAyNywgMjAwMyA2OjIw
IFBNDQoJU3ViamVjdDogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIFNwcmluZyBiZWFuIGZh
Y3RvcnkgWE1MIGZvcm1hdA0KCQ0KCQ0KCT4gR3V5cywNCgk+DQoJPiBJJ3ZlIGp1c3QgYmVlbiB0
aGlua2luZyBhYm91dCBhbiBpbXBvcnRhbnQgcG90ZW50aWFsIGlzc3VlLg0KCT4NCgk+IFRoZSBj
dXJyZW50IFhNTCBiZWFuLXJlZmVyZW5jZSBzeW50YXggbG9va3MgbGlrZToNCgk+IDxwcm9wZXJ0
eSBuYW1lPSJmb28iIGJlYW5SZWY9InRydWUiPm15Rm9vQmVhbjwvcHJvcGVydHk+DQoJPg0KCT4g
YW5kLCBmb3IgbGlzdHMgZXRjICh3aGVyZSBhIGJlYW4gZXhwb3NlcyBhICJDU1YiIHByb3BlcnR5
KQ0KCT4gPHByb3BlcnR5IG5hbWU9ImZvb3MiPmEsYixjPC9wcm9wZXJ0eT4NCgk+DQoJPiBXaGls
ZSB0aGlzIHN5bnRheCBpcyBjb25jaXNlLCBJIHRoaW5rIHRoZXJlIGFyZSBzb21lIGlzc3VlcyB3
ZSBzaG91bGQNCgk+IGRpc2N1c3MuDQoJPg0KCT4gYS4gSXQncyBoYXJkIHRvIHZhbGlkYXRlIHRo
aXMuIFRoZXJlJ3Mgbm8gdmFsaWRhdGFibGUgcmVmZXJlbmNlIHRvIGFub3RoZXINCgk+IGJlYW4g
ZWxlbWVudCBpZC4gSXQgd291bGQgYmUgZ3JlYXQgaWYgYW4gWE1MIGVkaXRvciBjb3VsZCBoZWxw
IHVzIGluIHRoaXMNCgk+IHJlZ2FyZC4NCgk+IGIuIEl0J3MgaW5lbGVnYW50LiBUaGUgdXNlIG9m
IHRoZSBDREFUQSBpbiB0aGUgcHJvcGVydHkgZWxlbWVudCBhcyBhDQoJc3RyaW5nDQoJPiB2YWx1
ZSBvciBhIHJlZmVyZW5jZSAoZGVwZW5kaW5nIG9uIHRoZSBwcmVzZW5jZSBvZiBhbiBhdHRyaWJ1
dGUpIGlzIGEgYml0DQoJPiBtZXNzeS4NCgk+IGMuIFRoZSBDU1YgZm9ybWF0IGlzIHJlYWxseSBh
IGhhY2ssIHRoYXQgSSB1c2VkIG9uY2UgYW5kIHRoZW4gcmV1c2VkLiBOb3QNCgk+IG9ubHkgZG9l
cyB0aGUgQ1NWIG1ha2Ugbm8gc2Vuc2UgdG8gYW4gWE1MIGVkaXRvciAoYW5hbG9nb3VzIHRvIHB1
dHRpbmcgQ1NWDQoJPiBkYXRhIGluIGFuIFJEQk1TKSwgaXQgcGxhY2VzIHRoZSBvbnVzIG9uIGVh
Y2ggY2xhc3MgdG8gcGFyc2UgdGhlIENTViBhbmQNCgk+IGxvb2sgdXAgdGhlIG5lY2Vzc2FyeSBi
ZWFucy4gVGhpcyBtYWtlcyBjbGFzc2VzIGV4cG9zaW5nIENTViBwcm9wZXJ0aWVzDQoJPiBkZXBl
bmRlbnQgb24gdGhlIG93bmluZyBCZWFuRmFjdG9yeSwgbGVzc2VuaW5nIHRoZSB2YWx1ZSBvZiBT
cHJpbmcncw0KCT4gdHJhbnNwYXJlbmNlLiAoQWRtaXR0ZWRseSB0aGlzIGlzIGNvbmNlYWxlZCBp
biBmcmFtZXdvcmsgY2xhc3Nlcywgc28gaXQNCgk+IGRvZXNuJ3QgcmVhbGx5IGFmZmVjdCBkZXZl
bG9wZXJzLikgV2l0aCB0aGUgcHJvcG9zZWQgbmV3IHdheSwgYW55DQoJPiBhcHBsaWNhdGlvbiBj
b2RlIGNvdWxkIGJlbmVmaXQgZnJvbSBjb2xsZWN0aW9uICYgYXJyYXkgc3VwcG9ydC4NCgk+IGQu
IFRoZSBuZXcgd2F5IHdvdWxkIG1ha2UgaXQgZWFzeSB0byB3cml0ZSBYU0xUIHRoYXQgc2hvd2Vk
IHJlbGF0aW9uc2hpcHMNCgk+IGFtb25nIFNwcmluZyBiZWFucy4gVGhpcyBjb3VsZCBiZSBoYW5k
eSBmb3IgZ2VuZXJhdGluZyBkb2N1bWVudGF0aW9uIGFib3V0DQoJPiBTcHJpbmcgYXBwcy4NCgk+
DQoJPiBTbyBJJ3ZlIGJlZW4gdGhpbmtpbmcgb2YgY2hhbmdlcyBhbG9uZyB0aGUgbGluZXMgb2Y6
DQoJPg0KCT4gPHByb3BlcnR5IG5hbWU9ImZvbyI+DQoJPiAgICAgPHJlZiBuYW1lPSJteUZvb0Jl
YW4iIC8+DQoJPiA8L3Byb3BlcnR5Pg0KCT4NCgk+IGFuZA0KCT4NCgk+IDxwcm9wZXJ0eSBuYW1l
PSJmb29zIj4NCgk+ICAgICA8cmVmIG5hbWU9ImEiIC8+DQoJPiAgICAgPHJlZiBuYW1lPSJiIi8+
DQoJPiAgICAgPHJlZiBuYW1lPSJjIi8+DQoJPiA8L3Byb3BlcnR5Pg0KCT4NCgk+IEluIHRoaXMg
Y2FzZSB0aGUgZm9vcyBiZWFuIGNsYXNzIHdvdWxkIGV4cG9zZSBhIENvbGxlY3Rpb24gb3IgYXJy
YXkNCgk+IHByb3BlcnR5LCBhbmQgdGhlIGJlYW4gZmFjdG9yeSB3b3VsZCBubyBob3cgdG8gcG9w
dWxhdGUgdGhhdCBmcm9tIHRoZQ0KCT4gcnVudGltZSByZWZlcmVuY2VzLiBObyBkZXBlbmRlbmNl
IG9uIHRoZSBmdyBldmVuIGZvciBtYW5hZ2luZyBjb2xsZWN0aW9uDQoJPiBwcm9wZXJ0aWVzLg0K
CT4NCgk+IEkndmUgYWxyZWFkeSBwcm90b3R5cGVkIHRoZSBpZGVhIG9mIGEgPHJlZj4gc3ViZWxl
bWVudCwgYW5kIHRoYXQgd2FzDQoJcHJldHR5DQoJPiBzaW1wbGUgdG8gaW1wbGVtZW50LiAgSSds
bCBleHBlcmltZW50IHdpdGggY29sbGVjdGlvbnMgdG9uaWdodC4NCgk+DQoJPiBBcGFydCBmcm9t
IGNoYW5naW5nIFhNTCBmaWxlcywgdGhlIGZsb3ctb24gZWZmZWN0IHdvdWxkIG1lYW4gdGhhdCBh
bnl0aGluZw0KCT4gdGhhdCBleHBvc2VkIGEgQ1NWIHByb3BlcnR5IChsaWtlIHRoZSBBT1AgaW50
ZXJjZXB0b3IgcHJveHkpIHdvdWxkIGNoYW5nZQ0KCXRvDQoJPiBleHBvc2luZyBhIENvbGxlY3Rp
b24gb3IgYXJyYXkuDQoJPg0KCT4gV2hhdCBkbyB5b3UgdGhpbms/IEknZCBsaWtlIHRob3VnaHRz
IG9uIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zOg0KCT4NCgk+IDEuIERvZXMgZXZlcnlvbmUgYWdy
ZWUgdGhhdCB0aGlzIGlzIHdvcnRoIGRvaW5nPw0KCT4NCgk+IDIuIFRvIHN1cHBvcnQgYSBjb2xs
ZWN0aW9uIGluY2x1ZGluZyBsaXRlcmFsIHZhbHVlcywgc2hvdWxkIHdlIGludHJvZHVjZSBhDQoJ
PiBuZXcgPHZhbHVlPiBlbGVtZW50LCBtZWFuaW5nIHRoYXQgc2ltcGxlIHByb3BlcnRpZXMgd291
bGQgYmVjb21lDQoJPiA8cHJvcGVydHkgbmFtZT0iZm9vIj48dmFsdWU+Y2FuQ29udmVydCB0aGlz
IHN0cmluZzwvdmFsdWU+PC9wcm9wZXJ0eT4uDQoJTW9yZQ0KCT4gdmVyYm9zZSwgYnV0IG1vcmUg
ZWxlZ2FudC4NCgk+DQoJPiAzLiBJcyB0aGVyZSBhIHdheSB0byBoZWxwIFhNTCBlbmZvcmNlIHRo
ZSByZWZlcmVuY2VzIGF1dG9tYXRpY2FsbHk/IEUuZy4NCgk+IGNoYW5nZSBiZWFuICJuYW1lIiB0
byAiaWQiIGFuZCB1c2UgYSA8aHJlZj4gaW5zdGVhZCBvZiBhIDxyZWY+PyBJIGhhdmVuJ3QNCgk+
IGhhZCBhIGNoYW5jZSB0byBleHBsb3JlIHRoaXMgeWV0LCBidXQgaG9wZWZ1bGx5IHNvbWVvbmUg
a25vd3MgWE1MIGJldHRlcg0KCT4gdGhhbiBJIGRvLg0KCT4NCgk+IDQuIElmIHRoaXMgaXMgd29y
dGggZG9pbmcsIHNob3VsZCB3ZSBkbyBpdCBpbiAwLjgsIGV2ZW4gaWYgaXQgZGVsYXlzIHRoZQ0K
CT4gcmVsZWFzZSAgKGFzIGl0IHdvdWxkKT8gT24gdGhlIG9uZSBoYW5kLCB3ZSBzaG91bGQgdHJ5
IHRvIHJlbGVhc2UgQVNBUC4gT24NCgk+IHRoZSBvdGhlciBoYW5kLCB0aGlzIGNoYW5nZSB3b3Vs
ZCBicmVhayBhbGwgZXhpc3RpbmcgYXBwbGljYXRpb25zLiBFdmVuDQoJPiB0aG91Z2ggdGhleSdk
IGJlIGVhc3kgdG8gZml4LCBpdCBtaWdodCBpcnJpdGF0ZSB1c2Vycy4gU28gdGhlIGNob2ljZSBp
czoNCgk+IC0gcmVsZWFzZSBub3cgd2l0aCBhIGxpa2VseSBpbmNvbXBhdGlibGUgY2hhbmdlIGlu
IHN0b3JlDQoJPiAtIGFjY2VwdCBhIGRlbGF5DQoJPg0KCT4gV2UnZCBhbHNvIGhhdmUgdG8gaW50
cm9kdWNlIGFuYWxvZ291cyBzdXBwb3J0IGZvciB0aGUgcHJvcGVydGllcyBmb3JtYXQsDQoJPiB3
aGljaCBjb3VsZG4ndCBiZW5lZml0IGZyb20gWE1MIGNhcGFiaWxpdGllcy4gVGhlIHByb3BlcnRp
ZXMgZm9ybWF0IHdvdWxkDQoJPiBwcm9iYWJseSBjaGFuZ2UgdmVyeSBsaXR0bGUuDQoJPg0KCT4g
UmVnYXJkcywNCgk+IFJvZA0KCT4NCgk+DQoJPg0KCT4NCgk+IC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCgk+IFRoaXMgU0YubmV0IGVtYWls
IGlzIHNwb25zb3JlZCBieTogT2JqZWN0U3RvcmUuDQoJPiBJZiBmbGF0dGVuaW5nIG91dCBDKysg
b3IgSmF2YSBjb2RlIHRvIG1ha2UgeW91ciBhcHBsaWNhdGlvbiBmaXQgaW4gYQ0KCT4gcmVsYXRp
b25hbCBkYXRhYmFzZSBpcyBwYWluZnVsLCBkb24ndCBkbyBpdCEgQ2hlY2sgb3V0IE9iamVjdFN0
b3JlLg0KCT4gTm93IHBhcnQgb2YgUHJvZ3Jlc3MgU29mdHdhcmUuIGh0dHA6Ly93d3cub2JqZWN0
c3RvcmUubmV0L3NvdXJjZWZvcmdlDQoJPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KCT4gU3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciBtYWlsaW5nIGxp
c3QNCgk+IFNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJ
PiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFt
ZXdvcmstZGV2ZWxvcGVyDQoJDQoJDQoJDQoJDQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCVRoaXMgU0YubmV0IGVtYWlsIGlzIHNwb25z
b3JlZCBieTogT2JqZWN0U3RvcmUuDQoJSWYgZmxhdHRlbmluZyBvdXQgQysrIG9yIEphdmEgY29k
ZSB0byBtYWtlIHlvdXIgYXBwbGljYXRpb24gZml0IGluIGENCglyZWxhdGlvbmFsIGRhdGFiYXNl
IGlzIHBhaW5mdWwsIGRvbid0IGRvIGl0ISBDaGVjayBvdXQgT2JqZWN0U3RvcmUuDQoJTm93IHBh
cnQgb2YgUHJvZ3Jlc3MgU29mdHdhcmUuIGh0dHA6Ly93d3cub2JqZWN0c3RvcmUubmV0L3NvdXJj
ZWZvcmdlDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
CglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1haWxpbmcgbGlzdA0KCVNwcmluZ2ZyYW1ld29y
ay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJaHR0cHM6Ly9saXN0cy5zb3VyY2Vm
b3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcg0KCQ0KDQo=

Re: [Springframework-developer] Spring bean factory XML format

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

I've successfully prototyped this idea.

The new format looks like:

<bean name="rod" class="com.interface21.beans.TestBean">
 <property name="name">Rod</property>
 <property name="age">32</property>
 <property name="friends">
  <ref name="jenny"/>
  <ref name="david"/>
 </property>
</bean>

<!--
 Try setting a collection property to a single value
-->
<bean name="loner" class="com.interface21.beans.TestBean">
 <property name="name">loner</property>
 <property name="age">26</property>
 <property name="friends">
  <ref name="david"/>
 </property>
</bean>

<bean name="jumble"
class="com.interface21.beans.factory.xml.MixedCollectionBean">
 <property name="jumble">
   <ref name="david"/>
   <value>literal</value>
   <ref name="jenny" />
 </property>
</bean>

I haven't dropped backward compatibility, or checked anything in.

If we agree this is an improvement, I'll check in these changes this week. I
guess I don't need to drop backward compatibility right now (beanRef), but
I think it should be dropped before 1.0.

I'm open to suggestions as to how to improve the XML further.

Regards,
Rod

----- Original Message -----
From: "Rod Johnson" <rod...@in...>
To: <spr...@li...>
Sent: Tuesday, May 27, 2003 6:20 PM
Subject: [Springframework-developer] Spring bean factory XML format


> Guys,
>
> I've just been thinking about an important potential issue.
>
> The current XML bean-reference syntax looks like:
> <property name="foo" beanRef="true">myFooBean</property>
>
> and, for lists etc (where a bean exposes a "CSV" property)
> <property name="foos">a,b,c</property>
>
> While this syntax is concise, I think there are some issues we should
> discuss.
>
> a. It's hard to validate this. There's no validatable reference to another
> bean element id. It would be great if an XML editor could help us in this
> regard.
> b. It's inelegant. The use of the CDATA in the property element as a
string
> value or a reference (depending on the presence of an attribute) is a bit
> messy.
> c. The CSV format is really a hack, that I used once and then reused. Not
> only does the CSV make no sense to an XML editor (analogous to putting CSV
> data in an RDBMS), it places the onus on each class to parse the CSV and
> look up the necessary beans. This makes classes exposing CSV properties
> dependent on the owning BeanFactory, lessening the value of Spring's
> transparence. (Admittedly this is concealed in framework classes, so it
> doesn't really affect developers.) With the proposed new way, any
> application code could benefit from collection & array support.
> d. The new way would make it easy to write XSLT that showed relationships
> among Spring beans. This could be handy for generating documentation about
> Spring apps.
>
> So I've been thinking of changes along the lines of:
>
> <property name="foo">
>     <ref name="myFooBean" />
> </property>
>
> and
>
> <property name="foos">
>     <ref name="a" />
>     <ref name="b"/>
>     <ref name="c"/>
> </property>
>
> In this case the foos bean class would expose a Collection or array
> property, and the bean factory would no how to populate that from the
> runtime references. No dependence on the fw even for managing collection
> properties.
>
> I've already prototyped the idea of a <ref> subelement, and that was
pretty
> simple to implement.  I'll experiment with collections tonight.
>
> Apart from changing XML files, the flow-on effect would mean that anything
> that exposed a CSV property (like the AOP interceptor proxy) would change
to
> exposing a Collection or array.
>
> What do you think? I'd like thoughts on the following questions:
>
> 1. Does everyone agree that this is worth doing?
>
> 2. To support a collection including literal values, should we introduce a
> new <value> element, meaning that simple properties would become
> <property name="foo"><value>canConvert this string</value></property>.
More
> verbose, but more elegant.
>
> 3. Is there a way to help XML enforce the references automatically? E.g.
> change bean "name" to "id" and use a <href> instead of a <ref>? I haven't
> had a chance to explore this yet, but hopefully someone knows XML better
> than I do.
>
> 4. If this is worth doing, should we do it in 0.8, even if it delays the
> release  (as it would)? On the one hand, we should try to release ASAP. On
> the other hand, this change would break all existing applications. Even
> though they'd be easy to fix, it might irritate users. So the choice is:
> - release now with a likely incompatible change in store
> - accept a delay
>
> We'd also have to introduce analogous support for the properties format,
> which couldn't benefit from XML capabilities. The properties format would
> probably change very little.
>
> Regards,
> Rod
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] DataSource setup in an ApplicationContext

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

VGhlIHByZXZpb3VzIG1haWwgYXNzdW1lcyB0aGF0IHlvdSBwcm92aWRlIHNwZWNpYWwgYXBwbGlj
YXRpb25Db250ZXh0LnhtbCBmaWxlcyBmb3IgdGVzdCBvciBzdGFuZGFsb25lIGVudmlyb25tZW50
cywgd2l0aCBhbHRlcm5hdGUgZGF0YVNvdXJjZSBkZWZpbml0aW9ucy4gVGhpcyBhbGxvd3MgZm9y
IGNvbnZlbmllbnQgY29uZmlndXJhdGlvbiB2aWEgdGhlIGJlYW4gZmFjdG9yeS4NCiANCkFuIGFs
dGVybmF0aXZlIHdheSBpcyB0byBzZXQgdXAgYSBtb2NrIEpOREkgZW52aXJvbm1lbnQgKGNvbS5p
bnRlcmZhY2UyMS5qbmRpLm1vY2spLiBUaGUgZXhhY3RseSBzYW1lIGFwcGxpY2F0aW9uQ29udGV4
dC54bWwgZmlsZSBsaWtlIHdpdGhpbiBhIEoyRUUgY29udGFpbmVyIGNhbiBiZSB1c2VkIHRoZW4g
KGluY2x1ZGluZyBhIEpuZGlPYmplY3RGYWN0b3J5QmVhbiBkZWZpbml0aW9uKSwgaWYgYSBEYXRh
U291cmNlIGxpa2UgU2luZ2xlQ29ubmVjdGlvbkRhdGFTb3VyY2UgaXMgbWFudWFsbHkgYm91bmQg
dG8gdGhlIGV4cGVjdGVkIEpOREkgbG9jYXRpb24uIFRoaXMgd2lsbCBhbHNvIHdvcmsgd2l0aCBw
ZXJzaXN0ZW5jZSB0b29sa2l0cyBsaWtlIEhpYmVybmF0ZSB0aGF0IHVzZSB0aGUgSk5ESSBEYXRh
U291cmNlIC0gbm8gY29uZmlnIGNoYW5nZSByZXF1aXJlZCBoZXJlIHRvby4NCiANCkluIGFueSBj
YXNlLCB0aGUgYXBwbGljYXRpb25Db250ZXh0LnhtbCBuZWVkcyB0byBiZSByZWFkIGJ5IGEgRmls
ZVN5c3RlbVhtbEFwcGxpY2F0aW9uQ29udGV4dCBpbnN0ZWFkIG9mIGEgWG1sV2ViQXBwbGljYXRp
b25Db250ZXh0LiBJZiB5b3Ugc2V0IHRoZSB3b3JraW5nIGRpcmVjdG9yeSBvZiBhIHRlc3QgZW52
aXJvbm1lbnQgdG8geW91ciB3ZWIgYXBwIHJvb3QsIGV2ZW4gYWxsIHRoZSByZWxhdGl2ZSBwYXRo
cyB3aWxsIHdvcmsuIFRoZSBsb2c0SidzIHN5c3RlbSBwcm9wZXJ0eSBrbm93biBhcyB3ZWJBcHBS
b290S2V5IGNhbiBiZSBpbml0aWFsaXplZCBlYXNpbHkgd2l0aCBMb2c0akNvbmZpZ3VyZXIsIHRv
IGJlIGFibGUgdG8gdXNlIHRoZSBzYW1lIHJlbGF0aXZlIHBhdGhzIGluIHRoZSBMb2c0SiBjb25m
aWcgZmlsZS4gV2UgYXJlIHVzaW5nIHN1Y2ggYSBzZXR1cCBzdWNjZXNzZnVsbHkgaW4gYSBwcm9q
ZWN0IGF0IHdlcmszQVQuDQogDQpKdWVyZ2VuDQogDQogDQoNCgktLS0tLVVyc3Byw7xuZ2xpY2hl
IE5hY2hyaWNodC0tLS0tIA0KCVZvbjogasO8cmdlbiBow7ZsbGVyIFt3ZXJrM0FUXSANCglHZXNl
bmRldDogRGkgMjcuMDUuMjAwMyAyMDoyOSANCglBbjogc3ByaW5nZnJhbWV3b3JrLWRldmVsb3Bl
ckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgDQoJQ2M6IA0KCUJldHJlZmY6IFtTcHJpbmdmcmFtZXdv
cmstZGV2ZWxvcGVyXSBEYXRhU291cmNlIHNldHVwIGluIGFuIEFwcGxpY2F0aW9uQ29udGV4dA0K
CQ0KCQ0KDQoJT24gYW4gb2NjYXNpb24sIHNvbWUgZXhhbXBsZXMgZm9yIHNldHRpbmcgdXAgYSBE
YXRhU291cmNlIGluIGEgU3ByaW5nIEFwcGxpY2F0aW9uQ29udGV4dC4gQWxsIG9mIHRoZW0gY2Fu
IGJlIHBhc3NlZCB0byB0aGUgZGF0YVNvdXJjZSBwcm9wZXJ0eSBvZiBEYXRhU291cmNlVHJhbnNh
Y3Rpb25NYW5hZ2VyLCBKZGJjVGVtcGxhdGUsIG9yIGN1c3RvbSBiZWFucyBhcyBiZWFuIHJlZmVy
ZW5jZS4gU3dpdGNoaW5nIGJldHdlZW4gdGhlbSBpcyB0aHVzIGEgbWF0dGVyIG9mIGNvbmZpZ3Vy
YXRpb24gLSBqdXN0IGFjdGl2YXRlIHRoZSByZXNwZWN0aXZlIGJlYW4gZGVmaW5pdGlvbi4NCgkN
CgkNCglBIG1vY2sgRGF0YVNvdXJjZSB0aGF0IHdyYXBzIGEgc2luZ2xlIGNvbm5lY3Rpb24gKG1h
aW5seSBmb3IgdGVzdCBzdWl0ZXMpOg0KCQ0KCTxiZWFuIG5hbWU9ImRhdGFTb3VyY2UiIGNsYXNz
PSJjb20uaW50ZXJmYWNlMjEuamRiYy5kYXRhc291cmNlLlNpbmdsZUNvbm5lY3Rpb25EYXRhU291
cmNlIj4NCgkgICAgICAgIDxwcm9wZXJ0eSBuYW1lPSJzdXBwcmVzc0Nsb3NlIj50cnVlPC9wcm9w
ZXJ0eT4NCgkgICAgICAgIDxwcm9wZXJ0eSBuYW1lPSJkcml2ZXJOYW1lIj5jb20ubXlzcWwuamRi
Yy5Ecml2ZXI8L3Byb3BlcnR5Pg0KCSAgICAgICAgPHByb3BlcnR5IG5hbWU9InVybCI+amRiYzpt
eXNxbDovL2xvY2FsaG9zdDozMzA2L2NieDwvcHJvcGVydHk+DQoJICAgICAgICA8cHJvcGVydHkg
bmFtZT0idXNlciI+cm9vdDwvcHJvcGVydHk+DQoJPC9iZWFuPg0KCQ0KCQ0KCUEgbW9jayBEYXRh
U291cmNlIHRoYXQgY3JlYXRlcyBhIG5ldyBjb25uZWN0aW9uIG9uIGV2ZXJ5IGdldENvbm5lY3Rp
b24gY2FsbDoNCgkNCgk8YmVhbiBuYW1lPSJkYXRhU291cmNlIiBjbGFzcz0iY29tLmludGVyZmFj
ZTIxLmpkYmMuZGF0YXNvdXJjZS5Ecml2ZXJNYW5hZ2VyRGF0YVNvdXJjZSI+DQoJICAgICAgICA8
cHJvcGVydHkgbmFtZT0iZHJpdmVyTmFtZSI+Y29tLm15c3FsLmpkYmMuRHJpdmVyPC9wcm9wZXJ0
eT4NCgkgICAgICAgIDxwcm9wZXJ0eSBuYW1lPSJ1cmwiPmpkYmM6bXlzcWw6Ly9sb2NhbGhvc3Q6
MzMwNi9jYng8L3Byb3BlcnR5Pg0KCSAgICAgICAgPHByb3BlcnR5IG5hbWU9InVzZXIiPnJvb3Q8
L3Byb3BlcnR5Pg0KCTwvYmVhbj4NCgkNCgkNCglBbiBleGFtcGxlIGZvciBhIHBvb2xpbmcgQXBh
Y2hlIENvbW1vbnMgREJDUCBEYXRhU291cmNlOg0KCQ0KCTxiZWFuIG5hbWU9ImRhdGFTb3VyY2Ui
IGNsYXNzPSJvcmcuYXBhY2hlLmNvbW1vbnMuZGJjcC5CYXNpY0RhdGFTb3VyY2UiPg0KCSAgICAg
ICAgPHByb3BlcnR5IG5hbWU9ImRyaXZlckNsYXNzTmFtZSI+Y29tLm15c3FsLmpkYmMuRHJpdmVy
PC9wcm9wZXJ0eT4NCgkgICAgICAgIDxwcm9wZXJ0eSBuYW1lPSJ1cmwiPmpkYmM6bXlzcWw6Ly9s
b2NhbGhvc3Q6MzMwNi9jYng8L3Byb3BlcnR5Pg0KCSAgICAgICAgPHByb3BlcnR5IG5hbWU9InVz
ZXJuYW1lIj5yb290PC9wcm9wZXJ0eT4NCgkgICAgICAgIDxwcm9wZXJ0eSBuYW1lPSJ2YWxpZGF0
aW9uUXVlcnkiPlNFTEVDVCAqIEZST00gbGFuZ3VhZ2U8L3Byb3BlcnR5Pg0KCTwvYmVhbj4NCgkN
CgkNCglUaGUgcHJlZmVycmVkIHdheSBpbiBhIEoyRUUgY29udGFpbmVyIC0gYSBKTkRJIERhdGFT
b3VyY2U6DQoJDQoJPGJlYW4gbmFtZT0iZGF0YVNvdXJjZSIgY2xhc3M9ImNvbS5pbnRlcmZhY2Uy
MS5qbmRpLkpuZGlPYmplY3RGYWN0b3J5QmVhbiI+DQoJICAgICAgICA8cHJvcGVydHkgbmFtZT0i
am5kaU5hbWUiPmpkYmMvY2J4PC9wcm9wZXJ0eT4NCgk8L2JlYW4+DQoJDQoJDQoJREkgSsO8cmdl
biBIw7ZsbGVyDQoJU2VuaW9yIFN5c3RlbSBBcmNoaXRlY3QNCglfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KCQ0KCXdlcmszQVRTIC0gZGl2aXNpb24gc3lzdGVtZW50d2lj
a2x1bmcNCglwYXJ0IG9mIHdlcmszQVQgaW50ZXJuZXRtZWRpZW4gb2VnDQoJDQoJZXVyb3BhcGxh
dHogNA0KCUEgLSA0MDIwIGxpbnoNCgkNCgl0LiAgKzQzICgwKSA3MzIgNzEgNjUgMjkgNTAyDQoJ
Zi4gICs0MyAoMCkgNzMyIDcxIDY1IDI5IDMNCglqdWVyZ2VuLmhvZWxsZXJAd2VyazNhdC5jb20N
Cgl3d3cud2VyazNhdC5jb20NCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KCXdlcmszQVRTIC0gV0lSIEVOVFdJQ0tFTE4gRVJGT0xHDQoJDQoJDQoJDQoJLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCVRoaXMgU0Yu
bmV0IGVtYWlsIGlzIHNwb25zb3JlZCBieTogT2JqZWN0U3RvcmUuDQoJSWYgZmxhdHRlbmluZyBv
dXQgQysrIG9yIEphdmEgY29kZSB0byBtYWtlIHlvdXIgYXBwbGljYXRpb24gZml0IGluIGENCgly
ZWxhdGlvbmFsIGRhdGFiYXNlIGlzIHBhaW5mdWwsIGRvbid0IGRvIGl0ISBDaGVjayBvdXQgT2Jq
ZWN0U3RvcmUuDQoJTm93IHBhcnQgb2YgUHJvZ3Jlc3MgU29mdHdhcmUuIGh0dHA6Ly93d3cub2Jq
ZWN0c3RvcmUubmV0L3NvdXJjZWZvcmdlDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCglTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1haWxpbmcgbGlz
dA0KCVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJaHR0
cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3b3Jr
LWRldmVsb3Blcg0KCQ0KDQo=

[Springframework-developer] DataSource setup in an ApplicationContext

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

On an occasion, some examples for setting up a DataSource in a Spring =
ApplicationContext. All of them can be passed to the dataSource property =
of DataSourceTransactionManager, JdbcTemplate, or custom beans as bean =
reference. Switching between them is thus a matter of configuration - =
just activate the respective bean definition.


A mock DataSource that wraps a single connection (mainly for test =
suites):

<bean name=3D"dataSource" =
class=3D"com.interface21.jdbc.datasource.SingleConnectionDataSource">
	<property name=3D"suppressClose">true</property>
	<property name=3D"driverName">com.mysql.jdbc.Driver</property>
	<property name=3D"url">jdbc:mysql://localhost:3306/cbx</property>
	<property name=3D"user">root</property>
</bean>


A mock DataSource that creates a new connection on every getConnection =
call:

<bean name=3D"dataSource" =
class=3D"com.interface21.jdbc.datasource.DriverManagerDataSource">
	<property name=3D"driverName">com.mysql.jdbc.Driver</property>
	<property name=3D"url">jdbc:mysql://localhost:3306/cbx</property>
	<property name=3D"user">root</property>
</bean>


An example for a pooling Apache Commons DBCP DataSource:

<bean name=3D"dataSource" =
class=3D"org.apache.commons.dbcp.BasicDataSource">
	<property name=3D"driverClassName">com.mysql.jdbc.Driver</property>
	<property name=3D"url">jdbc:mysql://localhost:3306/cbx</property>
	<property name=3D"username">root</property>
	<property name=3D"validationQuery">SELECT * FROM language</property>
</bean>


The preferred way in a J2EE container - a JNDI DataSource:

<bean name=3D"dataSource" =
class=3D"com.interface21.jndi.JndiObjectFactoryBean">
	<property name=3D"jndiName">jdbc/cbx</property>
</bean>


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

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

RE: [Springframework-developer] JAR file separation and classloader issues

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

SGkgUm9kLA0KDQpGaXJzdCBvZiBhbGwsIEkgaG9wZSB5b3UgaGFkIGEgcmVjcmVhdGl2ZSBiYW5r
IGhvbGlkYXkhDQoNClllcCwgSSd2ZSBjaGFuZ2VkIGFsbCBjbGFzcyBhbmQgcmVzb3VyY2UgYnVu
ZGxlIGFjY2VzcyB0byB0aGUgdGhyZWFkIGNvbnRleHQgY2xhc3MgbG9hZGVyLiBUaGlzIHdvcmtz
IG5pY2VseSBlLmcuIHdpdGggdGhlIFNwcmluZyBKQVIgaW4gUmVzaW4ncyBsaWIgYnV0IGFwcGxp
Y2F0aW9uIGNsYXNzZXMgaW4gV0VCLUlORi9saWIgYW5kIGFwcGxpY2F0aW9uIHJlc291cmNlcyBp
biBXRUItSU5GL2NsYXNzZXMuDQoNClJlZ2FyZGluZyBzaW1wbGVyIHBhY2thZ2luZzogV2hhdCB3
b3VsZCB5b3Ugc2ltcGxpZnk/IExldCdzIHJldmlldyB0aGUgcHJvcG9zZWQgSkFSczoNCi0gY29y
ZSAoc3Bhbm5pbmcgY29yZS9iZWFucy9qbmRpL3V0aWwpOiAxMTAgS0INCi0gamRiYyAoc3Bhbm5p
bmcgZGFvL2pkYmMpOiA5MSBLQg0KLSBlamJpbXBsIChzcGFubmluZyBlamIuc3VwcG9ydCk6IDcg
S0INCi0gY29udGV4dCAoc3Bhbm5pbmcgYW9wL2NvbnRleHQvZWpiLmFjY2Vzcy90cmFuc2FjdGlv
bi92YWxpZGF0aW9uKTogMTAzIEtCDQotIHdlYiAoc3Bhbm5pbmcgd2ViKTogMTE3IEtCDQoNCk9m
IGNvdXJzZSwgdGhlIGVqYmltcGwgaXMgdmVyeSB0aW55LiBTaG91bGQgd2UgbWVyZ2UgaXQgd2l0
aCBlLmcuIGNvcmUgb3IgY29udGV4dD8gVGhlIHJlc3Qgc2VlbXMgcHJldHR5IE9LIGluIHRlcm1z
IG9mIHNjb3BlIGFuZCBzaXplLCBJTU8uDQoNCkJUVywgb24gYXV0aGVudGljYXRpb246IEkgZG9u
J3QgaW50ZW5kIHRvIGFkZHJlc3MgdGhpcyBmb3IgMC44LCBkb24ndCB3b3JyeSA7LSkgSSd2ZSBq
dXN0IGhhZCB0byByZXZpZXcgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gb3B0aW9u
cyBmb3IgYSBjb21wYW55IHByb2plY3QsIHRodXMgdGhlIHRob3VnaHRzLg0KDQpSZWdhcmRzLA0K
SnVlcmdlbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSb2QgSm9obnNv
biBbbWFpbHRvOnJvZC5qb2huc29uQGludGVyZmFjZTIxLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE1h
eSAyNywgMjAwMyAxMDozOSBBTQ0KVG86IGrDvHJnZW4gaMO2bGxlciBbd2VyazNBVF07DQpzcHJp
bmdmcmFtZXdvcmstZGV2ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KU3ViamVjdDogUmU6
IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBKQVIgZmlsZSBzZXBhcmF0aW9uIGFuZA0KY2xh
c3Nsb2FkZXIgaXNzdWVzDQoNCg0KPiBBcyBub3RlZCBpbiBidWlsZC54bWwsIHRoaXMgY291bGQg
YmUgbWFkZSBvYnNvbGV0ZSBieSB1c2luZyB0aGUgdGhyZWFkDQpjb250ZXh0IGNsYXNzIGxvYWRl
ciB3aXRoaW4gdGhlIGZyYW1ld29yaywgZm9yIGxvYWRpbmcgY2xhc3NlcyBhbmQgb3RoZXINCnJl
c291cmNlcyBsaWtlIGJ1bmRsZXMuIEkndmUgYWxyZWFkeSBwcm90b3R5cGVkIHRoaXMsIGl0J3Mg
c2ltcGxlIGFuZCBzZWVtcw0KdG8gd29yayBuaWNlbHkuIE5vdGUgdGhhdCBpdCBpcyBhZHZpc2Fi
bGUgdG8ga2VlcCB0aGUgU3ByaW5nIEpBUnMgaW4geW91cg0KYXBwbGljYXRpb24gbGliIGRpcmVj
dG9yeSBhbnl3YXksIHlvdSB3b24ndCBiZSBjb25mcm9udGVkIHdpdGggdGhlc2UNCnByb2JsZW1z
IGluIGFueSBjYXNlIHRoZW4uIFRoZXJlJ3Mgbm8gY2hvaWNlLCBvZiBjb3Vyc2UsIGlmeW91ciBh
cHBsaWNhdGlvbg0Kc2VydmVyIHVzZXMgdGhlIEVKQiBjbGFzc2xvYWRlciBhcyBwYXJlbnQgb2Yg
eW91ciB3ZWIgYXBwIGNsYXNzbG9hZGVyIC0NCnRob3VnaCB0aGlzIHNob3VsZCB3b3JrIGVxdWFs
bHkgd2VsbCB3aXRoIHRoZSB0aHJlYWQgY29udGV4dCBhcHByb2FjaC4NCg0KQXJlIHlvdSBwcm9w
b3NpbmcgY2hhbmdpbmcgdG8gY29udGV4dCBsb2FkZXI/IEkgdGhpbmsgaXQncyBwcm9iYWJseSBh
IGdvb2QNCmlkZWEsIGFzIG90aGVyd2lzZSBJIHN1c3BlY3Qgd2UgbWF5IGVuY291bnRlciBvbmdv
aW5nIHByb2JsZW1zLiBJIGNhbid0DQplbnZpc2FnZSBhbnkgcHJvYmxlbXMgd2l0aCBjb250ZXh0
IGxvYWRpbmcgKGFsdGhvdWdoIEknbSBzdXJlIGFueSBhcHByb2FjaA0Kd2lsbCBmYWlsIGluIHNv
bWUgc2VydmVycyB3aXRob3V0IGNvZGUgY2hhbmdlcyA6LSkNCg0KV2hpbGUgeW91ciBwYWNrYWdp
bmcgc291bmRzIGxvZ2ljYWwsIG1heWJlIHRoaXMgd291bGQgZW5hYmxlIHNpbXBsZXINCnBhY2th
Z2luZy4gQnV0IEkgZ3Vlc3MgdGhlICJza2VsZXRvbiIgYXBwcm9hY2ggY291bGQgc2hvdyB3aGF0
IEphcnMgd2VyZQ0KbmVlZGVkIGZvciBFSkIgYXBwcyBldGMuDQoNClJlZ2FyZHMsDQpSb2QNCg0K
DQo=

[Springframework-developer] Spring bean factory XML format

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

Guys,

I've just been thinking about an important potential issue.

The current XML bean-reference syntax looks like:
<property name="foo" beanRef="true">myFooBean</property>

and, for lists etc (where a bean exposes a "CSV" property)
<property name="foos">a,b,c</property>

While this syntax is concise, I think there are some issues we should
discuss.

a. It's hard to validate this. There's no validatable reference to another
bean element id. It would be great if an XML editor could help us in this
regard.
b. It's inelegant. The use of the CDATA in the property element as a string
value or a reference (depending on the presence of an attribute) is a bit
messy.
c. The CSV format is really a hack, that I used once and then reused. Not
only does the CSV make no sense to an XML editor (analogous to putting CSV
data in an RDBMS), it places the onus on each class to parse the CSV and
look up the necessary beans. This makes classes exposing CSV properties
dependent on the owning BeanFactory, lessening the value of Spring's
transparence. (Admittedly this is concealed in framework classes, so it
doesn't really affect developers.) With the proposed new way, any
application code could benefit from collection & array support.
d. The new way would make it easy to write XSLT that showed relationships
among Spring beans. This could be handy for generating documentation about
Spring apps.

So I've been thinking of changes along the lines of:

<property name="foo">
    <ref name="myFooBean" />
</property>

and

<property name="foos">
    <ref name="a" />
    <ref name="b"/>
    <ref name="c"/>
</property>

In this case the foos bean class would expose a Collection or array
property, and the bean factory would no how to populate that from the
runtime references. No dependence on the fw even for managing collection
properties.

I've already prototyped the idea of a <ref> subelement, and that was pretty
simple to implement.  I'll experiment with collections tonight.

Apart from changing XML files, the flow-on effect would mean that anything
that exposed a CSV property (like the AOP interceptor proxy) would change to
exposing a Collection or array.

What do you think? I'd like thoughts on the following questions:

1. Does everyone agree that this is worth doing?

2. To support a collection including literal values, should we introduce a
new <value> element, meaning that simple properties would become
<property name="foo"><value>canConvert this string</value></property>. More
verbose, but more elegant.

3. Is there a way to help XML enforce the references automatically? E.g.
change bean "name" to "id" and use a <href> instead of a <ref>? I haven't
had a chance to explore this yet, but hopefully someone knows XML better
than I do.

4. If this is worth doing, should we do it in 0.8, even if it delays the
release  (as it would)? On the one hand, we should try to release ASAP. On
the other hand, this change would break all existing applications. Even
though they'd be easy to fix, it might irritate users. So the choice is:
- release now with a likely incompatible change in store
- accept a delay

We'd also have to introduce analogous support for the properties format,
which couldn't benefit from XML capabilities. The properties format would
probably change very little.

Regards,
Rod

[Springframework-developer] mysql key generation

[Ken K. <kk...@kk...>]

Resending this message. I sent it last night and don't know why it 
hasn't shown up on the mailing list.



Isabelle,

I have used your new mysql key generation in petclinic and it works fine.

By the way, I like this new interface much better than the old one using 
the KeyBinder and  JdbcTemplate.InsertRetval. It is much cleaner and 
easier to use.

Ken

Isabelle Muszynski wrote:

> Hi everyone,
>
> I've rewritten mySQL key generation (MySQLMaxValueIncrementer.java). 
> KeyBinder is no longer used. For a sample of how to use key 
> generation, have a look at livetest/JdbcInsertTestSuite.java.
>
> Your main table (the one for which you want key generation) should not 
> auto_increment its key. The sequence table, on the other hand, should 
> be auto_increment. Have a look at createTables in JdbcInsertTestSuite 
> or at the javadoc for MySQLMaxValueIncrementer.java.
>
> Please let me know if there still are problems. One of the tests is 
> for behavior when multithreading, and on my system it succeeds.
>
> Isabelle
>
>  
>

[Springframework-developer] tutorial

[Isabelle M. <isa...@me...>]

Hi everyone,

Zipfile and tarball are on my web site. The only thing not working is the log4j logging, I get no output and cannot figure out why. If anyone knows, please let me know.

Isabelle
-- 
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com

Re: [Springframework-developer] Authentication and authorization

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

I agree, maybe Spring should offer this.

Spring's ancestor, the MVC framework I wrote for FT group, did
authentication and it worked well.

What about adding an authentication interceptor? I think authentication is
arguable orthogonal to the app proper, hence a good candidate for AOP. As
all controllers implement an interface, we can easily put a global
interceptor in front of all of them.

I agree: standard J2EE authentication is not really standard, and just
doesn't cut the mustard for most real apps.

This is not something we should consider for 0.8, though!

Regards,
Rod

----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Sunday, May 25, 2003 10:31 PM
Subject: [Springframework-developer] Authentication and authorization


> Hi everyone,
>
> I just had a look at J2EE 1.4's JACC (Java Authorization Contract for
Containers), and I'm disappointed. Well, it deals with authorization of web
and EJB resources, what else would you expect from that name? But who needs
that, deployment descriptors allow to specify resource authorization in a
good enough way already, e.g. in web.xml.
>
> What I really miss is portable authentication. Every freaking container
has its own API for authenticators, basically taking username and password,
and returning the roles for this user, if any. Of course, there are always
default implementations for XML files and database tables. But you'll have
to get container-specific to use the J2EE login infrastructure in your apps
if you keep the user data in your application database, or some other
application-specific datastore.
>
> Furthermore, a J2EE web login simply authenticates and returns to the
original URL if the user is authorized. On each following URL, the
authorization check happens again, forbidding access if the user isn't in an
appropriate role. Of course, servlets can programmatically access the user
name, and check if the current user is a given role - but that's it. There
are no hooks for loading user-specific settings on login, for example.
>
> Thus, J2EE authentication seems only usable for basic website
administration purposes, like restricting certain namespaces for
administrators only, specifying the administrator usernames and passwords in
a server-specific way. It's completely inappropriate for handling a tightly
integrated application user base, potentially with thousands of customized
users.
>
> Why? The J2EE model doesn't really fit the concept of a login into a rich
web application. Typically, a login page is either the starting point, or
required for some parts of the application. On login, user settings get
loaded and put in the session. Web controllers offen act according to these
user settings, or are forbidden without login. A logout either removes the
user settings from the session, their existence being related to the login
status, or invalidates the session.
>
> All things considered, it would make sense to offer authentication support
within Spring's web MVC. The basic requirements are the ones from the last
paragraph. Of course, it is already possible to implement this via a custom
LoginController, checking a login/logout request and handling the user
settings in the session, and respective checks in business controllers. I
just wonder if we could offer dedicated authentication support to ease the
task.
>
> Regards,
> Juergen
> NHun~ujʉjjjjvv
> 9r>JF yqj~{zzym +-.ʭǟ+-떳b ~즸 (G^쮽h

Re: [Springframework-developer] key generation

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

Isabelle,

An interceptor could help so long as the insert was done behind an
interface, rather than a class. (As we use dynamic proxies.)

The new key could be attached to the AOP invocation by a
KeyGeneratorInterceptor and therefore available to the object doing the
insert. This would work with Oracle (SELECT nextval from DUAL first), but a
different approach would be needed for DBs using autoincrement.

So as our JDBC stuff is all classes, rather than interfaces (the only such
part of the framework) AOP may not help.

Regards,
Rod

> Hi everyone,
>
> I know very little about AOP right now except for the principle, but lying
in bath last night it occurred to me that this whole database-dependent key
generation problem just might be solved very elegantly using an interceptor.
Am I right?
>
> Isabelle
>
> --
> Isabelle Muszynski
> Software Engineer
> Zandweellaan 4
> 2660 Antwerpen
> Belgium
> Tel. 32-(0)3-830 18 54
> Mobile: 32-(0)485 49 50 89
> Email: isa...@me...
> Website: www.meta-logix.com
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] JAR file separation and classloader issues

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

> As noted in build.xml, this could be made obsolete by using the thread
context class loader within the framework, for loading classes and other
resources like bundles. I've already prototyped this, it's simple and seems
to work nicely. Note that it is advisable to keep the Spring JARs in your
application lib directory anyway, you won't be confronted with these
problems in any case then. There's no choice, of course, ifyour application
server uses the EJB classloader as parent of your web app classloader -
though this should work equally well with the thread context approach.

Are you proposing changing to context loader? I think it's probably a good
idea, as otherwise I suspect we may encounter ongoing problems. I can't
envisage any problems with context loading (although I'm sure any approach
will fail in some servers without code changes :-)

While your packaging sounds logical, maybe this would enable simpler
packaging. But I guess the "skeleton" approach could show what Jars were
needed for EJB apps etc.

Regards,
Rod

[Springframework-developer] JAR file separation and classloader issues

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

SGkgZXZlcnlib2R5LA0KIA0KSSdkIGxpa2UgdG8gYWRkcmVzcyBvdXIgSkFSIGZpbGUgc2VwYXJh
dGlvbiBmb3IgdGhlIHJlbGVhc2UuIEN1cnJlbnRseSwgd2UgaGF2ZSB0aGUgc2VwYXJhdGlvbiBp
bnRvICJjb3JlIiBhbmQgInhtbGJlYW4iIEpBUnMsIHRoZSBvbmx5IHJlYXNvbiBiZWluZyBjbGFz
c2xvYWRlciBpc3N1ZXM6IFRoZSB3ZWIgYXBwIHdpbGwgZmFpbCB0byBsb2FkIGNsYXNzZXMgaWYg
aXRzIFhtbEJlYW5GYWN0b3J5IGlzIGluIGEgcGFyZW50IGNsYXNzbG9hZGVyIG9mIHRoZSB3ZWIg
Y2xhc3Nsb2FkZXIsIGxpa2UgaW4gdGhlIEVKQiBjYXNlIHdpdGggc29tZSBjb250YWluZXJzLCBv
ciB3aGVuIHB1dHRpbmcgdGhlIFNwcmluZyBKQVJzIGluIHlvdXIgYXBwbGljYXRpb24gc2VydmVy
J3MgY29tbW9uIGxpYiBkaXJlY3RvcnkuDQogDQpBcyBub3RlZCBpbiBidWlsZC54bWwsIHRoaXMg
Y291bGQgYmUgbWFkZSBvYnNvbGV0ZSBieSB1c2luZyB0aGUgdGhyZWFkIGNvbnRleHQgY2xhc3Mg
bG9hZGVyIHdpdGhpbiB0aGUgZnJhbWV3b3JrLCBmb3IgbG9hZGluZyBjbGFzc2VzIGFuZCBvdGhl
ciByZXNvdXJjZXMgbGlrZSBidW5kbGVzLiBJJ3ZlIGFscmVhZHkgcHJvdG90eXBlZCB0aGlzLCBp
dCdzIHNpbXBsZSBhbmQgc2VlbXMgdG8gd29yayBuaWNlbHkuIE5vdGUgdGhhdCBpdCBpcyBhZHZp
c2FibGUgdG8ga2VlcCB0aGUgU3ByaW5nIEpBUnMgaW4geW91ciBhcHBsaWNhdGlvbiBsaWIgZGly
ZWN0b3J5IGFueXdheSwgeW91IHdvbid0IGJlIGNvbmZyb250ZWQgd2l0aCB0aGVzZSBwcm9ibGVt
cyBpbiBhbnkgY2FzZSB0aGVuLiBUaGVyZSdzIG5vIGNob2ljZSwgb2YgY291cnNlLCBpZnlvdXIg
YXBwbGljYXRpb24gc2VydmVyIHVzZXMgdGhlIEVKQiBjbGFzc2xvYWRlciBhcyBwYXJlbnQgb2Yg
eW91ciB3ZWIgYXBwIGNsYXNzbG9hZGVyIC0gdGhvdWdoIHRoaXMgc2hvdWxkIHdvcmsgZXF1YWxs
eSB3ZWxsIHdpdGggdGhlIHRocmVhZCBjb250ZXh0IGFwcHJvYWNoLg0KIA0KUmVjZW50IGFkZGl0
aW9ucyB0byBTcHJpbmcgSkRCQyBoYXZlIGludHJvZHVjZWQgYSBmdXJ0aGVyIGlzc3VlOiBzcWwt
ZXJyb3ItY29kZXMueG1sIG5lZWRzIHRvIGdldCBwYXJzZWQgd2l0aCBYbWxCZWFuRmFjdG9yeSwg
dGh1cyB0aGUgamRiYyBKQVIgZGVwZW5kcyBvbiB0aGUgeG1sYmVhbiBKQVIuIEFzIGFuIEVKQiBp
bXBsZW1lbnRhdGlvbiBsZXZlcmFnaW5nIFNwcmluZyBKREJDIHdvdWxkIHVzZSB0aGUgWG1sQmVh
bkZhY3Rvcnkgbm93LCB0aGUgd2ViIGFwcCB3b3VsZCBmYWlsIGFnYWluIGlmIHRoZSBFSkIgY2xh
c3Nsb2FkZXIgaXMgaXRzIHBhcmVudC4gQWRkcmVzc2luZyB0aGUgaXNzdWUgdmlhIHNlcGFyYXRp
b24gb2YgWG1sQmVhbkZhY3Rvcnkgc2ltcGx5IGlzbid0IHBvc3NpYmxlIGFueW1vcmUuDQogDQpB
bGwgdGhpbmdzIGNvbnNpZGVyZWQsIEknbGwgYXBwbHkgdGhlIGNoYW5nZSB0b2RheSBpZiB0aGVy
ZSBhcmVuJ3QgYW55IG9iamVjdGlvbnM6IGNvcmUgYW5kIHhtbGJlYW4gbWVyZ2UuIEluIGFkZGl0
aW9uLCBJIHByb3Bvc2UgYSBuZXcgImNvbnRleHQiIEpBUiBmaWxlLCBmb3Igbm9uLXdlYiBhcHBz
IHRoYXQgbGV2ZXJhZ2UgU3ByaW5nJ3MgQXBwbGljYXRpb25Db250ZXh0LiBCVFcsIHJlbW90aW5n
IChIZXNzaWFuL0J1cmxhcC90cmFuc3BhcmVudCBSTUkpIGFuZCBvcm0gKEhpYmVybmF0ZSBzdXBw
b3J0KSBhcmUgc3RpbGwgb25seSBhdmFpbGFibGUgaW4gImZ1bGwiLCB3aGljaCBzaG91bGRuJ3Qg
YmUgYW4gaXNzdWUuIFdob2V2ZXIgZGlzdHJpYnV0ZXMgSGliZXJuYXRlIHdpdGggYW4gYXBwIHNo
b3VsZG4ndCBtaW5kIGEgNDUwIEtCIHNwcmluZy1mdWxsLmphciA7LSkNCiANClNvIHdlJ2xsIGRp
c3RyaWJ1dGUgdGhlIGZvbGxvd2luZyBKQVIgZmlsZXMgdGhlbjoNCi0gZnVsbCAoc3Bhbm5pbmcg
YWxsIGNsYXNzZXMpDQotIGNvcmUgKHNwYW5uaW5nIGNvcmUvYmVhbnMvam5kaS91dGlsKQ0KLSBq
ZGJjIChzcGFubmluZyBkYW8vamRiYykNCi0gZWpiaW1wbCAoc3Bhbm5pbmcgZWpiLnN1cHBvcnQp
DQotIGNvbnRleHQgKHNwYW5uaW5nIGFvcC9jb250ZXh0L2VqYi5hY2Nlc3MvdHJhbnNhY3Rpb24v
dmFsaWRhdGlvbikNCi0gd2ViIChzcGFubmluZyB3ZWIpDQotIChhbmQgYSBzcmMgWklQIGNvbnRh
aW5pbmcgYWxsIHNvdXJjZXMpDQogDQpSZWdhcmRzLA0KSnVlcmdlbg0K

Re: [Springframework-developer] testCustomDateEditorWithAllowEmpty causes Error

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

I think I figured it out.  I must have installed an U.S. English only JRE at 
some point, and that is the version that was picked up when Ant was run.  If I 
pointed to the full path of the J2SDK then it worked.  I have since installed 
the JRE with all languages included and everything runs OK.

--Thomas

> Now I'm confused - I just booted into Linux to try it there and it works
> fine. 
> The other run was under Windows XP.  I will try to run that one again and see
> if
> I still get the error.
> 
> --Thomas
> 
> 
> > Juergen,
> > 
> > One of the new testcases throws an exception on my machine - something to
> do
> > 
> > with different locale maybe.
> > 
> > [junit] Running com.interface21.web.servlet.mvc.CommandControllerTestSuite
> > [junit] Tests run: 12, Failures: 0, Errors: 2, Time elapsed: 0.661 sec
> > 
> > Testcase: testCustomDateEditorWithAllowEmpty took 0.05 sec
> > 	Caused an ERROR
> > Unparseable date: "1.5.2003"
> > java.text.ParseException: Unparseable date: "1.5.2003"
> > 	at java.text.DateFormat.parse(Unknown Source)
> > 	at 
> >
> 
com.interface21.web.servlet.mvc.CommandControllerTestSuite.testCustomDateEditor
> > WithAllowEmpty(CommandControllerTestSuite.java:183)
> > 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> > 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> > 
> > Testcase: testCustomDateEditorWithAllowEmptyTestcase: 
> > testCustomDateEditorWithoutAllowEmpty took 0 sec
> > 	Caused an ERROR
> > Unparseable date: "1.5.2003"
> > java.text.ParseException: Unparseable date: "1.5.2003"
> > 	at java.text.DateFormat.parse(Unknown Source)
> > 	at 
> >
> 
com.interface21.web.servlet.mvc.CommandControllerTestSuite.testCustomDateEditor
> > WithoutAllowEmpty(CommandControllerTestSuite.java:211)
> > 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> > 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ObjectStore.
> > If flattening out C++ or Java code to make your application fit in a
> > relational database is painful, don't do it! Check out ObjectStore.
> > Now part of Progress Software. http://www.objectstore.net/sourceforge
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] testCustomDateEditorWithAllowEmpty causes Error

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

Now I'm confused - I just booted into Linux to try it there and it works fine. 
The other run was under Windows XP.  I will try to run that one again and see if
I still get the error.

--Thomas


> Juergen,
> 
> One of the new testcases throws an exception on my machine - something to do
> 
> with different locale maybe.
> 
> [junit] Running com.interface21.web.servlet.mvc.CommandControllerTestSuite
> [junit] Tests run: 12, Failures: 0, Errors: 2, Time elapsed: 0.661 sec
> 
> Testcase: testCustomDateEditorWithAllowEmpty took 0.05 sec
> 	Caused an ERROR
> Unparseable date: "1.5.2003"
> java.text.ParseException: Unparseable date: "1.5.2003"
> 	at java.text.DateFormat.parse(Unknown Source)
> 	at 
> com.interface21.web.servlet.mvc.CommandControllerTestSuite.testCustomDateEditor
> WithAllowEmpty(CommandControllerTestSuite.java:183)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 
> Testcase: testCustomDateEditorWithAllowEmptyTestcase: 
> testCustomDateEditorWithoutAllowEmpty took 0 sec
> 	Caused an ERROR
> Unparseable date: "1.5.2003"
> java.text.ParseException: Unparseable date: "1.5.2003"
> 	at java.text.DateFormat.parse(Unknown Source)
> 	at 
> com.interface21.web.servlet.mvc.CommandControllerTestSuite.testCustomDateEditor
> WithoutAllowEmpty(CommandControllerTestSuite.java:211)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

RE : [Springframework-developer] Authentication

[JP P. <jp....@ti...>]

Hi Brett,

I don't have for now the need of instance authorization, but it is well
understandable. AOP would be a nice choice as the authorizations could
be done in the beans definition files without puzzling the code. It is
really an "aspect".

Jean-Pierre


> -----Message d'origine-----
> De=A0: spr...@li...
> [mailto:spr...@li...] De la
part
> de Brett Bell
> Envoy=E9=A0: lundi 26 mai 2003 11:44
> =C0=A0: spr...@li...
> Objet=A0: Re: [Springframework-developer] Authentication
>=20
> Hi
>=20
> Unfortunately, JAAS only supports class based Authorisation(i.e. a
user
> can operate on a particular type) where a number of business cases
require
> instance based security (i.e. can this user operate on this specific
> instance).  I have written a framework recently to support instance
based
> authorisation at work so I can write a new one for Spring if that's
ok,
> possibly sprucing it up to use AOP.
>=20
> Please let me know what you think.
>=20
> Cheers
>=20
>=20
> Brett
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] testCustomDateEditorWithAllowEmpty causes Error

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

Juergen,

One of the new testcases throws an exception on my machine - something to do 
with different locale maybe.

[junit] Running com.interface21.web.servlet.mvc.CommandControllerTestSuite
[junit] Tests run: 12, Failures: 0, Errors: 2, Time elapsed: 0.661 sec

Testcase: testCustomDateEditorWithAllowEmpty took 0.05 sec
	Caused an ERROR
Unparseable date: "1.5.2003"
java.text.ParseException: Unparseable date: "1.5.2003"
	at java.text.DateFormat.parse(Unknown Source)
	at 
com.interface21.web.servlet.mvc.CommandControllerTestSuite.testCustomDateEditor
WithAllowEmpty(CommandControllerTestSuite.java:183)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

Testcase: testCustomDateEditorWithAllowEmptyTestcase: 
testCustomDateEditorWithoutAllowEmpty took 0 sec
	Caused an ERROR
Unparseable date: "1.5.2003"
java.text.ParseException: Unparseable date: "1.5.2003"
	at java.text.DateFormat.parse(Unknown Source)
	at 
com.interface21.web.servlet.mvc.CommandControllerTestSuite.testCustomDateEditor
WithoutAllowEmpty(CommandControllerTestSuite.java:211)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

Re: [Springframework-developer] paged lists

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

SmVhbi1QaWVycmUsDQogDQpJJ3ZlIGp1c3QgY29tbWl0dGVkIG15IHJld29ya2VkIHZlcnNpb24u
DQogDQpUaGVyZSdzIG5vdyBhIFNvcnREZWZpbml0aW9uIGludGVyZmFjZSBpbiBjb20uaW50ZXJm
YWNlMjEuYmVhbnMsIHdpdGggYSBNdXRhYmxlU29ydERlZmluaXRpb24gaW1wbGVtZW50YXRpb24u
IFRoZSBzb3J0IG1ldGhvZHMgaGF2ZSBtb3ZlZCBmcm9tIEJlYW5VdGlscyB0byBQcm9wZXJ0eUNv
bXBhcmF0b3IuDQogDQpQYWdlZExpc3RIb2xkZXIgaXMgcXVpdGUgc2ltaWxhciB0byBiZWZvcmUs
IHRhcmdldHRlZCBhbiBpbW11dGFibGUgbGlzdHMsIGJ1dCB3aXRoIGJpbmRpbmctZnJpZW5kbHkg
c29ydGluZyBzdXBwb3J0IHZpYSBTb3J0RGVmaW5pdGlvbi4gSSd2ZSB0dXJuZWQgUGFnZUxpc3RB
dXRvSG9sZGVyIGludG8gUmVmcmVzaGFibGVQYWdlZExpc3RIb2xkZXIsIGFkZGluZyByZWZyZXNo
aW5nIGZyb20gYSBzb3VyY2UgcHJvdmlkZXIgb24gY2hhbmdlZCBMb2NhbGUgb3IgZmlsdGVyLiBG
aWx0ZXIgaXMgYSBnZW5lcmljIE9iamVjdCBwcm9wZXJ0eSBub3csIGFsbG93aW5nIGZvciBhbnkg
ZmlsdGVyIHNldHRpbmdzIGJlaW5nIHBhc3NlZCB0aHJvdWdoIHRvIHRoZSByZXNwZWN0aXZlIHNv
dXJjZSBwcm92aWRlci4NCiANCkknbGwgc2VuZCB0aGUgYWRhcHRlZCB2ZXJzaW9uIG9mIHlvdXIg
ZXhhbXBsZSBhcHAgdG8gdGhlIGxpc3QgdG9tb3Jyb3cuIFRoZXJlIGhhdmVuJ3QgYmVlbiBtYW55
IGNoYW5nZXMgdG8gdGhlIGNvbnRyb2xsZXIgYW5kIHZpZXcsIGJ1dCB3aHkgZmlndXJlIG91dCB5
b3Vyc2VsZj8gOi0pDQogDQpSZWdhcmRzLA0KSnVlcmdlbg0KIA0KIA0KDQoJLS0tLS1VcnNwcsO8
bmdsaWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IGpwLnBhd2xha0B0aXNjYWxpLmZyIFttYWls
dG86anAucGF3bGFrQHRpc2NhbGkuZnJdIA0KCUdlc2VuZGV0OiBTbyAyNS4wNS4yMDAzIDE1OjA4
IA0KCUFuOiBqw7xyZ2VuIGjDtmxsZXIgW3dlcmszQVRdIA0KCUNjOiBzcHJpbmdmcmFtZXdvcmst
ZGV2ZWxvcGVyIA0KCUJldHJlZmY6IFJlOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gcGFn
ZWQgbGlzdHMNCgkNCgkNCg0KCUhpIErDvHJnZW4sDQoJDQoJWW91ciBzdWdnZXN0cyBhcmUgdmVy
eSB3ZWxjb21lLiBBcyB5b3UgaGF2ZSBhICBiZXR0ZXIga25vd2xlZGdlIG9iIHRoZSB3aG9sZSBT
cHJpbmcgZnJhbWV3b3JrLCB5b3Ugc2VlbiBxdWlja2x5IGJldHRlciBpbnRlcmFjdGlvbiB1c2Uu
IEkgYW0gbm90IGF0IGhvbWUsIEl0IHNlZW1zIHlvdSBhcmUgYWxyZWFkeSBtYWtpbmcgdGhlIGNo
YW5nZS4gSWYgeW91IGV4cGV4dCBhbnl0aGluZyBmcm9tIG1lLCB0YWxrIG1lIGp1c3QgYWJvdXQu
IA0KCQ0KCVJlZ2FyZHMsDQoJSmVhbi1QaWVycmUNCgkNCgktLS0tLS0tLS0tIEluaXRpYWwgSGVh
ZGVyIC0tLS0tLS0tLS0tDQoJDQoJRnJvbSAgICAgIDogc3ByaW5nZnJhbWV3b3JrLWRldmVsb3Bl
ci1hZG1pbkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCglUbyAgICAgICAgICA6ICJKUCBQYXdsYWsi
IDxqcC5wYXdsYWtAdGlzY2FsaS5mcj4sIlNwcmluZyBEZXZlbG9wZXJzIiA8c3ByaW5nZnJhbWV3
b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQ+DQoJQ2MgICAgICAgICAgOg0KCURh
dGUgICAgICA6IFN1biwgMjUgTWF5IDIwMDMgMTQ6NDg6MzQgKzAyMDANCglTdWJqZWN0IDogUmU6
IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBwYWdlZCBsaXN0cw0KCQ0KCUhpIEplYW4tUGll
cnJlLA0KCQ0KCUJUVywgdGhlIHRlc3RzIGhhdmUgYWxsIHdvcmtlZCBmb3IgbWUgb24gRnJpZGF5
IC0gSSdsbCByZWNoZWNrIHRvbW9ycm93Lg0KCQ0KCVJlZ2FyZGluZyBQYWdlZExpc3RBdXRvSG9s
ZGVyOiBJIGFwcHJlY2lhdGUgaXRzIGFkZGVkIGZ1bmN0aW9uYWxpdHkuIElmIEkgdW5kZXJzdGFu
ZCBjb3JyZWN0bHksIGl0J3MgdGFyZ2V0dGVkIGF0IGVhc3kgdXNhZ2UgaW4gYSB3ZWIgY29udHJv
bGxlci4gTXkgaW5pdGlhbCBQYWdlZExpc3RIb2xkZXIgd2FzIGp1c3QgYSBmaXJzdCB0YWtlLCBk
cmF3biBmcm9tIGFuIGFwcGxpY2F0aW9uIHByb2plY3QuIEknbSB2ZXJ5IG11Y2ggZm9yIHdvcmtp
bmcgYWxsIG9mIHRoaXMgaW50byBhIHJlZmluZWQgdmVyc2lvbiwgZXZlbiBiZWZvcmUgMC44LiBJ
J2xsIHByb2JhYmx5IHVzZSBpdCBpbiBvdXIgYXBwbGljYXRpb24gcHJvamVjdCB0b28uDQoJDQoJ
LS0tDQoJDQoJSSd2ZSBnb3Qgc29tZSBjb25jcmV0ZSBpc3N1ZXM6DQoJDQoJLSBHZW5lcmFsbHks
IHdlIHNob3VsZCB0cnkgdG8gdXNlIGRhdGEgYmluZGluZyB3aGVyZXZlciBwb3NzaWJsZSwgdG8g
a2VlcCB0aGUgbW9kZWwgYW5kIHRoZSBhY3Rpb25zIGFzIE9PIHJlc3AuIGJlYW4tc3R5bGUgYXMg
cG9zc2libGUuIEknbSBub3QgYSBncmVhdCBmYW4gb2YgbWFudWFsIHBhcmFtZXRlciBwYXJzaW5n
IChoYXZlIHVzZWQgaXQgZmFyIHRvbyBtYW55IHRpbWVzIG15c2VsZiksIGJlIGl0IGZyb20gdGhl
IFNlcnZsZXRSZXF1ZXN0IG9yIGZyb20gYSBTdHJpbmctYmFzZWQgcGFyYW1ldGVyIG1hcC4gU3By
aW5nJ3MgU2VydmxldFJlcXVlc3REYXRhQmluZGVyIGFsbG93cyBmb3IgdmVyeSBwb3dlcmZ1bCBi
aW5kaW5nIG9mIHJlcXVlc3QgcGFyYW1ldGVycyB0byBiZWFuIGluc3RhbmNlcywgZXZlbiBvbmUg
dG8gcmVxdWVzdCB0byBtdWx0aXBsZSBiZWFucy4gTWFudWFsIFN0cmluZyBwYXJhbWV0ZXIgZXZh
bHVhdGlvbiBkb2Vzbid0IGJlbG9uZyBpbiBhIHByb3BlciBtb2RlbCBvYmplY3QsIElNTy4NCgkN
CgktIGdldE1heERpc3BsYXlQYWdlcywgZ2V0Rmlyc3REaXNwbGF5UGFnZSwgZ2V0TGFzdERpc3Bs
YXlQYWdlIHNob3VsZCBwcm9iYWJseSBiZSBjYWxsZWQgZ2V0TWF4TGlua2VkUGFnZXMsIGdldEZp
cnN0TGlua2VkUGFnZSwgZ2V0TGFzdExpbmtlZFBhZ2UgLSBhcyB0aGV5IGFyZW4ndCByZWFsbHkg
ZGlzcGxheWVkIHRoZW1zZWx2ZXMgYnV0IHJhdGhlciBqdXN0IGxpbmtlZCBmcm9tIHRoZSBjdXJy
ZW50bHkgZGlzcGxheWVkIHBhZ2UuDQoJDQoJLSBJJ2QgbGlrZSB0byB0dXJuIHlvdXIgIlNvcnQi
IGlubmVyIGNsYXNzIGludG8gYSBnZW5lcmljIGNvbS5pbnRlcmZhY2UyMS5iZWFucy5Tb3J0RGVm
aW5pdGlvbiBpbnRlcmZhY2UsIGFuZCBvZmZlciBhbiBhY2NvbXBhbnlpbmcgQmVhblV0aWxzLnNv
cnRCeVByb3BlcnR5KExpc3QsU29ydERlZmluaXRpb24pIG1ldGhvZC4gWW91ciBjdXJyZW50IFNv
cnQgaW1wbGVtZW50YXRpb24gY291bGQgc2VydmUgYXMgRGVmYXVsdFNvcnREZWZpbml0aW9uIGlt
cGxlbWVudGF0aW9uLg0KCQ0KCS0gQXMgeW91J3ZlIGFkZHJlc3NlZCB3aXRoIGV4dGVuZGVkSW5m
bywgcmVsb2FkaW5nIGNhbiBkZXBlbmQgb24gdmFyaW91cyBzcGVjaWZpYyBwYXJhbWV0ZXJzLiBC
dXQgZmlsdGVyaW5nIGNvdWxkIGJlIGJhc2VkIG5vdCBvbmx5IG9uIHBlci1maWVsZCBtYXRjaGlu
ZyB2YWx1ZXMgYnV0IG9uIHJlZ3VsYXIgZXhwcmVzc2lvbnMgZXRjLiBBIGdlbmVyaWMgImZpbHRl
ciIgcHJvcGVydHkgb2YgdHlwZSBPYmplY3Qgd2lsbCBhbGxvdyB0aGUgY29udHJvbGxlciB0byBz
dG9yZSBhIHN0YXRlIG9iamVjdCByZXByZXNlbnRpbmcgdGhlIGN1cnJlbnQgZmlsdGVyIHNldHRp
bmdzLCBjb21iaW5pbmcgeW91ciBmaWx0ZXJNYXAgYW5kIGV4dGVuZGVkSW5mbyBpbiBvbmUgZ2Vu
ZXJpYyBPYmplY3QuIE5vdGUgdGhhdCBQYWdlZExpc3RIb2xkZXIgZG9lcyBub3QgYW5kIHNob3Vs
ZCBub3QgbmVlZCB0byBrbm93IGFib3V0IHRoZSBzZW1hbnRpY3Mgb2YgImZpbHRlciIuDQoJDQoJ
LSBTb21lIHByb3BlcnRpZXMgcmVwcmVzZW50IExpc3QgbWV0YSBkYXRhOiAic29ydCIgb2YgdHlw
ZSBTb3J0RGVmaW5pdGlvbiwgImZpbHRlciIgb2YgdHlwZSBPYmplY3QsICJsb2NhbGUiIG9mIHR5
cGUgTG9jYWxlLiBUaGVzZSBjYW4gZWFzaWx5IGJlIGluY2x1ZGVkIGluIFBhZ2VkTGlzdEhvbGRl
ciwganVzdCBsaWtlIHRoZSBsaW5rZWQgcGFnZXMgc3VwcG9ydCB0b28gKGluIHRoZSBlbmQsIGxl
dCdzIG1lcmdlIFBhZ2VkTGlzdEhvbGRlciBhbmQgUGFnZWRMaXN0QXV0b0hvbGRlciAtIHdlIHBy
b2JhYmx5IGRvbid0IG5lZWQgYm90aCkuIFBhZ2VkTGlzdFNvdXJjZVByb3ZpZGVyIHdvdWxkIGhh
dmUgYSBnZW5lcmljIGxvYWRMaXN0KE9iamVjdCBGaWx0ZXIsIExvY2FsZSBsb2NhbGUpIHRoZW4u
DQoJDQoJLSBQYWdlZExpc3RIb2xkZXIgcHJvcGVydGllcyBsaWtlIHBhZ2VTaXplLCBwYWdlTnIs
IG1heExpbmtlZFBhZ2VzIHNob3VsZCBiZSBwb3B1bGF0ZWQgdmlhIGJpbmRpbmcgKHRoYXQncyBo
b3cgbXkgaW5pdGlhbCB2ZXJzaW9uIHdhcyBtZWFudCB0byBiZSB1c2VkKS4gTGV0J3MgdHJlYXQg
UGFnZWRMaXN0SG9sZGVyIGFzIGEgZm9ybSBiZWFuLCB3aXRoIHJlcXVlc3QgcGFyYW1ldGVycyBn
ZXR0aW5nIGJvdW5kIHRvIGl0IG9uIGV2ZXJ5IHN1Ym1pdCAtIG5vIFN0cmluZyBwYXJhbWV0ZXIg
cGFyc2luZywgbm8gSW50ZWdlci5wYXJzZUludC4gVGhlIHNhbWUgYXBwbGllcyB0byAic29ydCIg
YW5kICJmaWx0ZXIiOiBBIGNvbnRyb2xsZXIgY2FuIHNldCBzcGVjaWZpYyBpbnN0YW5jZXMgdG8g
dGhlIFBhZ2VkTGlzdEhvbGRlciBpbnN0YW5jZSBvbiBzZXR1cC4gVGhlc2UgaW5zdGFuY2VzIGNh
biBiZSBwb3B1bGF0ZWQgdmlhIHRoZSBzYW1lIGJpbmRpbmcgc3RlcCwgdXNpbmcgbmVzdGVkIHBh
dGhzIGxpa2UgInNvcnQuYXNjZW5kaW5nIiBldGMuDQoJDQoJLSBQYWdlZExpc3RIb2xkZXIncyBy
ZWZyZXNoIG1ldGhvZCBzaG91bGQgZG8gZXF1YWxzIGNoZWNrcyBvbiAic29ydCIgYW5kICJmaWx0
ZXIiICh1c2luZyBzdG9yZWQgY29waWVzIGZyb20gdGhlIGxhc3QgcmVmcmVzaCksIGFuZCBwZXJm
b3JtIHJlc29ydGluZyByZXNwLiByZWxvYWRpbmcgaWYgbmVjZXNzYXJ5IChzZXR0aW5nIGN1cnJl
bnQgdmVyc2lvbnMgYXMgc3RvcmVkIGNvcGllcykuIFRodXMsIGEgY29udHJvbGxlciBzaG91bGQg
aW52b2tlIHJlZnJlc2ggYWZ0ZXIgZWFjaCBiZWFuIHBvcHVsYXRpb24sIGkuZS4gb24gZWFjaCBy
ZXF1ZXN0LiBBIHJlYWwgcmVmcmVzaCBjYW4gYmUgZW5mb3JjZWQgYnkgYSByZXNwZWN0aXZlIHJl
cXVlc3QgcGFyYW1ldGVyLCBidXQgdGhpcyBzaG91bGQgYmUgY2hlY2tlZCBieSB0aGUgc3BlY2lm
aWMgd2ViIGNvbnRyb2xsZXIsIHRyaWdnZXJpbmcgYSByZWZyZXNoKGJvb2xlYW4gZW5mb3JjZSkg
Y2FsbCB3aXRoIHRydWUgdGhlbi4NCgkNCgktIEFsbCB0aGluZ3MgY29uc2lkZXJlZCwgdGhlIHVu
aWZpZWQgUGFnZWRMaXN0SG9sZGVyIHdpbGwgbm90IG5lZWQgdG8ga25vdyBhbnl0aGluZyBhYm91
dCByZXF1ZXN0IHBhcmFtZXRlcnMuIFBhZ2VkTGlzdEF1dG9Ib2xkZXIncyB4eHhQYXJhbSBwcm9w
ZXJ0aWVzIGFuZCBpdHMgcXVpdGUgbGVuZ3RoeSBleGVjdXRlIG1ldGhvZCBhcmVuJ3QgbmVjZXNz
YXJ5IHRoZW4sIG1vc3Qgc3R1ZmYgY2FuIHdvcmsgdmlhIGRhdGEgYmluZGluZyBhbmQgcmVmcmVz
aC4gSWYgb25lIHdhbnRzIHRvIHVzZSBkaWZmZXJlbnQgcmVxdWVzdCBwYXJhbWV0ZXJzLCBvbmUg
Y2FuIGFsd2F5cyBwZXJmb3JtIG1hbnVhbCBwb3N0LWJpbmRpbmcsIGJ1dCB0aGUgYmVhbiBwcm9w
ZXJ0eSBuYW1lcyBzaG91bGQgYmUgcHJldHR5IHN0cmFpZ2h0Zm9yd2FyZCBhcyBwYXJhbWV0ZXIg
bmFtZXMgYW55d2F5LiBUaGUgYmluZGluZyBwYXRocyBtYXRjaCB0aGUgSlNUTCBFTCBleHByZXNz
aW9ucyBuaWNlbHksIGxpa2UgInNvcnQuYXNjZW5kaW5nIi4NCgkNCgktLS0NCgkNCglBIGNvbnRy
b2xsZXIgaW1wbGVtZW50YXRpb24gaXMgYXMgc2ltcGxlIGFzIGJlZm9yZS4gSXQganVzdCBuZWVk
cyB0byB0cmlnZ2VyIHRoZSBiaW5kaW5nIGFuZCBjYWxsIHRoZSByZWZyZXNoIG1ldGhvZCBhZnRl
cndhcmRzLCBpbnN0ZWFkIG9mIHRoZSBjdXJyZW50IGV4ZWN1dGUgY2FsbC4gVGhlIHJlc3BlY3Rp
dmUgY29kZSBpbiB5b3VyIFBhZ2VkTGlzdENvbnRyb2xsZXIgZXhhbXBsZSB3b3VsZCBsb29rIGFi
b3V0IGFzIGZvbGxvd3M6DQoJDQoJcHVibGljIE1vZGVsQW5kVmlldyBzaG93TWFpbihIdHRwU2Vy
dmxldFJlcXVlc3QgcmVxdWVzdCwgSHR0cFNlcnZsZXRSZXNwb25zZSByZXNwb25zZSkgew0KCSAg
UGFnZWRMaXN0QXV0b0hvbGRlciBsaXN0SG9sZGVyID0NCgkgICAgKFBhZ2VkTGlzdEF1dG9Ib2xk
ZXIpcmVxdWVzdC5nZXRTZXNzaW9uKHRydWUpLmdldEF0dHJpYnV0ZShDT1VOVFJJRVNfQVRUUik7
DQoJICBpZiAobnVsbCA9PSBsaXN0SG9sZGVyKSB7DQoJICAgIGxpc3RIb2xkZXIgPSAoUGFnZWRM
aXN0QXV0b0hvbGRlcil0aGlzLmdldEFwcGxpY2F0aW9uQ29udGV4dCgpLmdldEJlYW4oImF1dG9M
aXN0SG9sZGVyIik7DQoJICAgIGxpc3RIb2xkZXIuc2V0U291cmNlUHJvdmlkZXIobmV3IENvdW50
cmllc1Byb3ZpZGVyKCkpOw0KCSAgICBsaXN0SG9sZGVyLnNldEZpbHRlcihuZXcgQ291bnRyaWVz
RmlsdGVyKCkpOw0KCSAgICBsaXN0SG9sZGVyLnNldFNvcnQobmV3IERlZmF1bHRTb3J0RGVmaW5p
dGlvbigpKTsNCgkgICAgcmVxdWVzdC5nZXRTZXNzaW9uKHRydWUpLnNldEF0dHJpYnV0ZShDT1VO
VFJJRVNfQVRUUiwgbGlzdEhvbGRlcik7IA0KCSAgfQ0KCSAgQmluZEV4Y2VwdGlvbiBleCA9IEJp
bmRVdGlscy5iaW5kKHJlcXVlc3QsIGxpc3RIb2xkZXIsICJjb3VudHJpZXMiKTsNCgkgIGJvb2xl
YW4gZm9yY2VSZWZyZXNoID0gcmVxdWVzdC5nZXRQYXJhbWV0ZXIoImZvcmNlUmVmcmVzaCkgIT0g
bnVsbDsNCgkgIGxpc3RIb2xkZXIucmVmcmVzaChmb3JjZVJlZnJlc2gpOw0KCSAgcmV0dXJuIG5l
dyBNb2RlbEFuZFZpZXcoIm1haW5WaWV3IiwgZXguZ2V0TW9kZWwoKSk7DQoJfQ0KCQ0KCXB1Ymxp
YyBjbGFzcyBDb3VudHJpZXNGaWx0ZXIgew0KCSAgcHJpdmF0ZSBTdHJpbmcgbmFtZTsNCgkgIHBy
aXZhdGUgU3RyaW5nIGNvZGU7DQoJICBwdWJsaWMgU3RyaW5nIGdldE5hbWUoKSB7DQoJICAgIHJl
dHVybiBuYW1lOw0KCSAgfQ0KCSAgcHVibGljIHZvaXMgc2V0TmFtZShTdHJpbmcgbmFtZSkgew0K
CSAgICB0aGlzLm5hbWUgPSBuYW1lOw0KCSAgfQ0KCSAgcHVibGljIFN0cmluZyBnZXRDb2RlKCkg
ew0KCSAgICByZXR1cm4gY29kZTsNCgkgIH0NCgkgIHB1YmxpYyB2b2lzIHNldENvZGUoU3RyaW5n
IGNvZGUpIHsNCgkgICAgdGhpcy5jb2RlID0gY29kZTsNCgkgIH0NCgl9DQoJDQoJRmlsdGVyaW5n
IGRvZXNuJ3Qgd29yayB2aWEgcGFyYW1ldGVyIG5hbWVzIHRoYXQgc2VydmUgYXMgZmlsdGVyIG5h
bWVzIGFueW1vcmUsIGJ1dCB3aXRoIGEgbmVzdGVkICJmaWx0ZXIiIG9iamVjdCBvZiB0eXBlIENv
dW50cmllc0ZpbHRlci4gU28geW91ciBtYWluLmpzcCB3b3VsZCBuZWVkIHRvIHVzZSAiY291bnRy
aWVzLmZpbHRlci5jb2RlIiBFTCBmb3IgbWF0Y2hpbmcsIHNlbmRpbmcgImZpbHRlci5jb2RlIiBh
cyByZXF1ZXN0IHBhcmFtZXRlciBuYW1lIGZvciBjaGFuZ2luZy4gVGhlIHNhbWUgYXBwbGllcyB0
byBzb3J0aW5nLCB1c2luZyB0aGUgbmVzdGVkICJzb3J0IiBvYmplY3Q6IGUuZy4gImNvdW50cmll
cy5zb3J0LmFzY2VuZGluZyIgRUwgZm9yIGV2YWx1YXRpb24gKGp1c3QgbGlrZSBpbiB5b3VyIGN1
cnJlbnQgdmVyc2lvbiksICJzb3J0LmFzY2VuZGluZyIgYXMgcmVxdWVzdCBwYXJhbWV0ZXIgbmFt
ZS4NCgkNCgktLS0NCgkNCglXaGF0IGRvIHlvdSB0aGluaz8gSSdtIGtlZW4gb24gYXBwbHlpbmcg
dGhlc2UgY2hhbmdlcyBwcm9tcHRseSwgaWYgeW91IGRvbid0IG1pbmQsIGlmIHBvc3NpYmxlIGFs
cmVhZHkgdG9tb3Jyb3cuIEJUVywgSSdtIHdyaXRpbmcgdGhpcyBvbiBhIG5vbi1kZXZlbG9wbWVu
dCBQQyBhdCBob21lLCBzbyBJIGhhdmVuJ3QgYWN0dWFsbHkgcHJvdG90eXBlZCB0aGUgZGVzaWdu
LCBidXQgSSBleHBlY3QgaXQgdG8gd29yayBuaWNlbHkuIFdlIHNob3VsZCBlbmQgdXAgd2l0aCBz
aWduaWZpY2FudGx5IGxlc3MgYW5kIG1vcmUgbWFpbnRhaW5hYmxlIGNvZGUsIEkgaG9wZS4NCgkN
CglSZWdhcmRzLA0KCUp1ZXJnZW4NCgkNCgkNCgkNCgkgICAgICAgIC0tLS0tVXJzcHLDvG5nbGlj
aGUgTmFjaHJpY2h0LS0tLS0NCgkgICAgICAgIFZvbjogSlAgUGF3bGFrIFttYWlsdG86anAucGF3
bGFrQHRpc2NhbGkuZnJdDQoJICAgICAgICBHZXNlbmRldDogRnIgMjMuMDUuMjAwMyAyMjoyMA0K
CSAgICAgICAgQW46IFNwcmluZyBEZXZlbG9wZXJzDQoJICAgICAgICBDYzoNCgkgICAgICAgIEJl
dHJlZmY6IFtTcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyXSBwYWdlZCBsaXN0cw0KCSAgICAgICAN
CgkgICAgICAgDQoJDQoJDQoJICAgICAgICBIaSwNCgkgICAgICAgDQoJICAgICAgICBFeGN1c2Ug
bWUgZnJvbSBkaXN0dXJiaW5nIGZyb20gZnVuZGFtZW50YWwgaXNzdWVzIGxpa2UgdGhlIEtleUJp
bmRlcg0KCSAgICAgICAgcG9zdGVkIGJ5IElzYWJlbGxlIGFuZCB0aGUgYnJva2VuIHRlc3RzIEkn
dmUganVzdCBwb3N0ZWQuDQoJICAgICAgIA0KCSAgICAgICAgQXMgSSB0YWxrZWQgYWJvdXQsIEkg
aGF2ZSBhZGRlZCB0aHJlZSBmaWxlczoNCgkgICAgICAgIEluIHNyYzoNCgkgICAgICAgICAgIC0g
Y29tLmludGVyZmFjZTIxLnV0aWwuUGFnZWRMaXN0QXV0b0hvbGRlci5qYXZhIChDbGFzcyBkZXJp
dmVkIGZyb20NCgkgICAgICAgIFBhZ2VkTGlzdEhvbGRlcikNCgkgICAgICAgICAgIC0gY29tLmlu
dGVyZmFjZTIxLnV0aWwuUGFnZWRMaXN0U291cmNlUHJvdmlkZXIuamF2YSAoSW50ZXJmYWNlKQ0K
CSAgICAgICAgaW4gdGVzdDoNCgkgICAgICAgICAgIC0gY29tLmludGVyZmFjZTIxLnV0aWwuUGFn
ZWRMaXN0QXV0b0hvbGRlclRlc3RzLmphdmEgKENsYXNzKQ0KCSAgICAgICANCgkgICAgICAgIFRo
aXMgYWxsIGZvciBlYXN5IHVzZSBvZiBhIG1vcmUgcG93ZXJmdWxsIHBhZ2VkIExpc3QuDQoJICAg
ICAgICBUaGUgamF2YWRvYyBhbmQgZXZlbnR1YWxseSB0ZXN0IHNvdXJjZSB3aWxsIG5vcm1hbGx5
IHN1ZmZpY2UgdG8NCgkgICAgICAgIHVuZGVyc3RhbmQgdGhlIHVzZS4NCgkgICAgICAgIE5ldmVy
dGhlbGVzcywgaWYgSSB3aWxsIG5vdCBiZSBpbXBhY3RlZCBieSB0aGUgY3VycmVudCB0ZXN0IGlz
c3VlcywgSQ0KCSAgICAgICAgd2lsbCB0cnkgdG8gcHJvdmlkZSBhIHRpbnkgc2FtcGxlIGFwcGxp
Y2F0aW9uIGZvciBkZW1vbnN0cmF0aW5nLg0KCSAgICAgICANCgkgICAgICAgIEFmdGVyIDAuOCB3
aWxsIGJlIHJlbGVhc2VkLCBJIGNvdWxkIGhhdmUgc29tZSBoZWxwIGZvciByZXdpZXZpbmcgdGhl
DQoJICAgICAgICBqYXZhZG9jIGNvbW1lbnRzIGFzIG15IEVuZ2xpc2ggaXMgdmVyeSBmYXIgZnJv
bSBwZXJmZWN0Lg0KCSAgICAgICANCgkgICAgICAgIFJlZ2FyZHMsDQoJICAgICAgICBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCgkgICAgICAgIEplYW4tUGllcnJlIFBhd2xhaw0KCSAg
ICAgICAganAucGF3bGFrQHRpc2NhbGkuZnINCgkgICAgICAgIA0KCSAgICAgICANCgkgICAgICAg
DQoJICAgICAgIA0KCSAgICAgICANCgkgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCgkgICAgICAgIFRoaXMgU0YubmV0IGVtYWls
IGlzIHNwb25zb3JlZCBieTogT2JqZWN0U3RvcmUuDQoJICAgICAgICBJZiBmbGF0dGVuaW5nIG91
dCBDKysgb3IgSmF2YSBjb2RlIHRvIG1ha2UgeW91ciBhcHBsaWNhdGlvbiBmaXQgaW4gYQ0KCSAg
ICAgICAgcmVsYXRpb25hbCBkYXRhYmFzZSBpcyBwYWluZnVsLCBkb24ndCBkbyBpdCEgQ2hlY2sg
b3V0IE9iamVjdFN0b3JlLg0KCSAgICAgICAgTm93IHBhcnQgb2YgUHJvZ3Jlc3MgU29mdHdhcmUu
IGh0dHA6Ly93d3cub2JqZWN0c3RvcmUubmV0L3NvdXJjZWZvcmdlDQoJICAgICAgICBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCSAgICAgICAgU3ByaW5n
ZnJhbWV3b3JrLWRldmVsb3BlciBtYWlsaW5nIGxpc3QNCgkgICAgICAgIFNwcmluZ2ZyYW1ld29y
ay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJICAgICAgICBodHRwczovL2xpc3Rz
LnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVy
DQoJICAgICAgIA0KCQ0KCQ0KCQ0KCSoqKioqKioqKiogU1BFQ0lBTCBBRFNMICoqKioqKioqKioN
CglMJ0FEU0wgw6AgcGFydGlyIGRlIDE1LDk1IEVVUi9tb2lzIGV0IGxlIG1vZGVtIEFEU0wgb2Zm
ZXJ0ID8gIEMnZXN0IGVuIGV4Y2x1c2l2aXTDqSBjaGV6IFRpc2NhbGkgIQ0KCVBvdXIgcHJvZml0
ZXIgZGUgY2V0dGUgb2ZmcmUsIGNsaXF1ZXogaWNpOiBodHRwOi8vcmVnaXN0ZXIudGlzY2FsaS5m
ci9hZHNsLw0KCU9mZnJlIHNvdW1pc2Ugw6AgY29uZGl0aW9ucy4NCgkNCgkNCgkNCg0K

RE : [Springframework-developer] Authentication and authorization

[JP P. <jp....@ti...>]

Hi Isabelle, J=FCrgen,

XML has nothing to do with container authorization. It is only the
default setting of most application servers. I have only worked with
Tomcat and JBoss, but both allow the use of LDAP or database as
authorization repositories (JdbcRealm for Tomcat). Changing xml files is
not a job in this case.

I can't let say that it is useless. But, as said J=FCrgen, it doesn't =
make
the complete job. J=FCrgen omitted the possibility to have conditional
parts in JSP depending of the status logged/not logged or having a given
role. The management of protected pages is clean and simple.

Nevertheless:

- The login page cannot be asked directly. I had to create a dummy
protected page to simulate a login. The page simply redirects to the
home page.
- As consequence, it is not possible to have form fields for login in
the banner or other continuously displayed part of the page.
- The login process doesn't let loading a custom object in the user's
session ( no hooks). I had for every request to check elsewhere (top of
servlet, filter, ...) if the user is already logged in without having
his context loaded and make the job if necessary.
- The setting of the repository management is server dependent.

The need of a general authentication management in the framework seems
to be clear as no standard solution answer to the developer needs. The
main question is has this to work in part with the container
authentication or not (maybe optionally). If yes, and it would have an
interest, the main issue is the last point I mentioned, the
server-dependent nature of the authentication repository settings. The
part included in web.xml is, in contrast, portable.

Regards,
Jean-Pierre

> -----Message d'origine-----
> De=A0: spr...@li...
> [mailto:spr...@li...] De la
part
> de Isabelle Muszynski
> Envoy=E9=A0: lundi 26 mai 2003 10:46
> =C0=A0: j=FCrgen h=F6ller [werk3AT]
> Cc=A0: spr...@li...
> Objet=A0: Re: [Springframework-developer] Authentication and
authorization
>=20
> Hi Juergen,
>=20
> I have found container authorization to be pretty useless. In a
typical
> business scenario, the user population is fluid (add, delete, ...) and
> constantly changing the xml files is a no-no.
> On the other hand, there are also lots of different ways people solve
the
> problem in their applications : database, LDAP, ...
> Maybe JAAS support would be nice, then it's simply a question of
having
> the service providers for the different protocols.
>=20
> Isabelle
>=20
> On Sun, May 25, 2003 at 11:31:55PM +0200, j=FCrgen h=F6ller [werk3AT]
wrote:
> > Hi everyone,
> >
> > I just had a look at J2EE 1.4's JACC (Java Authorization Contract
for
> Containers), and I'm disappointed. Well, it deals with authorization
of
> web and EJB resources, what else would you expect from that name? But
who
> needs that, deployment descriptors allow to specify resource
authorization
> in a good enough way already, e.g. in web.xml.
> >
> > What I really miss is portable authentication. Every freaking
container
> has its own API for authenticators, basically taking username and
> password, and returning the roles for this user, if any. Of course,
there
> are always default implementations for XML files and database tables.
But
> you'll have to get container-specific to use the J2EE login
infrastructure
> in your apps if you keep the user data in your application database,
or
> some other application-specific datastore.
> >
> > Furthermore, a J2EE web login simply authenticates and returns to
the
> original URL if the user is authorized. On each following URL, the
> authorization check happens again, forbidding access if the user isn't
in
> an appropriate role. Of course, servlets can programmatically access
the
> user name, and check if the current user is a given role - but that's
it.
> There are no hooks for loading user-specific settings on login, for
> example.
> >
> > Thus, J2EE authentication seems only usable for basic website
> administration purposes, like restricting certain namespaces for
> administrators only, specifying the administrator usernames and
passwords
> in a server-specific way. It's completely inappropriate for handling a
> tightly integrated application user base, potentially with thousands
of
> customized users.
> >
> > Why? The J2EE model doesn't really fit the concept of a login into a
> rich web application. Typically, a login page is either the starting
> point, or required for some parts of the application. On login, user
> settings get loaded and put in the session. Web controllers offen act
> according to these user settings, or are forbidden without login. A
logout
> either removes the user settings from the session, their existence
being
> related to the login status, or invalidates the session.
> >
> > All things considered, it would make sense to offer authentication
> support within Spring's web MVC. The basic requirements are the ones
from
> the last paragraph. Of course, it is already possible to implement
this
> via a custom LoginController, checking a login/logout request and
handling
> the user settings in the session, and respective checks in business
> controllers. I just wonder if we could offer dedicated authentication
> support to ease the task.
> >
> > Regards,
> > Juergen
>=20
> --
> Isabelle Muszynski
> Software Engineer
> Zandweellaan 4
> 2660 Antwerpen
> Belgium
> Tel. 32-(0)3-830 18 54
> Mobile: 32-(0)485 49 50 89
> Email: isa...@me...
> Website: www.meta-logix.com
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] changes for 0.8

[Isabelle M. <isa...@me...>]

Hi everyone,

I am reviewing the tutorial, making sure everything still works with the latest sources. Once that is done, I will post a zip file and a tarball on my website and post a message to the list.
There is no new material in the tutorial, the mySQL key generation took longer than expected.

Isabelle
-- 
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com

Re: [Springframework-developer] MagicDraw license for Spring project

[Isabelle M. <isa...@me...>]

Hi Gary,

I haven't heard from you after my last message. Does this mean that Magic Draw has decided against supporting us with licences?

Best regards,

Isabelle


On Fri, May 16, 2003 at 10:04:44AM +0200, Isabelle Muszynski wrote:
> Hi Gary,
> 
> Have you been able to get something official laid out? Thanks for the 30-day license. I've been using it to chart the whole project.
> We have someone working on our website, the idea is to have a section for our sponsors where you can explain who you are and why you support the open source movement.
> 
> Best regards,
> 
> Isabelle Muszynski
> 
> On Tue, Apr 22, 2003 at 11:58:34AM -0500, Gary Duncanson wrote:
> > Isabelle,
> > 
> > I just sent a 30 day full evaluation key for MagicDraw for your entire group. Please contact me during the first week of May, as the end of the month sales for products and services are keeping be 150% busy.
> > Sorry for the slow response. I am truing to get caught up. We will get something office laid out during the first week of May.
> > 
> > Sincerely,
> > 
> > Gary
> > 
> > Isabelle Muszynski wrote:
> > 
> > > Hi Gary,
> > >
> > > Apparently more of us are interested in using the professional edition. For example, Thomas Risberg has started using it to generate the data model for our tutorial. See http://www.tridb.org/spring.html.
> > >
> > > Isabelle
> > >
> > > On Thu, Apr 17, 2003 at 08:23:52AM -0500, Gary Duncanson wrote:
> > > > Folks,
> > > >
> > > > How many people are involved in the effort? I see that you would have need
> > > > for both the professional and standard editions. What I could do is provide
> > > > you with a few standard copies and a single floating professional to be used
> > > > for the Spring Framework Project only.
> > > >
> > > > Would this suite your needs?
> > > >
> > > > For our part, we would like a quote from you for our web page and a link
> > > > from your project site to MagicDraw.
> > > >
> > > > Sincerely,
> > > >
> > > > Gary Duncanson,
> > > > Executive Vice President,
> > > > Sales and Marketing
> > > > No Magic, Inc. USA
> > > > 800 East Campbell Road, STE 199
> > > > Richardson, TX 75081
> > > > Direct:  972-527-9377
> > > > Fax:   972-527-9470
> > > > Mobile & Pager: 469-222-5966
> > > > E-mail: ga...@no...
> > > > WWW: http://www.nomagic.com
> > > >
> > > >
> > > > Thomas Risberg wrote:
> > > >
> > > > > Gary,
> > > > >
> > > > > I understand that Isabelle Muszynski has been in contact with you
> > > > > regarding using MagicDraw for our open source project "Spring
> > > > > Framework".  I joined the group in February and I have been working on
> > > > > enhancements to the JDBC framework.  I have a 20+ year career as a
> > > > > database developer (you can view my resume at
> > > > > http://www.tridb.com/resume.php) and working on this JDBC framework is
> > > > > really exciting, since it makes dealing with the details of the API soo
> > > > > much easier.
> > > > >
> > > > > It would be a great benefit if we could use MagicDraw for documenting
> > > > > the sample applications and tutorials that we are planning to develop.
> > > > > In addition to modeling Java classes, I would also use MagicDraw to
> > > > > develop any database models using the Data Modeling Profile for the UML.
> > > > >  That would allow us to use one single tool for all our modeling needs.
> > > > >
> > > > > I have occasionally used the MagicDraw demo version, and I actually
> > > > > prefer it to Together when I am modeling at a higher level and when I am
> > > > > not interested in synchronizing with my Java code.  I work for TargetRx,
> > > > > Inc (www.targetrx.com) and if we did not already  have a sizeable
> > > > > investment in ERwin and Together, than I would definitely have
> > > > > considered MagicDraw for our modeling needs.
> > > > >
> > > > > If you have any questions you can e-mail me at tri...@ta... or
> > > > > tri...@tr....
> > > > >
> > > > > Sincerely,
> > > > >
> > > > > Thomas Risberg
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > --
> > > Isabelle Muszynski
> > > Software Engineer
> > > Zandweellaan 4
> > > 2660 Antwerpen
> > > Belgium
> > > Tel. 32-(0)3-830 18 54
> > > Mobile: 32-(0)485 49 50 89
> > > Email: isa...@me...
> > > Website: www.meta-logix.com
> > 
> > --
> > Gary Duncanson,
> > Executive Vice President,
> > Sales and Marketing
> > No Magic, Inc. USA
> > 800 East Campbell Road, STE 199
> > Richardson, TX 75081
> > Direct:  972-527-9377
> > Fax:   972-527-9470
> > Mobile & Pager: 469-222-5966
> > E-mail: ga...@no...
> > WWW: http://www.nomagic.com
> > 
> > 
> > 
> > 
> 
> -- 
> Isabelle Muszynski
> Software Engineer
> Zandweellaan 4
> 2660 Antwerpen
> Belgium
> Tel. 32-(0)3-830 18 54
> Mobile: 32-(0)485 49 50 89
> Email: isa...@me...
> Website: www.meta-logix.com
> 
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 

-- 
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com

Re: [Springframework-developer] Authentication

[Brett B. <br...@po...>]

Hi

Unfortunately, JAAS only supports class based Authorisation(i.e. a user
can operate on a particular type) where a number of business cases require
instance based security (i.e. can this user operate on this specific
instance).  I have written a framework recently to support instance based
authorisation at work so I can write a new one for Spring if that's ok,
possibly sprucing it up to use AOP.

Please let me know what you think.

Cheers


Brett

Re: [Springframework-developer] Authentication and authorization

[Isabelle M. <isa...@me...>]

Hi Juergen,

I have found container authorization to be pretty useless. In a typical business scenario, the user population is fluid (add, delete, ...) and constantly changing the xml files is a no-no.
On the other hand, there are also lots of different ways people solve the problem in their applications : database, LDAP, ...
Maybe JAAS support would be nice, then it's simply a question of having the service providers for the different protocols.

Isabelle

On Sun, May 25, 2003 at 11:31:55PM +0200, jürgen höller [werk3AT] wrote:
> Hi everyone,
>  
> I just had a look at J2EE 1.4's JACC (Java Authorization Contract for Containers), and I'm disappointed. Well, it deals with authorization of web and EJB resources, what else would you expect from that name? But who needs that, deployment descriptors allow to specify resource authorization in a good enough way already, e.g. in web.xml.
>  
> What I really miss is portable authentication. Every freaking container has its own API for authenticators, basically taking username and password, and returning the roles for this user, if any. Of course, there are always default implementations for XML files and database tables. But you'll have to get container-specific to use the J2EE login infrastructure in your apps if you keep the user data in your application database, or some other application-specific datastore.
>  
> Furthermore, a J2EE web login simply authenticates and returns to the original URL if the user is authorized. On each following URL, the authorization check happens again, forbidding access if the user isn't in an appropriate role. Of course, servlets can programmatically access the user name, and check if the current user is a given role - but that's it. There are no hooks for loading user-specific settings on login, for example.
>  
> Thus, J2EE authentication seems only usable for basic website administration purposes, like restricting certain namespaces for administrators only, specifying the administrator usernames and passwords in a server-specific way. It's completely inappropriate for handling a tightly integrated application user base, potentially with thousands of customized users.
>  
> Why? The J2EE model doesn't really fit the concept of a login into a rich web application. Typically, a login page is either the starting point, or required for some parts of the application. On login, user settings get loaded and put in the session. Web controllers offen act according to these user settings, or are forbidden without login. A logout either removes the user settings from the session, their existence being related to the login status, or invalidates the session.
>  
> All things considered, it would make sense to offer authentication support within Spring's web MVC. The basic requirements are the ones from the last paragraph. Of course, it is already possible to implement this via a custom LoginController, checking a login/logout request and handling the user settings in the session, and respective checks in business controllers. I just wonder if we could offer dedicated authentication support to ease the task.
>  
> Regards,
> Juergen

-- 
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com

Re: RE : [Springframework-developer] mysql key generation

[Isabelle M. <isa...@me...>]

Hi Jean-Pierre,

the shell script I sent is up-to-date, except for the typo Rod discoverd in the aopalliance (I had aopcalliance or some such)

Isabelle

On Sun, May 25, 2003 at 09:19:44PM +0200, JP Pawlak wrote:
> Hi Isabelle,
> 
> It is effectively the way I suggested. You made also a great job about
> multithreading.
> But I have still the same issue. How setting, in practice, for run the
> live tests. I didn't look for now at the batch you sent to Rod. Is it
> currently up to date or is a newer way?
> 
> Regards,
> Jean-Pierre
> 
> 
> > -----Message d'origine-----
> > De : spr...@li...
> > [mailto:spr...@li...] De la
> part
> > de Isabelle Muszynski
> > Envoyé : dimanche 25 mai 2003 18:29
> > À : spr...@li...
> > Objet : [Springframework-developer] mysql key generation
> > 
> > Hi everyone,
> > 
> > I've rewritten mySQL key generation (MySQLMaxValueIncrementer.java).
> > KeyBinder is no longer used. For a sample of how to use key
> generation,
> > have a look at livetest/JdbcInsertTestSuite.java.
> > 
> > Your main table (the one for which you want key generation) should not
> > auto_increment its key. The sequence table, on the other hand, should
> be
> > auto_increment. Have a look at createTables in JdbcInsertTestSuite or
> at
> > the javadoc for MySQLMaxValueIncrementer.java.
> > 
> > Please let me know if there still are problems. One of the tests is
> for
> > behavior when multithreading, and on my system it succeeds.
> > 
> > Isabelle
> > 
> > --
> > Isabelle Muszynski
> > Software Engineer
> > Zandweellaan 4
> > 2660 Antwerpen
> > Belgium
> > Tel. 32-(0)3-830 18 54
> > Mobile: 32-(0)485 49 50 89
> > Email: isa...@me...
> > Website: www.meta-logix.com
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ObjectStore.
> > If flattening out C++ or Java code to make your application fit in a
> > relational database is painful, don't do it! Check out ObjectStore.
> > Now part of Progress Software. http://www.objectstore.net/sourceforge
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 

-- 
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com