springframework-developer — Spring Framework developers list

RE: [Springframework-developer] Commons Logging

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

SSd2ZSBqdXN0IGNvbW1pdHRlZCB0aGUgQ29tbW9ucyBMb2dnaW5nIGNoYW5nZXMuIFRoaXMgc2hv
dWxkbid0IGNhdXNlIGFueSBwYWluLCB5b3UnbGwganVzdCBuZWVkIGNvbW1vbnMtbG9nZ2luZy5q
YXIgKGluIG1haW4vbGliL2xvZzRqKSBpbiB0aGUgbGlicyBvZiB5b3VyIGRlcGxveWVkIGFwcGxp
Y2F0aW9ucy4NCg0KRXZlbiBpZiBJJ3ZlIGNoYW5nZWQgbXkgbWluZCBhIGJpdCwgSSdtIHN0aWxs
IGEgTG9nNEogcHJvcG9uZW50LCBhbmQgSSB3aWxsIHByb2JhYmx5IHVzZSBMb2c0SiBmb3IgYWxs
IG15IFNwcmluZyB3ZWIgYXBwbGljYXRpb25zLiBMb2c0SiBpcyBvYnZpb3VzbHkgc3RpbGwgdGhl
IHByaW1hcnkgY2hvaWNlIGZvciBTcHJpbmcgYXBwcywgYXMgaW5kaWNhdGVkIGJ5IG91ciBkZWRp
Y2F0ZWQgY29uZmlndXJhdGlvbiBzdXBwb3J0IGZvciBpdCAoTG9nNGpDb25maWd1cmVyLCBMb2c0
akNvbmZpZ1NlcnZsZXQpLg0KDQpDb21tb25zIExvZ2dpbmcgc2ltcGx5IGVuYWJsZXMgbW9yZSBm
bGV4aWJsZSB1c2FnZSBvZiBwYXJ0cyBvZiBTcHJpbmcsIGxpa2UgaW4gYXBwbGV0cyBhcyBJIG1l
bnRpb25lZCwgYW5kIGludGVncmF0ZXMgbmljZWx5IHdpdGggdGhlIGxpa2VzIG9mIEhpYmVybmF0
ZSBhbmQgS29kbyBKRE8uIEl0J3MgcHJvYmFibHkgYmV0dGVyIHRvIGxldCB0aGUgYXBwbGljYXRp
b24gZGV2ZWxvcGVyIGNob29zZSB0aGUgbG9nZ2luZyBzb2x1dGlvbiwgZXNwZWNpYWxseSB3aGVu
IGNvbWJpbmVkIHdpdGggb3RoZXIgdG9vbGtpdHMuDQoNClJlZ2FyZHMsDQpKdWVyZ2VuDQoNCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJvZC5qb2huc29uQGludGVyZmFjZTIx
LmNvbSBbbWFpbHRvOnJvZC5qb2huc29uQGludGVyZmFjZTIxLmNvbV0NClNlbnQ6IFdlZG5lc2Rh
eSwgTWF5IDI4LCAyMDAzIDQ6NDMgUE0NClRvOiBqw7xyZ2VuIGjDtmxsZXIgW3dlcmszQVRdDQpD
Yzogc3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNClN1Ympl
Y3Q6IFJlOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gQ29tbW9ucyBMb2dnaW5nDQoNCg0K
SSBkb24ndCBoYXZlIGFueSBvYmplY3Rpb24gdG8gY29tbW9ucyBsb2dnaW5nLCBzbyBsb25nIGFz
IGl0IA0KZG9lc24ndCBzYWNyaWZpY2UgdG9vIG11Y2ggcG93ZXIgYW5kIGlzIGVhc3kgdG8gc2V0
IHVwLg0KDQpJdCBkb2VzIHNlZW0gd2lkZWx5IHVzZWQtLUkgbm90aWNlZCBpdHMgdXNlIGluIEhp
YmVybmF0ZSBhbmQgDQpLb2RvIGFsc28uDQoNClJlZ2FyZHMsDQpSb2QNCg==

[Springframework-developer] new context init problem

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

Juergen,

I just updated my build of Spring with the latest file changes made 
since Isabelle updated MySqlMaxValueIncrementer on 26-may.

My petclinic app will no longer initialize properly. There seems to be a 
problem with ContextRefreshedEvent. It was recently changed to add a 
getApplicationContext convenience method which casts the source object 
to an ApplicationContext. The constructor was also changed to used to 
initialize the source using an ApplicationContext parameter  instead of 
an Object param. This seems to be what causes the problem as the 
ApplicationEvent constructor doesn't expect to see an 
ApplicationContext. The fact that getApplicationContext does this cast 
seems to imply that the param class change was inadvertent and should be 
changed back to using an Object param.

I made the change in my own local copy , recompiled, and it works.

BTW, the petclinic web.xml no longer specifies a ContextLoader but uses 
a listener, i.e.

    <listener>
        
<listener-class>com.interface21.web.context.ContextLoaderListener</listener-class>
    </listener>


Ken



The server log shows the following :

blah, blah, blah

2003-05-28 09:56:56 StandardManager[/petclinic_demo_tutorial-1.0]: 
Seeding of random number generator has been completed
2003-05-28 09:56:57 StandardContext[/petclinic_demo_tutorial-1.0]: 
Exception sending context initialized event to listener instance of 
class com.interface21.web.context.ContextLoaderListener
java.lang.NoSuchMethodError: 
com.interface21.context.support.ContextRefreshedEvent: method 
<init>(Ljava/lang/Object;)V not found
    at 
com.interface21.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:237)
    at 
com.interface21.web.context.support.XmlWebApplicationContext.setServletContext(XmlWebApplicationContext.java:121)
    at 
com.interface21.web.context.ContextLoader.initContext(ContextLoader.java:55)
    at 
com.interface21.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:20)
    at 
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3269)

blah,blah,blah

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

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

Let's take the following (which I posted earlier today) as the basis for
discussion.

JP is happy.  Is everyone else happy with this, or have any suggestions?

I've written a DTD, which makes authoring fairly easy (although the Eclipse
XML editor isn't enforcing correct referencing):


<bean class="MyClass" id="foos" singleton="false>
<property name="foo"><value>FOO</value></property>

<property name="foo3">
  <ref refid="foo3"/>
</property>
<property name="foo4">
   <value>FOO4.1</value>
   <value>FOO4.2</value>
   <ref refid="foo4.3"/>
</property>
</bean>

Always consistent: always at least one value or ref
subelement of a property elt; <value> contains only text
data; ref body must be empty.

Slightly more verbose, but probably easier to author with an
XML editor (even the basic Eclipse XML editor I use most of
the time).

I don't care whether it's called value or data, or anything
else...any ideas?

Regards,
Rod

[Springframework-developer] =?iso-8859-1?Q?Re:_=09Re:_[Springframework-developer]_Spring_bean_factory_XML_format?=

[=?iso-8859-1?Q?<jp....@ti...>]

Hi Rod,=0D=0A=0D=0AAs the proposal is consistent and real needs are invok=
ed, I have no more objection.=0D=0A=0D=0ARegards,=0D=0AJean-Pierre=0D=0A=0D=
=0A---------- Initial Header -----------=0D=0A=0D=0AFrom      : springfra=
mew...@li...=0D=0ATo          : "jp.pawla=
k...@ti..." <jp....@ti...>=0D=0ACc          : "rod.johnson" <ro=
d.j...@in...>,       isabelle <isa...@me...>,    =
   "rod.johnson" <rod...@in...>,       springframework-dev=
eloper <spr...@li...>=0D=0ADate      :=
 Wed, 28 May 2003 07:25:25 -0400=0D=0ASubject : Re: 	Re: [Springframework=
-developer] Spring bean factory XML format=0D=0A=0D=0AJP suggested:=0D=0A=
=0D=0A<bean class=3D"MyClass" id=3D"foos" singleton=3D"false> =0D=0A<prop=
erty name=3D"foo">FOO</property> =0D=0A<property name=3D"foo2" value=3D"F=
OO2"/> =0D=0A<property name=3D"foo3" refid=3D"foo3"/> =0D=0A<property nam=
e=3D"foo4"> =0D=0A   <data>FOO4.1</data> =0D=0A   <data value=3D"FOO4.2"/=
> =0D=0A   <data refid=3D"foo4.3"/> =0D=0A</property> =0D=0A</bean> =0D=0A=
=0D=0A=0D=0AThe problem I see here is that there are 3 ways of defining =0D=
=0Aliterals:=0D=0A- in the body of the property element (as before)=0D=0A=
- in a value attribute. I don't think this is a good idea, as =0D=0Aattri=
butes can only hold simple strings without getting into =0D=0Anasty escap=
ing.=0D=0A- in a <data> element, which is necessary anyway for a =0D=0Aco=
llection.=0D=0A=0D=0AJuergen makes a good point about mixed collections o=
f =0D=0Areferences and string data (which of course would be =0D=0Aconver=
ted to objects). Initially I thought this was unlikely, =0D=0Abut I reali=
sed it has quite a few uses (with the AOP proxy =0D=0Afactory, for exampl=
e), and the <value> subelement I suggested =0D=0Ahandles it. (It's alread=
y implemented: see collections.xml in =0D=0Abeanfactory.xml tests.)=0D=0A=
=0D=0AThe most consistent approach IMHO is:=0D=0A=0D=0A<bean class=3D"MyC=
lass" id=3D"foos" singleton=3D"false> =0D=0A<property name=3D"foo"><value=
>FOO</value></property> =0D=0A=0D=0A<property name=3D"foo3">=0D=0A  <ref =
refid=3D"foo3"/> =0D=0A</property>=0D=0A<property name=3D"foo4"> =0D=0A  =
 <value>FOO4.1</value> =0D=0A   <value>FOO4.2</value>=0D=0A   <ref refid=3D=
"foo4.3"/> =0D=0A</property> =0D=0A</bean> =0D=0A=0D=0AAlways consistent:=
 always at least one value or ref =0D=0Asubelement of a property elt; <va=
lue> contains only text =0D=0Adata; ref body must be empty.=0D=0A=0D=0ASl=
ightly more verbose, but probably easier to author with an =0D=0AXML edit=
or (even the basic Eclipse XML editor I use most of =0D=0Athe time).=0D=0A=
=0D=0AI don't care whether it's called value or data, or anything =0D=0Ae=
lse...any ideas?=0D=0A=0D=0ARegards,=0D=0ARod=0D=0A=0D=0A=0D=0A----------=
---------------------------------------------=0D=0AThis SF.net email is s=
ponsored by: ObjectStore.=0D=0AIf flattening out C++ or Java code to make=
 your application fit in a=0D=0Arelational database is painful, don't do =
it! Check out ObjectStore.=0D=0ANow part of Progress Software. http://www=
.objectstore.net/sourceforge=0D=0A_______________________________________=
________=0D=0ASpringframework-developer mailing list=0D=0ASpringframework=
-dev...@li...=0D=0Ahttps://lists.sourceforge.net/lists=
/listinfo/springframework-developer=0D=0A=0A=0A********** SPECIAL ADSL **=
********=0AL'ADSL =E0 partir de 15,95 EUR/mois et le modem ADSL offert ? =
 C'est en exclusivit=E9 chez Tiscali !=0APour profiter de cette offre, cl=
iquez ici: http://register.tiscali.fr/adsl/=0AOffre soumise =E0 condition=
s.=0A

Re: [Springframework-developer] Commons Logging

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

Hi Juergen,

Sounds good to me!

Isabelle

On Wed, May 28, 2003 at 04:17:20PM +0200, jürgen höller [werk3AT] wrote:
> Hi Rod, JP, Isabelle, everybody,
> 
> As there seems to be the time for basic issues... ;-)
> 
> I've been thinking about using Commons Logging for quite a while, instead of Log4J directly. Initially I've been somewhat sceptical about its value, especially regarding the drawback of tricky classloader issues that might arise in a container environment. But Commons Logging 1.0.3 works without hassle in Tomcat 4.0, Tomcat 4.1, and Resin 2.1 - both with and without Log4J. The release notes say that they've been working busily on proper behavior within a container, using the thread context class loader everywhere now.
> 
> If Log4j is present in either WEB-INF/lib or the container's common lib directory, Log4J is chosen by default. If not and running on J2SE 1.4, JDK logging gets used. On J2SE 1.3, the fallback is a simple console logger. You can explicitly configure the implementation too, via a commons-logging.properties file in the classpath, or via VM parameters.
> 
> I've tried a lot of combinations: Both commons-logging.jar and log4j.jar in each WEB-INF/lib, both in common lib, commons-logging in WEB-INF/lib + log4j.jar in common lib - all of them work in Tomcat and Resin. There's only one combo that doesn't work: commons-logging.jar just in common lib + log4j.jar in WEB-INF/lib. The latter with a commons-logging copy in WEB-INF/lib does work. So there's only one definitive rule: Keep a commons-logging.jar in your WEB-INF/lib.
> 
> Today I've prototyped using Commons Logging within Spring, and it works nicely - I just had to exchange the Log4J Logger declarations with the following:
> 
> 	protected final Log logger = LogFactory.getLog(getClass());
> 
> A Commons Logging Log object is very similar to a Log4J Logger object, mirroring the Log4J API closely. The configuration and runtime impact is negligible - you probably wouldn't even recognize that Commons Logging is used after refreshing from CVS, as Log4J still gets used by default, applying any Log4J configuration that was there before.
> 
> My main intent is to support as many environments as possible. At werk3AT, we've recently considered using Spring in an applet (yep, they're still around), debating about the inclusion of Log4J in the download. Just depending on Commons Logging would ease such things significantly, as its JAR is just 31 KB including all wrapper implementations! A even slimmer version is provided too, containing just the J2SE 1.4 logger and the simple one - in 22 KB.
> 
> Both Hibernate and Kodo JDO use Commons Logging too, so we would be in good neighborhood. And it seems that we wouldn't lose anything, not even simplicity. All things considered, I vote for changing to Commons Logging promptly (I could check it in this evening). What do you think? Any objections?
> 
> Regards,
> Juergen
> 
> 
> DI Jürgen Höller
> 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
> 
> 
> 
> -------------------------------------------------------
> 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

[Springframework-developer] =?iso-8859-1?Q?Re:_[Springframework-developer]_Commons_Logging?=

[=?iso-8859-1?Q?<jp....@ti...>]

As it is what I used before Spring recommandations, I have no problem wit=
h.=0D=0AI work in a relatively constant environnement (j2sdk1.4.1 -JBoss =
3.2 -MySql 4.0.12 - WIN2000/XP), so I don't know nothing about issues in =
other contexts. I don't have too the deep knowledge to compare really fea=
tures. Commons Logging is for me sufficient and the more portable way.=0D=
=0A=0D=0ARegards,=0D=0AJean-Pierre=0D=0A=0D=0A---------- Initial Header -=
----------=0D=0A=0D=0AFrom      : springframework-developer-admin@lists.s=
ourceforge.net=0D=0ATo          : "j=FCrgen h=F6ller [werk3AT] " <juergen=
.ho...@we...>=0D=0ACc          : springframework-developer@lists.=
sourceforge.net=0D=0ADate      : Wed, 28 May 2003 10:43:16 -0400=0D=0ASub=
ject : Re: [Springframework-developer] Commons Logging=0D=0A=0D=0AI don't=
 have any objection to commons logging, so long as it =0D=0Adoesn't sacri=
fice too much power and is easy to set up.=0D=0A=0D=0AIt does seem widely=
 used--I noticed its use in Hibernate and =0D=0AKodo also.=0D=0A=0D=0AReg=
ards,=0D=0ARod=0D=0A=0D=0A=0D=0A-----------------------------------------=
--------------=0D=0AThis SF.net email is sponsored by: ObjectStore.=0D=0A=
If flattening out C++ or Java code to make your application fit in a=0D=0A=
relational database is painful, don't do it! Check out ObjectStore.=0D=0A=
Now part of Progress Software. http://www.objectstore.net/sourceforge=0D=0A=
_______________________________________________=0D=0ASpringframework-deve=
loper mailing lis...@li...=0D=
=0Ahttps://lists.sourceforge.net/lists/listinfo/springframework-developer=
=0D=0A=0A=0A********** SPECIAL ADSL **********=0AL'ADSL =E0 partir de 15,=
95 EUR/mois et le modem ADSL offert ?  C'est en exclusivit=E9 chez Tiscal=
i !=0APour profiter de cette offre, cliquez ici: http://register.tiscali.=
fr/adsl/=0AOffre soumise =E0 conditions.=0A

Re: [Springframework-developer] Commons Logging

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

I don't have any objection to commons logging, so long as it 
doesn't sacrifice too much power and is easy to set up.

It does seem widely used--I noticed its use in Hibernate and 
Kodo also.

Regards,
Rod

[Springframework-developer] Commons Logging

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

Hi Rod, JP, Isabelle, everybody,

As there seems to be the time for basic issues... ;-)

I've been thinking about using Commons Logging for quite a while, =
instead of Log4J directly. Initially I've been somewhat sceptical about =
its value, especially regarding the drawback of tricky classloader =
issues that might arise in a container environment. But Commons Logging =
1.0.3 works without hassle in Tomcat 4.0, Tomcat 4.1, and Resin 2.1 - =
both with and without Log4J. The release notes say that they've been =
working busily on proper behavior within a container, using the thread =
context class loader everywhere now.

If Log4j is present in either WEB-INF/lib or the container's common lib =
directory, Log4J is chosen by default. If not and running on J2SE 1.4, =
JDK logging gets used. On J2SE 1.3, the fallback is a simple console =
logger. You can explicitly configure the implementation too, via a =
commons-logging.properties file in the classpath, or via VM parameters.

I've tried a lot of combinations: Both commons-logging.jar and log4j.jar =
in each WEB-INF/lib, both in common lib, commons-logging in WEB-INF/lib =
+ log4j.jar in common lib - all of them work in Tomcat and Resin. =
There's only one combo that doesn't work: commons-logging.jar just in =
common lib + log4j.jar in WEB-INF/lib. The latter with a commons-logging =
copy in WEB-INF/lib does work. So there's only one definitive rule: Keep =
a commons-logging.jar in your WEB-INF/lib.

Today I've prototyped using Commons Logging within Spring, and it works =
nicely - I just had to exchange the Log4J Logger declarations with the =
following:

	protected final Log logger =3D LogFactory.getLog(getClass());

A Commons Logging Log object is very similar to a Log4J Logger object, =
mirroring the Log4J API closely. The configuration and runtime impact is =
negligible - you probably wouldn't even recognize that Commons Logging =
is used after refreshing from CVS, as Log4J still gets used by default, =
applying any Log4J configuration that was there before.

My main intent is to support as many environments as possible. At =
werk3AT, we've recently considered using Spring in an applet (yep, =
they're still around), debating about the inclusion of Log4J in the =
download. Just depending on Commons Logging would ease such things =
significantly, as its JAR is just 31 KB including all wrapper =
implementations! A even slimmer version is provided too, containing just =
the J2SE 1.4 logger and the simple one - in 22 KB.

Both Hibernate and Kodo JDO use Commons Logging too, so we would be in =
good neighborhood. And it seems that we wouldn't lose anything, not even =
simplicity. All things considered, I vote for changing to Commons =
Logging promptly (I could check it in this evening). What do you think? =
Any objections?

Regards,
Juergen


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] Spring bean factory XML format

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

Hi Jean-Pierre,

your're right, it's too hot to think clearly right now :-(

Isabelle

On Wed, May 28, 2003 at 12:44:07PM +0200, jp....@ti... wrote:
> Hi Isabelle,
> 
> We are on the same wavelength, just a little "booboo" as you say:
> the "element" elements were not closed in your example:
>   <element refid="alpha"/>
> is what you probably would type. ;)
> 
> Jean-Pierre
> 
> ---------- Initial Header -----------
> 
> From      : spr...@li...
> To          : rod...@in...
> Cc          : spr...@li...
> Date      : Wed, 28 May 2003 12:32:42 +0200
> Subject : Re: [Springframework-developer] Spring bean factory XML format
> 
> HI Rod,
> 
> Do it the way JP suggested :
> 
> <bean id="foo">
>  <property name="moo">moo</property>
>  <property name="coll">
>   <element refid="alpha">
>   <element refid="beta>
>  </property>
> </bean>
> 
> Isabelle
> 
> On Wed, May 28, 2003 at 06:17:54AM -0400, rod...@in... wrote:
> > Isabelle, 
> > 
> > OK, we can change name -> id when defining all beans, and use 
> > refid for references.
> > 
> > The only problem I see with your syntax below...
> > 
> > <property name="thefoo" refid="foo/>
> > <property name="moo">moo</property>
> > 
> > ...is that I can't see how it would support collections. I 
> > see this as a major enhancement, possible with the original 
> > proposal, that had <value> and <ref> subelements.
> > 
> > I can easily change the XML parsing for whatever we agree. 
> > 
> > Regards,
> > Rod
> > 
> > > Hi Rod,
> > > 
> > > There is one thing I do not like about your proposed 
> > syntax: you use <ref
> > > name="xxx"> is used in two different contexts, one when you 
> > define a bean
> > > that can serve as a reference, and once when you refer to 
> > such a bean from
> > > another bean.
> > > That's confusing. It would be better to define with for ex. 
> > an id attribute,
> > > and reference with a refid attribute:
> > > 
> > > <bean name="foo" id="foo"/>
> > > <bean name="bar" id="bar">
> > >   <property name="thefoo" refid="foo/>
> > >   <property name="moo">moo</property>
> > > </bean>
> > > <bean name=baz>
> > >   <property name="bla">blabla</property>
> > > </bean>
> > > 
> > > Note that bean bar can in turn be referenced from other 
> > beans, thanks to its
> > > id attribute. Bean baz cannot be referenced, because it 
> > doesn't have an id
> > > attribute.
> > > 
> > > A validating parser will not help you make sure that bean 
> > foo really exists
> > > when referenced, and neither will a DTD.
> > > 
> > > Isabelle
> > 
> > 
> > -------------------------------------------------------
> > 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
> 
> 
> -------------------------------------------------------
> 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
> 
> 
> ********** SPECIAL ADSL **********
> L'ADSL à partir de 15,95 EUR/mois et le modem ADSL offert ?  C'est en exclusivité chez Tiscali !
> Pour profiter de cette offre, cliquez ici: http://register.tiscali.fr/adsl/
> Offre soumise à conditions.
> 
> 
> 
> 

-- 
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

[Springframework-developer] =?iso-8859-1?Q?Re:_=09Re:_[Springframework-developer]_Spring_bean_factory_XML_format?=

[=?iso-8859-1?Q?<jp....@ti...>]

Hi Rod,=0D=0A=0D=0AAs long as we have the same logic in "element" and "pr=
operty", we can disable either the value attribute either the body conten=
t depending on the way you prefer. I am agnostic on this.=0D=0AThe way to=
 define a value will be unique, but we will have in any case the possibil=
ity of defining directly on the property or in an "element". =0D=0AWe can=
 also define that when "element" are included in the property, it's neces=
sarly an array of collection with one item only?=0D=0AIn this case, all d=
efinitions are one way possible.=0D=0A=0D=0AJean-Pierre=0D=0A=0D=0A------=
---- Initial Header -----------=0D=0A=0D=0AFrom      : <rod.johnson@inter=
face21.com>=0D=0ATo          : "jp....@ti..." <jp.pawlak@tiscali.=
fr>=0D=0ACc          : "rod.johnson" <rod...@in...>,      =
 isabelle <isa...@me...>,       "rod.johnson" <rod.johnson@int=
erface21.com>,       springframework-developer <springframework-developer=
@lists.sourceforge.net>=0D=0ADate      : Wed, 28 May 2003 07:25:25 -0400=0D=
=0ASubject : Re: 	Re: [Springframework-developer] Spring bean factory XML=
 format=0D=0A=0D=0AJP suggested:=0D=0A=0D=0A<bean class=3D"MyClass" id=3D=
"foos" singleton=3D"false> =0D=0A<property name=3D"foo">FOO</property> =0D=
=0A<property name=3D"foo2" value=3D"FOO2"/> =0D=0A<property name=3D"foo3"=
 refid=3D"foo3"/> =0D=0A<property name=3D"foo4"> =0D=0A   <data>FOO4.1</d=
ata> =0D=0A   <data value=3D"FOO4.2"/> =0D=0A   <data refid=3D"foo4.3"/> =
=0D=0A</property> =0D=0A</bean> =0D=0A=0D=0A=0D=0AThe problem I see here =
is that there are 3 ways of defining =0D=0Aliterals:=0D=0A- in the body o=
f the property element (as before)=0D=0A- in a value attribute. I don't t=
hink this is a good idea, as =0D=0Aattributes can only hold simple string=
s without getting into =0D=0Anasty escaping.=0D=0A- in a <data> element, =
which is necessary anyway for a =0D=0Acollection.=0D=0A=0D=0AJuergen make=
s a good point about mixed collections of =0D=0Areferences and string dat=
a (which of course would be =0D=0Aconverted to objects). Initially I thou=
ght this was unlikely, =0D=0Abut I realised it has quite a few uses (with=
 the AOP proxy =0D=0Afactory, for example), and the <value> subelement I =
suggested =0D=0Ahandles it. (It's already implemented: see collections.xm=
l in =0D=0Abeanfactory.xml tests.)=0D=0A=0D=0AThe most consistent approac=
h IMHO is:=0D=0A=0D=0A<bean class=3D"MyClass" id=3D"foos" singleton=3D"fa=
lse> =0D=0A<property name=3D"foo"><value>FOO</value></property> =0D=0A=0D=
=0A<property name=3D"foo3">=0D=0A  <ref refid=3D"foo3"/> =0D=0A</property=
>=0D=0A<property name=3D"foo4"> =0D=0A   <value>FOO4.1</value> =0D=0A   <=
value>FOO4.2</value>=0D=0A   <ref refid=3D"foo4.3"/> =0D=0A</property> =0D=
=0A</bean> =0D=0A=0D=0AAlways consistent: always at least one value or re=
f =0D=0Asubelement of a property elt; <value> contains only text =0D=0Ada=
ta; ref body must be empty.=0D=0A=0D=0ASlightly more verbose, but probabl=
y easier to author with an =0D=0AXML editor (even the basic Eclipse XML e=
ditor I use most of =0D=0Athe time).=0D=0A=0D=0AI don't care whether it's=
 called value or data, or anything =0D=0Aelse...any ideas?=0D=0A=0D=0AReg=
ards,=0D=0ARod=0D=0A=0A=0A********** SPECIAL ADSL **********=0AL'ADSL =E0=
 partir de 15,95 EUR/mois et le modem ADSL offert ?  C'est en exclusivit=E9=
 chez Tiscali !=0APour profiter de cette offre, cliquez ici: http://regis=
ter.tiscali.fr/adsl/=0AOffre soumise =E0 conditions.=0A

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

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

JP suggested:

<bean class="MyClass" id="foos" singleton="false> 
<property name="foo">FOO</property> 
<property name="foo2" value="FOO2"/> 
<property name="foo3" refid="foo3"/> 
<property name="foo4"> 
   <data>FOO4.1</data> 
   <data value="FOO4.2"/> 
   <data refid="foo4.3"/> 
</property> 
</bean> 


The problem I see here is that there are 3 ways of defining 
literals:
- in the body of the property element (as before)
- in a value attribute. I don't think this is a good idea, as 
attributes can only hold simple strings without getting into 
nasty escaping.
- in a <data> element, which is necessary anyway for a 
collection.

Juergen makes a good point about mixed collections of 
references and string data (which of course would be 
converted to objects). Initially I thought this was unlikely, 
but I realised it has quite a few uses (with the AOP proxy 
factory, for example), and the <value> subelement I suggested 
handles it. (It's already implemented: see collections.xml in 
beanfactory.xml tests.)

The most consistent approach IMHO is:

<bean class="MyClass" id="foos" singleton="false> 
<property name="foo"><value>FOO</value></property> 

<property name="foo3">
  <ref refid="foo3"/> 
</property>
<property name="foo4"> 
   <value>FOO4.1</value> 
   <value>FOO4.2</value>
   <ref refid="foo4.3"/> 
</property> 
</bean> 

Always consistent: always at least one value or ref 
subelement of a property elt; <value> contains only text 
data; ref body must be empty.

Slightly more verbose, but probably easier to author with an 
XML editor (even the basic Eclipse XML editor I use most of 
the time).

I don't care whether it's called value or data, or anything 
else...any ideas?

Regards,
Rod

[Springframework-developer] =?iso-8859-1?Q?Re:[Springframework-developer]_RE:_[Springframework-developer]_Spring_bean_factory_XML_format?=

[=?iso-8859-1?Q?<jp....@ti...>]

In addition, using the first way ( the same element with either refid att=
r either value attr) will be coherent with what is to do with properties =
which haven't an array. =0D=0A=0D=0AWe don't have a property and a refPro=
perty element. We could have the same remark at this level.=0D=0A=0D=0AOn=
 all cases, the two levels, "property" and "element" must have the same l=
ogic. Either byReference elements are distinct either they are not but us=
ing "refid".=0D=0A=0D=0AJean-Pierre=0D=0A=0D=0A---------- Initial Header =
-----------=0D=0A=0D=0AFrom      : springframework-developer-admin@lists.=
sourceforge.net=0D=0ATo          : "juergen.hoeller" <juergen.hoeller@wer=
k3at.com>=0D=0ACc          : "springframework-developer" <springframework=
-dev...@li...>=0D=0ADate      : Wed, 28 May 2003 13:03=
:46 +0200=0D=0ASubject : [Springframework-developer] RE: [Springframework=
-developer] Spring bean factory XML format=0D=0A=0D=0AHi Juergen,=0D=0A=0D=
=0AI don't agree. The element passes a value, directly or by reference. B=
ut the job is the same. Making the difference in the used attribute will =
suffice. There is no nature difference between the two cases. Having a co=
herent collection (only one kind of sub-elements) should take precedence.=
 =0D=0AIf a reference element should have much more particular properties=
, the scenario could be the other way, but still it's not.=0D=0A=0D=0AJea=
n-Pierre=0D=0A =0D=0A=0D=0A---------- Initial Header -----------=0D=0A=0D=
=0AFrom      : spr...@li...=0D=0A=
To          : <spr...@li...>=0D=0ACc  =
        : =0D=0ADate      : Wed, 28 May 2003 12:41:39 +0200=0D=0ASubject =
: RE: [Springframework-developer] Spring bean factory XML format=0D=0A=0D=
=0AWhat about mixing references and values in a collection? Would it look=
 as follows:=0D=0A=0D=0A<bean id=3D"foo">=0D=0A <property name=3D"moo">mo=
o</property>=0D=0A <property name=3D"coll">=0D=0A  <element refid=3D"alph=
a"/>=0D=0A  <element refid=3D"beta"/>=0D=0A  <element>gamma</element>=0D=0A=
 </property>=0D=0A</bean>=0D=0A=0D=0ARod's proposed syntax would be like =
this:=0D=0A=0D=0A<bean id=3D"foo">=0D=0A <property name=3D"moo">moo</prop=
erty>=0D=0A <property name=3D"coll">=0D=0A   <ref refid=3D"alpha"/>=0D=0A=
   <ref refid=3D"beta"/>=0D=0A   <value>gamma</value>=0D=0A </property>=0D=
=0A</bean>=0D=0A=0D=0AI tend to prefer the latter, as it clearly separate=
s references and values.=0D=0A=0D=0AJuergen=0D=0A=0D=0A=0A=0A********** S=
PECIAL ADSL **********=0AL'ADSL =E0 partir de 15,95 EUR/mois et le modem =
ADSL offert ?  C'est en exclusivit=E9 chez Tiscali !=0APour profiter de c=
ette offre, cliquez ici: http://register.tiscali.fr/adsl/=0AOffre soumise=
 =E0 conditions.=0A

[Springframework-developer] =?iso-8859-1?Q?RE:_[Springframework-developer]_Spring_bean_factory_XML_format?=

[=?iso-8859-1?Q?<jp....@ti...>]

Hi Juergen,=0D=0A=0D=0AI don't agree. The element passes a value, directl=
y or by reference. But the job is the same. Making the difference in the =
used attribute will suffice. There is no nature difference between the tw=
o cases. Having a coherent collection (only one kind of sub-elements) sho=
uld take precedence. =0D=0AIf a reference element should have much more p=
articular properties, the scenario could be the other way, but still it's=
 not.=0D=0A=0D=0AJean-Pierre=0D=0A =0D=0A=0D=0A---------- Initial Header =
-----------=0D=0A=0D=0AFrom      : springframework-developer-admin@lists.=
sourceforge.net=0D=0ATo          : <spr...@li...=
eforge.net>=0D=0ACc          : =0D=0ADate      : Wed, 28 May 2003 12:41:3=
9 +0200=0D=0ASubject : RE: [Springframework-developer] Spring bean factor=
y XML format=0D=0A=0D=0AWhat about mixing references and values in a coll=
ection? Would it look as follows:=0D=0A=0D=0A<bean id=3D"foo">=0D=0A <pro=
perty name=3D"moo">moo</property>=0D=0A <property name=3D"coll">=0D=0A  <=
element refid=3D"alpha"/>=0D=0A  <element refid=3D"beta"/>=0D=0A  <elemen=
t>gamma</element>=0D=0A </property>=0D=0A</bean>=0D=0A=0D=0ARod's propose=
d syntax would be like this:=0D=0A=0D=0A<bean id=3D"foo">=0D=0A <property=
 name=3D"moo">moo</property>=0D=0A <property name=3D"coll">=0D=0A   <ref =
refid=3D"alpha"/>=0D=0A   <ref refid=3D"beta"/>=0D=0A   <value>gamma</val=
ue>=0D=0A </property>=0D=0A</bean>=0D=0A=0D=0AI tend to prefer the latter=
, as it clearly separates references and values.=0D=0A=0D=0AJuergen=0D=0A=
=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Isabelle Muszynski [mai=
lto:isa...@me...]=0D=0ASent: Wednesday, May 28, 2003 12:33 PM=0D=
=0ATo: rod...@in...=0D=0ACc: springframework-developer@lis=
ts.sourceforge.net=0D=0ASubject: Re: [Springframework-developer] Spring b=
ean factory XML format=0D=0A=0D=0A=0D=0AHI Rod,=0D=0A=0D=0ADo it the way =
JP suggested :=0D=0A=0D=0A<bean id=3D"foo">=0D=0A <property name=3D"moo">=
moo</property>=0D=0A <property name=3D"coll">=0D=0A  <element refid=3D"al=
pha">=0D=0A  <element refid=3D"beta>=0D=0A </property>=0D=0A</bean>=0D=0A=
=0D=0AIsabelle=0D=0A=0D=0AOn Wed, May 28, 2003 at 06:17:54AM -0400, rod.j=
oh...@in... wrote:=0D=0A> Isabelle, =0D=0A> =0D=0A> OK, we can=
 change name -> id when defining all beans, and use =0D=0A> refid for ref=
erences.=0D=0A> =0D=0A> The only problem I see with your syntax below...=0D=
=0A> =0D=0A> <property name=3D"thefoo" refid=3D"foo/>=0D=0A> <property na=
me=3D"moo">moo</property>=0D=0A> =0D=0A> ...is that I can't see how it wo=
uld support collections. I =0D=0A> see this as a major enhancement, possi=
ble with the original =0D=0A> proposal, that had <value> and <ref> subele=
ments.=0D=0A> =0D=0A> I can easily change the XML parsing for whatever we=
 agree. =0D=0A> =0D=0A> Regards,=0D=0A> Rod=0D=0A> =0D=0A> > Hi Rod,=0D=0A=
> > =0D=0A> > There is one thing I do not like about your proposed =0D=0A=
> syntax: you use <ref=0D=0A> > name=3D"xxx"> is used in two different co=
ntexts, one when you =0D=0A> define a bean=0D=0A> > that can serve as a r=
eference, and once when you refer to =0D=0A> such a bean from=0D=0A> > an=
other bean.=0D=0A> > That's confusing. It would be better to define with =
for ex. =0D=0A> an id attribute,=0D=0A> > and reference with a refid attr=
ibute:=0D=0A> > =0D=0A> > <bean name=3D"foo" id=3D"foo"/>=0D=0A> > <bean =
name=3D"bar" id=3D"bar">=0D=0A> >   <property name=3D"thefoo" refid=3D"fo=
o/>=0D=0A> >   <property name=3D"moo">moo</property>=0D=0A> > </bean>=0D=0A=
> > <bean name=3Dbaz>=0D=0A> >   <property name=3D"bla">blabla</property>=
=0D=0A> > </bean>=0D=0A> > =0D=0A> > Note that bean bar can in turn be re=
ferenced from other =0D=0A> beans, thanks to its=0D=0A> > id attribute. B=
ean baz cannot be referenced, because it =0D=0A> doesn't have an id=0D=0A=
> > attribute.=0D=0A> > =0D=0A> > A validating parser will not help you m=
ake sure that bean =0D=0A> foo really exists=0D=0A> > when referenced, an=
d neither will a DTD.=0D=0A> > =0D=0A> > Isabelle=0D=0A> =0D=0A> =0D=0A> =
-------------------------------------------------------=0D=0A> This SF.ne=
t email is sponsored by: ObjectStore.=0D=0A> If flattening out C++ or Jav=
a code to make your application fit in a=0D=0A> relational database is pa=
inful, don't do it! Check out ObjectStore.=0D=0A> Now part of Progress So=
ftware. http://www.objectstore.net/sourceforge=0D=0A> ___________________=
____________________________=0D=0A> Springframework-developer mailing lis=
t=0D=0A> Spr...@li...=0D=0A> https://l=
ists.sourceforge.net/lists/listinfo/springframework-developer=0D=0A> =0D=0A=
> =0D=0A=0D=0A-- =0D=0AIsabelle Muszynski=0D=0ASoftware Engineer=0D=0AZan=
dweellaan 4=0D=0A2660 Antwerpen=0D=0ABelgium=0D=0ATel. 32-(0)3-830 18 54=0D=
=0AMobile: 32-(0)485 49 50 89=0D=0AEmail: isa...@me...=0D=0AWe=
bsite: www.meta-logix.com=0D=0A=0D=0A=0D=0A------------------------------=
-------------------------=0D=0AThis SF.net email is sponsored by: ObjectS=
tore.=0D=0AIf flattening out C++ or Java code to make your application fi=
t in a=0D=0Arelational database is painful, don't do it! Check out Object=
Store.=0D=0ANow part of Progress Software. http://www.objectstore.net/sou=
rceforge=0D=0A_______________________________________________=0D=0ASpring=
framework-developer mailing lis...@li...=
rceforge.net=0D=0Ahttps://lists.sourceforge.net/lists/listinfo/springfram=
ework-developer=0D=0A=0D=0A=0D=0A----------------------------------------=
---------------=0D=0AThis SF.net email is sponsored by: ObjectStore.=0D=0A=
If flattening out C++ or Java code to make your application fit in a=0D=0A=
relational database is painful, don't do it! Check out ObjectStore.=0D=0A=
Now part of Progress Software. http://www.objectstore.net/sourceforge=0D=0A=
_______________________________________________=0D=0ASpringframework-deve=
loper mailing lis...@li...=0D=
=0Ahttps://lists.sourceforge.net/lists/listinfo/springframework-developer=
=0D=0A=0A=0A********** SPECIAL ADSL **********=0AL'ADSL =E0 partir de 15,=
95 EUR/mois et le modem ADSL offert ?  C'est en exclusivit=E9 chez Tiscal=
i !=0APour profiter de cette offre, cliquez ici: http://register.tiscali.=
fr/adsl/=0AOffre soumise =E0 conditions.=0A

[Springframework-developer] =?iso-8859-1?Q?Re:_[Springframework-developer]_Spring_bean_factory_XML_format?=

[=?iso-8859-1?Q?<jp....@ti...>]

Hi Isabelle,=0D=0A=0D=0AWe are on the same wavelength, just a little "boo=
boo" as you say:=0D=0Athe "element" elements were not closed in your exam=
ple:=0D=0A  <element refid=3D"alpha"/>=0D=0Ais what you probably would ty=
pe. ;)=0D=0A=0D=0AJean-Pierre=0D=0A=0D=0A---------- Initial Header ------=
-----=0D=0A=0D=0AFrom      : spr...@li...=
forge.net=0D=0ATo          : rod...@in...=0D=0ACc         =
 : spr...@li...=0D=0ADate      : Wed, =
28 May 2003 12:32:42 +0200=0D=0ASubject : Re: [Springframework-developer]=
 Spring bean factory XML format=0D=0A=0D=0AHI Rod,=0D=0A=0D=0ADo it the w=
ay JP suggested :=0D=0A=0D=0A<bean id=3D"foo">=0D=0A <property name=3D"mo=
o">moo</property>=0D=0A <property name=3D"coll">=0D=0A  <element refid=3D=
"alpha">=0D=0A  <element refid=3D"beta>=0D=0A </property>=0D=0A</bean>=0D=
=0A=0D=0AIsabelle=0D=0A=0D=0AOn Wed, May 28, 2003 at 06:17:54AM -0400, ro=
d.j...@in... wrote:=0D=0A> Isabelle, =0D=0A> =0D=0A> OK, we =
can change name -> id when defining all beans, and use =0D=0A> refid for =
references.=0D=0A> =0D=0A> The only problem I see with your syntax below.=
..=0D=0A> =0D=0A> <property name=3D"thefoo" refid=3D"foo/>=0D=0A> <proper=
ty name=3D"moo">moo</property>=0D=0A> =0D=0A> ...is that I can't see how =
it would support collections. I =0D=0A> see this as a major enhancement, =
possible with the original =0D=0A> proposal, that had <value> and <ref> s=
ubelements.=0D=0A> =0D=0A> I can easily change the XML parsing for whatev=
er we agree. =0D=0A> =0D=0A> Regards,=0D=0A> Rod=0D=0A> =0D=0A> > Hi Rod,=
=0D=0A> > =0D=0A> > There is one thing I do not like about your proposed =
=0D=0A> syntax: you use <ref=0D=0A> > name=3D"xxx"> is used in two differ=
ent contexts, one when you =0D=0A> define a bean=0D=0A> > that can serve =
as a reference, and once when you refer to =0D=0A> such a bean from=0D=0A=
> > another bean.=0D=0A> > That's confusing. It would be better to define=
 with for ex. =0D=0A> an id attribute,=0D=0A> > and reference with a refi=
d attribute:=0D=0A> > =0D=0A> > <bean name=3D"foo" id=3D"foo"/>=0D=0A> > =
<bean name=3D"bar" id=3D"bar">=0D=0A> >   <property name=3D"thefoo" refid=
=3D"foo/>=0D=0A> >   <property name=3D"moo">moo</property>=0D=0A> > </bea=
n>=0D=0A> > <bean name=3Dbaz>=0D=0A> >   <property name=3D"bla">blabla</p=
roperty>=0D=0A> > </bean>=0D=0A> > =0D=0A> > Note that bean bar can in tu=
rn be referenced from other =0D=0A> beans, thanks to its=0D=0A> > id attr=
ibute. Bean baz cannot be referenced, because it =0D=0A> doesn't have an =
id=0D=0A> > attribute.=0D=0A> > =0D=0A> > A validating parser will not he=
lp you make sure that bean =0D=0A> foo really exists=0D=0A> > when refere=
nced, and neither will a DTD.=0D=0A> > =0D=0A> > Isabelle=0D=0A> =0D=0A> =
=0D=0A> -------------------------------------------------------=0D=0A> Th=
is SF.net email is sponsored by: ObjectStore.=0D=0A> If flattening out C+=
+ or Java code to make your application fit in a=0D=0A> relational databa=
se is painful, don't do it! Check out ObjectStore.=0D=0A> Now part of Pro=
gress Software. http://www.objectstore.net/sourceforge=0D=0A> ___________=
____________________________________=0D=0A> Springframework-developer mai=
ling list=0D=0A> Spr...@li...=0D=0A> h=
ttps://lists.sourceforge.net/lists/listinfo/springframework-developer=0D=0A=
> =0D=0A> =0D=0A=0D=0A-- =0D=0AIsabelle Muszynski=0D=0ASoftware Engineer=0D=
=0AZandweellaan 4=0D=0A2660 Antwerpen=0D=0ABelgium=0D=0ATel. 32-(0)3-830 =
18 54=0D=0AMobile: 32-(0)485 49 50 89=0D=0AEmail: isa...@me...=
=0D=0AWebsite: www.meta-logix.com=0D=0A=0D=0A=0D=0A----------------------=
---------------------------------=0D=0AThis SF.net email is sponsored by:=
 ObjectStore.=0D=0AIf flattening out C++ or Java code to make your applic=
ation fit in a=0D=0Arelational database is painful, don't do it! Check ou=
t ObjectStore.=0D=0ANow part of Progress Software. http://www.objectstore=
.net/sourceforge=0D=0A_______________________________________________=0D=0A=
Springframework-developer mailing list=0D=0ASpringframework-developer@lis=
ts.sourceforge.net=0D=0Ahttps://lists.sourceforge.net/lists/listinfo/spri=
ngframework-developer=0D=0A=0A=0A********** SPECIAL ADSL **********=0AL'A=
DSL =E0 partir de 15,95 EUR/mois et le modem ADSL offert ?  C'est en excl=
usivit=E9 chez Tiscali !=0APour profiter de cette offre, cliquez ici: htt=
p://register.tiscali.fr/adsl/=0AOffre soumise =E0 conditions.=0A

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

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

What about mixing references and values in a collection? Would it look =
as follows:

<bean id=3D"foo">
 <property name=3D"moo">moo</property>
 <property name=3D"coll">
  <element refid=3D"alpha"/>
  <element refid=3D"beta"/>
  <element>gamma</element>
 </property>
</bean>

Rod's proposed syntax would be like this:

<bean id=3D"foo">
 <property name=3D"moo">moo</property>
 <property name=3D"coll">
   <ref refid=3D"alpha"/>
   <ref refid=3D"beta"/>
   <value>gamma</value>
 </property>
</bean>

I tend to prefer the latter, as it clearly separates references and =
values.

Juergen


-----Original Message-----
From: Isabelle Muszynski [mailto:isa...@me...]
Sent: Wednesday, May 28, 2003 12:33 PM
To: rod...@in...
Cc: spr...@li...
Subject: Re: [Springframework-developer] Spring bean factory XML format


HI Rod,

Do it the way JP suggested :

<bean id=3D"foo">
 <property name=3D"moo">moo</property>
 <property name=3D"coll">
  <element refid=3D"alpha">
  <element refid=3D"beta>
 </property>
</bean>

Isabelle

On Wed, May 28, 2003 at 06:17:54AM -0400, rod...@in... =
wrote:
> Isabelle,=20
>=20
> OK, we can change name -> id when defining all beans, and use=20
> refid for references.
>=20
> The only problem I see with your syntax below...
>=20
> <property name=3D"thefoo" refid=3D"foo/>
> <property name=3D"moo">moo</property>
>=20
> ...is that I can't see how it would support collections. I=20
> see this as a major enhancement, possible with the original=20
> proposal, that had <value> and <ref> subelements.
>=20
> I can easily change the XML parsing for whatever we agree.=20
>=20
> Regards,
> Rod
>=20
> > Hi Rod,
> >=20
> > There is one thing I do not like about your proposed=20
> syntax: you use <ref
> > name=3D"xxx"> is used in two different contexts, one when you=20
> define a bean
> > that can serve as a reference, and once when you refer to=20
> such a bean from
> > another bean.
> > That's confusing. It would be better to define with for ex.=20
> an id attribute,
> > and reference with a refid attribute:
> >=20
> > <bean name=3D"foo" id=3D"foo"/>
> > <bean name=3D"bar" id=3D"bar">
> >   <property name=3D"thefoo" refid=3D"foo/>
> >   <property name=3D"moo">moo</property>
> > </bean>
> > <bean name=3Dbaz>
> >   <property name=3D"bla">blabla</property>
> > </bean>
> >=20
> > Note that bean bar can in turn be referenced from other=20
> beans, thanks to its
> > id attribute. Bean baz cannot be referenced, because it=20
> doesn't have an id
> > attribute.
> >=20
> > A validating parser will not help you make sure that bean=20
> foo really exists
> > when referenced, and neither will a DTD.
> >=20
> > Isabelle
>=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
>=20
>=20

--=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


-------------------------------------------------------
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] =?iso-8859-1?Q?Re:_[Springframework-developer]_Spring_bean_factory_XML_format?=

[=?iso-8859-1?Q?<jp....@ti...>]

Hi Rod,=0D=0A=0D=0AHere comes my proposal in play, modified by Isabelle's=
 remark.=0D=0A=0D=0A<bean class=3D"MyClass" id=3D"foos" singleton=3D"fals=
e>=0D=0A<property name=3D"foo">FOO</property>=0D=0A<property name=3D"foo2=
" value=3D"FOO2"/>=0D=0A<property name=3D"foo3" refid=3D"foo3"/>=0D=0A<pr=
operty name=3D"foo4">=0D=0A    <data>FOO4.1</data>=0D=0A    <data value=3D=
"FOO4.2"/>=0D=0A    <data refid=3D"foo4.3"/>=0D=0A</property>=0D=0A</bean=
>=0D=0A<bean class=3D"MyClass2" id=3D"foo3"/>=0D=0A<bean class=3D"MyClass=
3" id=3D"foo4.3"/>=0D=0A=0D=0AI don't like very much naming the individua=
l array elements "data". If anyone has a better idea.=0D=0A=0D=0AJean-Pie=
rre=0D=0A=0D=0A---------- Initial Header -----------=0D=0A=0D=0AFrom     =
 : spr...@li...=0D=0ATo         =
 : Isabelle Muszynski <isa...@me...>=0D=0ACc          : Rod Jo=
hnson <rod...@in...>,       springframework-developer@list=
s.sourceforge.net=0D=0ADate      : Wed, 28 May 2003 06:17:54 -0400=0D=0AS=
ubject : Re: [Springframework-developer] Spring bean factory XML format=0D=
=0A=0D=0AIsabelle, =0D=0A=0D=0AOK, we can change name -> id when defining=
 all beans, and use =0D=0Arefid for references.=0D=0A=0D=0AThe only probl=
em I see with your syntax below...=0D=0A=0D=0A<property name=3D"thefoo" r=
efid=3D"foo/>=0D=0A<property name=3D"moo">moo</property>=0D=0A=0D=0A...is=
 that I can't see how it would support collections. I =0D=0Asee this as a=
 major enhancement, possible with the original =0D=0Aproposal, that had <=
value> and <ref> subelements.=0D=0A=0D=0AI can easily change the XML pars=
ing for whatever we agree. =0D=0A=0D=0ARegards,=0D=0ARod=0D=0A=0D=0A> Hi =
Rod,=0D=0A> =0D=0A> There is one thing I do not like about your proposed =
=0D=0Asyntax: you use <ref=0D=0A> name=3D"xxx"> is used in two different =
contexts, one when you =0D=0Adefine a bean=0D=0A> that can serve as a ref=
erence, and once when you refer to =0D=0Asuch a bean from=0D=0A> another =
bean.=0D=0A> That's confusing. It would be better to define with for ex. =
=0D=0Aan id attribute,=0D=0A> and reference with a refid attribute:=0D=0A=
> =0D=0A> <bean name=3D"foo" id=3D"foo"/>=0D=0A> <bean name=3D"bar" id=3D=
"bar">=0D=0A>   <property name=3D"thefoo" refid=3D"foo/>=0D=0A>   <proper=
ty name=3D"moo">moo</property>=0D=0A> </bean>=0D=0A> <bean name=3Dbaz>=0D=
=0A>   <property name=3D"bla">blabla</property>=0D=0A> </bean>=0D=0A> =0D=
=0A> Note that bean bar can in turn be referenced from other =0D=0Abeans,=
 thanks to its=0D=0A> id attribute. Bean baz cannot be referenced, becaus=
e it =0D=0Adoesn't have an id=0D=0A> attribute.=0D=0A> =0D=0A> A validati=
ng parser will not help you make sure that bean =0D=0Afoo really exists=0D=
=0A> when referenced, and neither will a DTD.=0D=0A> =0D=0A> Isabelle=0D=0A=
=0D=0A=0D=0A-------------------------------------------------------=0D=0A=
This SF.net email is sponsored by: ObjectStore.=0D=0AIf flattening out C+=
+ or Java code to make your application fit in a=0D=0Arelational database=
 is painful, don't do it! Check out ObjectStore.=0D=0ANow part of Progres=
s Software. http://www.objectstore.net/sourceforge=0D=0A_________________=
______________________________=0D=0ASpringframework-developer mailing lis=
t=0...@li...=0D=0Ahttps://lists=
.sourceforge.net/lists/listinfo/springframework-developer=0D=0A=0A=0A****=
****** SPECIAL ADSL **********=0AL'ADSL =E0 partir de 15,95 EUR/mois et l=
e modem ADSL offert ?  C'est en exclusivit=E9 chez Tiscali !=0APour profi=
ter de cette offre, cliquez ici: http://register.tiscali.fr/adsl/=0AOffre=
 soumise =E0 conditions.=0A

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

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

HI Rod,

Do it the way JP suggested :

<bean id="foo">
 <property name="moo">moo</property>
 <property name="coll">
  <element refid="alpha">
  <element refid="beta>
 </property>
</bean>

Isabelle

On Wed, May 28, 2003 at 06:17:54AM -0400, rod...@in... wrote:
> Isabelle, 
> 
> OK, we can change name -> id when defining all beans, and use 
> refid for references.
> 
> The only problem I see with your syntax below...
> 
> <property name="thefoo" refid="foo/>
> <property name="moo">moo</property>
> 
> ...is that I can't see how it would support collections. I 
> see this as a major enhancement, possible with the original 
> proposal, that had <value> and <ref> subelements.
> 
> I can easily change the XML parsing for whatever we agree. 
> 
> Regards,
> Rod
> 
> > Hi Rod,
> > 
> > There is one thing I do not like about your proposed 
> syntax: you use <ref
> > name="xxx"> is used in two different contexts, one when you 
> define a bean
> > that can serve as a reference, and once when you refer to 
> such a bean from
> > another bean.
> > That's confusing. It would be better to define with for ex. 
> an id attribute,
> > and reference with a refid attribute:
> > 
> > <bean name="foo" id="foo"/>
> > <bean name="bar" id="bar">
> >   <property name="thefoo" refid="foo/>
> >   <property name="moo">moo</property>
> > </bean>
> > <bean name=baz>
> >   <property name="bla">blabla</property>
> > </bean>
> > 
> > Note that bean bar can in turn be referenced from other 
> beans, thanks to its
> > id attribute. Bean baz cannot be referenced, because it 
> doesn't have an id
> > attribute.
> > 
> > A validating parser will not help you make sure that bean 
> foo really exists
> > when referenced, and neither will a DTD.
> > 
> > Isabelle
> 
> 
> -------------------------------------------------------
> 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

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

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

Isabelle, 

OK, we can change name -> id when defining all beans, and use 
refid for references.

The only problem I see with your syntax below...

<property name="thefoo" refid="foo/>
<property name="moo">moo</property>

...is that I can't see how it would support collections. I 
see this as a major enhancement, possible with the original 
proposal, that had <value> and <ref> subelements.

I can easily change the XML parsing for whatever we agree. 

Regards,
Rod

> Hi Rod,
> 
> There is one thing I do not like about your proposed 
syntax: you use <ref
> name="xxx"> is used in two different contexts, one when you 
define a bean
> that can serve as a reference, and once when you refer to 
such a bean from
> another bean.
> That's confusing. It would be better to define with for ex. 
an id attribute,
> and reference with a refid attribute:
> 
> <bean name="foo" id="foo"/>
> <bean name="bar" id="bar">
>   <property name="thefoo" refid="foo/>
>   <property name="moo">moo</property>
> </bean>
> <bean name=baz>
>   <property name="bla">blabla</property>
> </bean>
> 
> Note that bean bar can in turn be referenced from other 
beans, thanks to its
> id attribute. Bean baz cannot be referenced, because it 
doesn't have an id
> attribute.
> 
> A validating parser will not help you make sure that bean 
foo really exists
> when referenced, and neither will a DTD.
> 
> Isabelle

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

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

Hi Rod,

You're absolutely right, the name attribute can go away.

Isabelle

On Wed, May 28, 2003 at 09:22:04AM +0100, Rod Johnson wrote:
> Why not replace "name" attribute with "id"? Why do we need a name attribu=
te?
>=20
> ----- Original Message -----
> From: "Isabelle Muszynski" <isa...@me...>
> To: "Rod Johnson" <rod...@in...>
> Cc: <spr...@li...>
> Sent: Wednesday, May 28, 2003 8:43 AM
> Subject: Re: [Springframework-developer] Spring bean factory XML format
>=20
>=20
> Hi Rod,
>=20
> There is one thing I do not like about your proposed syntax: you use <ref
> name=3D"xxx"> is used in two different contexts, one when you define a be=
an
> that can serve as a reference, and once when you refer to such a bean from
> another bean.
> That's confusing. It would be better to define with for ex. an id attribu=
te,
> and reference with a refid attribute:
>=20
> <bean name=3D"foo" id=3D"foo"/>
> <bean name=3D"bar" id=3D"bar">
>   <property name=3D"thefoo" refid=3D"foo/>
>   <property name=3D"moo">moo</property>
> </bean>
> <bean name=3Dbaz>
>   <property name=3D"bla">blabla</property>
> </bean>
>=20
> Note that bean bar can in turn be referenced from other beans, thanks to =
its
> id attribute. Bean baz cannot be referenced, because it doesn't have an id
> attribute.
>=20
> A validating parser will not help you make sure that bean foo really exis=
ts
> when referenced, and neither will a DTD.
>=20
> Isabelle
>=20
>=20
> On Wed, May 28, 2003 at 08:16:10AM +0100, Rod Johnson wrote:
> > I've checked in the changes (backward compatible for now).  I'll tidy it
> up
> > after we decide on a definitive strategy.
> >
> > JP, thanks for your comments on the XML. The XML certainly can be chang=
ed
> at
> > this stage if we agree on an alternative.
> >
> > Regards,
> > Rod
> >
> > ----- Original Message -----
> > From: "JP Pawlak" <jp....@ti...>
> > To: "'j=C3=BCrgen h=C3=B6ller [werk3AT]'" <jue...@we...>=
; "'Rod
> > Johnson'" <rod...@in...>;
> > <spr...@li...>
> > Sent: Wednesday, May 28, 2003 7:56 AM
> > Subject: RE : [Springframework-developer] Spring bean factory XML format
> >
> >
> > Hi Rod, J=C3=BCrgen,
> >
> > I agree that formalism gains to be changed.
> > Mapping properties and CSV looked always strange.
> > We can keep compatibility, but release 0.8
> > 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 a=
nd
> > 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 sam=
e.
> 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
> >   <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 litter=
al
> > value) or a data elements collection.
> >
> >
> > Regards,
> > Jean-Pierre
> >
> >
> > > -----Message d'origine-----
> > > De : spr...@li...
> > > [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
> > >
> > >
> > > Hi Rod,
> > >
> > > 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).
> > >
> > > 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=3D"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.
> > >
> > > 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.
> > >
> > > 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?
> > >
> > > Regards,
> > > Juergen
> > >
> > >
> > >
> > > -----Urspr=C3=BCngliche Nachricht-----
> > > Von: Rod Johnson [mailto:rod...@in...]
> > > Gesendet: Di 27.05.2003 22:19
> > > An: spr...@li...
> > > Cc:
> > > Betreff: Re: [Springframework-developer] Spring bean
> > > factory XML format
> > >
> > >
> > >
> > > I've successfully prototyped this idea.
> > >
> > > The new format looks like:
> > >
> > > <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>
> > >
> > > <!--
> > > 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>
> > >
> > > <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>
> > >
> > > 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=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
> > > 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=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
> > > 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=3D"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-develo=
per
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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-develo=
per
> > >
> > >
> > > N=18HYX=E9=8A=B2un7+~V
> > > /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
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
> >
> >
>=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
>=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
>=20
>=20

--=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

[Springframework-developer] =?iso-8859-1?Q?Re:_[Springframework-developer]_Spring_bean_factory_XML_format?=

[=?iso-8859-1?Q?<jp....@ti...>]

Hi Isabelle, Rod=0D=0A=0D=0AVery good proposal from Isabelle and Rod's an=
swer. Replacing "name" by "id" and "ref" by "refid" will simplify the fut=
ure DTD checking.=0D=0A=0D=0AJean-Pierre=0D=0A=0D=0A---------- Initial He=
ader -----------=0D=0A=0D=0AFrom      : springframework-developer-admin@l=
ists.sourceforge.net=0D=0ATo          : "Isabelle Muszynski" <isabelle@me=
ta-logix.com>=0D=0ACc          : <spr...@li...=
orge.net>=0D=0ADate      : Wed, 28 May 2003 09:22:04 +0100=0D=0ASubject :=
 Re: [Springframework-developer] Spring bean factory XML format=0D=0A=0D=0A=
Why not replace "name" attribute with "id"? Why do we need a name attribu=
te?=0D=0A=0D=0A----- Original Message -----=0D=0AFrom: "Isabelle Muszynsk=
i" <isa...@me...>=0D=0ATo: "Rod Johnson" <rod.johnson@interfac=
e21.com>=0D=0ACc: <spr...@li...>=0D=0A=
Sent: Wednesday, May 28, 2003 8:43 AM=0D=0ASubject: Re: [Springframework-=
developer] Spring bean factory XML format=0D=0A=0D=0A=0D=0AHi Rod,=0D=0A=0D=
=0AThere is one thing I do not like about your proposed syntax: you use <=
ref=0D=0Aname=3D"xxx"> is used in two different contexts, one when you de=
fine a bean=0D=0Athat can serve as a reference, and once when you refer t=
o such a bean from=0D=0Aanother bean.=0D=0AThat's confusing. It would be =
better to define with for ex. an id attribute,=0D=0Aand reference with a =
refid attribute:=0D=0A=0D=0A<bean name=3D"foo" id=3D"foo"/>=0D=0A<bean na=
me=3D"bar" id=3D"bar">=0D=0A  <property name=3D"thefoo" refid=3D"foo/>=0D=
=0A  <property name=3D"moo">moo</property>=0D=0A</bean>=0D=0A<bean name=3D=
baz>=0D=0A  <property name=3D"bla">blabla</property>=0D=0A</bean>=0D=0A=0D=
=0ANote that bean bar can in turn be referenced from other beans, thanks =
to its=0D=0Aid attribute. Bean baz cannot be referenced, because it doesn=
't have an id=0D=0Aattribute.=0D=0A=0D=0AA validating parser will not hel=
p you make sure that bean foo really exists=0D=0Awhen referenced, and nei=
ther will a DTD.=0D=0A=0D=0AIsabelle=0D=0A=0D=0A=0D=0AOn Wed, May 28, 200=
3 at 08:16:10AM +0100, Rod Johnson wrote:=0D=0A> I've checked in the chan=
ges (backward compatible for now).  I'll tidy it=0D=0Aup=0D=0A> after we =
decide on a definitive strategy.=0D=0A>=0D=0A> JP, thanks for your commen=
ts on the XML. The XML certainly can be changed=0D=0Aat=0D=0A> this stage=
 if we agree on an alternative.=0D=0A>=0D=0A> Regards,=0D=0A> Rod=0D=0A>=0D=
=0A> ----- Original Message -----=0D=0A> From: "JP Pawlak" <jp.pawlak@tis=
cali.fr>=0D=0A> To: "'j=C3=BCrgen h=C3=B6ller [werk3AT]'" <juergen.hoelle=
r...@we...>; "'Rod=0D=0A> Johnson'" <rod...@in...>;=0D=0A=
> <spr...@li...>=0D=0A> Sent: Wednesda=
y, May 28, 2003 7:56 AM=0D=0A> Subject: RE : [Springframework-developer] =
Spring bean factory XML format=0D=0A>=0D=0A>=0D=0A> Hi Rod, J=C3=BCrgen,=0D=
=0A>=0D=0A> I agree that formalism gains to be changed.=0D=0A> Mapping pr=
operties and CSV looked always strange.=0D=0A> We can keep compatibility,=
 but release 0.8=0D=0A> before fixing the new one would be a bad beginnin=
g.=0D=0A>=0D=0A> I'm not an XML expert, but worked with. I have some rema=
rks:=0D=0A>=0D=0A> First, attributes "name", "class" and "singleton" are =
straightforward and=0D=0A> clean.=0D=0A> The "beanref" as a boolean had p=
oor value and changed the meaning of the=0D=0A> body! Avoiding this will =
be safer.=0D=0A> The main isuue is with organizing the "value" part.=0D=0A=
>=0D=0A> Single values:=0D=0A> If anything is allowed in the body, the me=
aning shall always be the same.=0D=0AWe=0D=0A> can consider it will be th=
e litteral value.=0D=0A> My proposition will be:=0D=0A>   <property name=3D=
"xxx">yyy</bean>=0D=0A> An alternative could be accepted:=0D=0A>   <prope=
rty name=3D"xxx" value=3D"yyy"/>=0D=0A>=0D=0A> If the unique value is a b=
ean reference, the body has to be empty:=0D=0A>   <property name=3D"xxx" =
ref=3D"zzz"/>=0D=0A>=0D=0A> Multiple values:=0D=0A> I don't like=0D=0A>  =
 <property name=3D"jumble">=0D=0A>      <ref name=3D"david"/>=0D=0A>     =
 <value>literal</value>=0D=0A>      <ref name=3D"jenny" />=0D=0A>   </pro=
perty>=0D=0A>=0D=0A> The ref name=3D"xxx" has a poor value, we have two e=
ntities for only one=0D=0A> information.=0D=0A>=0D=0A> Because of differe=
nt tag names. "ref" and "value" are both data in the=0D=0A> collection.=0D=
=0A> I prefer such as:=0D=0A>   <property name=3D"jumble">=0D=0A>      <d=
ata ref=3D"david"/>=0D=0A>      <data value=3D"literal"/>=0D=0A>      <da=
ta>literal2</data>=0D=0A>      <data ref=3D"jenny" />=0D=0A>   </property=
>=0D=0A>=0D=0A> The "data" element could have a better name.=0D=0A>=0D=0A=
> So we could have a consistent definition, both in property and data:=0D=
=0A> The value is either the body either the value attribute.=0D=0A> The =
bean reference is always the ref attribute.=0D=0A>=0D=0A> The property el=
ement could only have in its body a text(the sole litteral=0D=0A> value) =
or a data elements collection.=0D=0A>=0D=0A>=0D=0A> Regards,=0D=0A> Jean-=
Pierre=0D=0A>=0D=0A>=0D=0A> > -----Message d'origine-----=0D=0A> > De : s=
pri...@li...=0D=0A> > [mailto:spr=
ing...@li...]=0D=0A> >  De la part =
de j=C3=BCrgen h=C3=B6ller [werk3AT]=0D=0A> > Envoy=C3=A9 : mercredi 28 m=
ai 2003 07:33=0D=0A> > =C3=80 : Rod Johnson; springframework-developer@li=
sts.sourceforge.net=0D=0A> > Objet : Re: [Springframework-developer] Spri=
ng bean factory XML format=0D=0A> >=0D=0A> >=0D=0A> > Hi Rod,=0D=0A> >=0D=
=0A> > I agree that the new format makes sense. I didn't think about=0D=0A=
> > validating the XML before, but to my understanding you're=0D=0A> > ri=
ght about the pitfalls. Keeping backwards compatibility for=0D=0A> > the =
moment makes sense, as each and every application context=0D=0A> > defini=
tion will be affected (admittedly in a straightforward way).=0D=0A> >=0D=0A=
> > So besides the <ref> tag, there's a <value> tag now, for=0D=0A> > mix=
ed collections. I guess it can also be used with a single=0D=0A> > value =
property like this:=0D=0A> >=0D=0A> > <property name=3D"name"><value>Rod<=
/value></property>=0D=0A> >=0D=0A> > Do you recommend this syntax for suc=
h properties too? Does it=0D=0A> > add any value in terms of validation? =
We should definitely=0D=0A> > stick to one recommended syntax, to avoid c=
onfusion.=0D=0A> >=0D=0A> > Regarding beans that expose CSV properties: I=
've already=0D=0A> > tried to clean many of the exposed bean properties w=
ithin=0D=0A> > Spring (e.g. both commandClass and commandClassName, now o=
nly=0D=0A> > the former because of the ClassEditor), we should try to=0D=0A=
> > continue this for multiple value properties. I guess if=0D=0A> > choi=
ce doesn't add real value, it rather causes confusion.=0D=0A> >=0D=0A> > =
I'm not an XML expert, so I can't really help in terms of=0D=0A> > furthe=
r improvements. Does anyone else have some thoughts on this?=0D=0A> >=0D=0A=
> > Regards,=0D=0A> > Juergen=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> > -----Ur=
spr=C3=BCngliche Nachricht-----=0D=0A> > Von: Rod Johnson [mailto:rod.joh=
ns...@in...]=0D=0A> > Gesendet: Di 27.05.2003 22:19=0D=0A> > An:=
 spr...@li...=0D=0A> > Cc:=0D=0A> > Be=
treff: Re: [Springframework-developer] Spring bean=0D=0A> > factory XML f=
ormat=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> > I've successfully prototyped th=
is idea.=0D=0A> >=0D=0A> > The new format looks like:=0D=0A> >=0D=0A> > <=
bean name=3D"rod" class=3D"com.interface21.beans.TestBean">=0D=0A> > <pro=
perty name=3D"name">Rod</property>=0D=0A> > <property name=3D"age">32</pr=
operty>=0D=0A> > <property name=3D"friends">=0D=0A> >   <ref name=3D"jenn=
y"/>=0D=0A> >   <ref name=3D"david"/>=0D=0A> > </property>=0D=0A> > </bea=
n>=0D=0A> >=0D=0A> > <!--=0D=0A> > Try setting a collection property to a=
 single value=0D=0A> > -->=0D=0A> > <bean name=3D"loner" class=3D"com.int=
erface21.beans.TestBean">=0D=0A> > <property name=3D"name">loner</propert=
y>=0D=0A> > <property name=3D"age">26</property>=0D=0A> > <property name=3D=
"friends">=0D=0A> >   <ref name=3D"david"/>=0D=0A> > </property>=0D=0A> >=
 </bean>=0D=0A> >=0D=0A> > <bean name=3D"jumble"=0D=0A> > class=3D"com.in=
terface21.beans.factory.xml.MixedCollectionBean">=0D=0A> > <property name=
=3D"jumble">=0D=0A> >    <ref name=3D"david"/>=0D=0A> >    <value>literal=
</value>=0D=0A> >    <ref name=3D"jenny" />=0D=0A> > </property>=0D=0A> >=
 </bean>=0D=0A> >=0D=0A> > I haven't dropped backward compatibility, or c=
hecked=0D=0A> > anything in.=0D=0A> >=0D=0A> > If we agree this is an imp=
rovement, I'll check in these=0D=0A> > changes this week. I=0D=0A> > gues=
s I don't need to drop backward compatibility right=0D=0A> > now (beanRef=
), but=0D=0A> > I think it should be dropped before 1.0.=0D=0A> >=0D=0A> =
> I'm open to suggestions as to how to improve the XML further.=0D=0A> >=0D=
=0A> > Regards,=0D=0A> > Rod=0D=0A> >=0D=0A> > ----- Original Message ---=
--=0D=0A> > From: "Rod Johnson" <rod...@in...>=0D=0A> > To=
: <spr...@li...>=0D=0A> > Sent: Tuesda=
y, May 27, 2003 6:20 PM=0D=0A> > Subject: [Springframework-developer] Spr=
ing bean=0D=0A> > factory XML format=0D=0A> >=0D=0A> >=0D=0A> > > Guys,=0D=
=0A> > >=0D=0A> > > I've just been thinking about an important potential =
issue.=0D=0A> > >=0D=0A> > > The current XML bean-reference syntax looks =
like:=0D=0A> > > <property name=3D"foo" beanRef=3D"true">myFooBean</prope=
rty>=0D=0A> > >=0D=0A> > > and, for lists etc (where a bean exposes a "CS=
V" property)=0D=0A> > > <property name=3D"foos">a,b,c</property>=0D=0A> >=
 >=0D=0A> > > While this syntax is concise, I think there are some=0D=0A>=
 > issues we should=0D=0A> > > discuss.=0D=0A> > >=0D=0A> > > a. It's har=
d to validate this. There's no validatable=0D=0A> > reference to another=0D=
=0A> > > bean element id. It would be great if an XML editor=0D=0A> > cou=
ld help us in this=0D=0A> > > regard.=0D=0A> > > b. It's inelegant. The u=
se of the CDATA in the=0D=0A> > property element as a=0D=0A> > string=0D=0A=
> > > value or a reference (depending on the presence of an=0D=0A> > attr=
ibute) is a bit=0D=0A> > > messy.=0D=0A> > > c. The CSV format is really =
a hack, that I used once=0D=0A> > and then reused. Not=0D=0A> > > only do=
es the CSV make no sense to an XML editor=0D=0A> > (analogous to putting =
CSV=0D=0A> > > data in an RDBMS), it places the onus on each class=0D=0A>=
 > to parse the CSV and=0D=0A> > > look up the necessary beans. This make=
s classes=0D=0A> > exposing CSV properties=0D=0A> > > dependent on the ow=
ning BeanFactory, lessening the=0D=0A> > value of Spring's=0D=0A> > > tra=
nsparence. (Admittedly this is concealed in=0D=0A> > framework classes, s=
o it=0D=0A> > > doesn't really affect developers.) With the proposed=0D=0A=
> > new way, any=0D=0A> > > application code could benefit from collectio=
n &=0D=0A> > array support.=0D=0A> > > d. The new way would make it easy =
to write XSLT that=0D=0A> > showed relationships=0D=0A> > > among Spring =
beans. This could be handy for=0D=0A> > generating documentation about=0D=
=0A> > > Spring apps.=0D=0A> > >=0D=0A> > > So I've been thinking of chan=
ges along the lines of:=0D=0A> > >=0D=0A> > > <property name=3D"foo">=0D=0A=
> > >     <ref name=3D"myFooBean" />=0D=0A> > > </property>=0D=0A> > >=0D=
=0A> > > and=0D=0A> > >=0D=0A> > > <property name=3D"foos">=0D=0A> > >   =
  <ref name=3D"a" />=0D=0A> > >     <ref name=3D"b"/>=0D=0A> > >     <ref=
 name=3D"c"/>=0D=0A> > > </property>=0D=0A> > >=0D=0A> > > In this case t=
he foos bean class would expose a=0D=0A> > Collection or array=0D=0A> > >=
 property, and the bean factory would no how to=0D=0A> > populate that fr=
om the=0D=0A> > > runtime references. No dependence on the fw even for=0D=
=0A> > managing collection=0D=0A> > > properties.=0D=0A> > >=0D=0A> > > I=
've already prototyped the idea of a <ref>=0D=0A> > subelement, and that =
was=0D=0A> > pretty=0D=0A> > > simple to implement.  I'll experiment with=
=0D=0A> > collections tonight.=0D=0A> > >=0D=0A> > > Apart from changing =
XML files, the flow-on effect=0D=0A> > would mean that anything=0D=0A> > =
> that exposed a CSV property (like the AOP interceptor=0D=0A> > proxy) w=
ould change=0D=0A> > to=0D=0A> > > exposing a Collection or array.=0D=0A>=
 > >=0D=0A> > > What do you think? I'd like thoughts on the following=0D=0A=
> > questions:=0D=0A> > >=0D=0A> > > 1. Does everyone agree that this is =
worth doing?=0D=0A> > >=0D=0A> > > 2. To support a collection including l=
iteral values,=0D=0A> > should we introduce a=0D=0A> > > new <value> elem=
ent, meaning that simple properties=0D=0A> > would become=0D=0A> > > <pro=
perty name=3D"foo"><value>canConvert this=0D=0A> > string</value></proper=
ty>.=0D=0A> > More=0D=0A> > > verbose, but more elegant.=0D=0A> > >=0D=0A=
> > > 3. Is there a way to help XML enforce the references=0D=0A> > autom=
atically? E.g.=0D=0A> > > change bean "name" to "id" and use a <href> ins=
tead=0D=0A> > of a <ref>? I haven't=0D=0A> > > had a chance to explore th=
is yet, but hopefully=0D=0A> > someone knows XML better=0D=0A> > > than I=
 do.=0D=0A> > >=0D=0A> > > 4. If this is worth doing, should we do it in =
0.8,=0D=0A> > even if it delays the=0D=0A> > > release  (as it would)? On=
 the one hand, we should=0D=0A> > try to release ASAP. On=0D=0A> > > the =
other hand, this change would break all existing=0D=0A> > applications. E=
ven=0D=0A> > > though they'd be easy to fix, it might irritate=0D=0A> > u=
sers. So the choice is:=0D=0A> > > - release now with a likely incompatib=
le change in store=0D=0A> > > - accept a delay=0D=0A> > >=0D=0A> > > We'd=
 also have to introduce analogous support for the=0D=0A> > properties for=
mat,=0D=0A> > > which couldn't benefit from XML capabilities. The=0D=0A> =
> properties format would=0D=0A> > > probably change very little.=0D=0A> =
> >=0D=0A> > > Regards,=0D=0A> > > Rod=0D=0A> > >=0D=0A> > >=0D=0A> > >=0D=
=0A> > >=0D=0A> > > -----------------------------------------------------=
--=0D=0A> > > This SF.net email is sponsored by: ObjectStore.=0D=0A> > > =
If flattening out C++ or Java code to make your=0D=0A> > application fit =
in a=0D=0A> > > relational database is painful, don't do it! Check=0D=0A>=
 > out ObjectStore.=0D=0A> > > Now part of Progress Software.=0D=0A> > ht=
tp://www.objectstore.net/sourceforge=0D=0A> > >=0D=0A> > ________________=
_______________________________=0D=0A> > > Springframework-developer mail=
ing list=0D=0A> > > Spr...@li...=0D=0A=
> > >=0D=0A> > > https://lists.sourceforge.net/lists/listinfo/springframe=
work-developer=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> > -------------=
------------------------------------------=0D=0A> > This SF.net email is =
sponsored by: ObjectStore.=0D=0A> > If flattening out C++ or Java code to=
 make your=0D=0A> > application fit in a=0D=0A> > relational database is =
painful, don't do it! Check out=0D=0A> > ObjectStore.=0D=0A> > Now part o=
f Progress Software.=0D=0A> > http://www.objectstore.net/sourceforge=0D=0A=
> >=0D=0A> > _______________________________________________=0D=0A> > Spr=
ingframework-developer mailing list=0D=0A> > Springframework-developer@li=
sts.sourceforge.net=0D=0A> >=0D=0A> > > https://lists.sourceforge.net/lis=
ts/listinfo/springframework-developer=0D=0A> >=0D=0A> >=0D=0A> > N=18HYX=E9=
=8A=B2un7+~V=0D=0A> > /u=EB=99=A9=CA=8Bj=C6=8Aj=D8=B7j=D8=9Djj vv=0D=0A> =
> =17=E8=92=8B9r=D4=A2=0D=0A> > >=DA=BAJ   y=CB=B6=EB=B2=8Bq =E7=AE=A6 G =
j) =D4=AE)~{=0D=0A> > zZz=D7=B9=DB=A2y =1B=E9=B6=A6=CF=96+=CA=AD=C7=A2+=EB=
=96=B3 ~ G=0D=0A> >=0D=0A>=0D=0A>=0D=0A>=0D=0A>=0D=0A> ------------------=
-------------------------------------=0D=0A> This SF.net email is sponsor=
ed by: ObjectStore.=0D=0A> If flattening out C++ or Java code to make you=
r application fit in a=0D=0A> relational database is painful, don't do it=
! Check out ObjectStore.=0D=0A> Now part of Progress Software. http://www=
.objectstore.net/sourceforge=0D=0A> _____________________________________=
__________=0D=0A> Springframework-developer mailing list=0D=0A> Springfra=
mew...@li...=0D=0A> https://lists.sourceforge.n=
et/lists/listinfo/springframework-developer=0D=0A>=0D=0A>=0D=0A>=0D=0A>=0D=
=0A> -------------------------------------------------------=0D=0A> This =
SF.net email is sponsored by: ObjectStore.=0D=0A> If flattening out C++ o=
r Java code to make your application fit in a=0D=0A> relational database =
is painful, don't do it! Check out ObjectStore.=0D=0A> Now part of Progre=
ss Software. http://www.objectstore.net/sourceforge=0D=0A> ______________=
_________________________________=0D=0A> Springframework-developer mailin=
g list=0D=0A> Spr...@li...=0D=0A> http=
s://lists.sourceforge.net/lists/listinfo/springframework-developer=0D=0A>=
=0D=0A>=0D=0A=0D=0A--=0D=0AIsabelle Muszynski=0D=0ASoftware Engineer=0D=0A=
Zandweellaan 4=0D=0A2660 Antwerpen=0D=0ABelgium=0D=0ATel. 32-(0)3-830 18 =
54=0D=0AMobile: 32-(0)485 49 50 89=0D=0AEmail: isa...@me...=0D=
=0AWebsite: www.meta-logix.com=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A-------------=
------------------------------------------=0D=0AThis SF.net email is spon=
sored by: ObjectStore.=0D=0AIf flattening out C++ or Java code to make yo=
ur application fit in a=0D=0Arelational database is painful, don't do it!=
 Check out ObjectStore.=0D=0ANow part of Progress Software. http://www.ob=
jectstore.net/sourceforge=0D=0A__________________________________________=
_____=0D=0ASpringframework-developer mailing list=0D=0ASpringframework-de=
ve...@li...=0D=0Ahttps://lists.sourceforge.net/lists/li=
stinfo/springframework-developer=0D=0A=0A=0A********** SPECIAL ADSL *****=
*****=0AL'ADSL =E0 partir de 15,95 EUR/mois et le modem ADSL offert ?  C'=
est en exclusivit=E9 chez Tiscali !=0APour profiter de cette offre, cliqu=
ez ici: http://register.tiscali.fr/adsl/=0AOffre soumise =E0 conditions.=0A=

[Springframework-developer] Hibernate setup in an ApplicationContext

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

After the general DataSource ones, some notes on Hibernate setup:

For the non-JCA case, I would not access Hibernate's SessionFactory via =
JNDI (natural with JCA), as you'll have to fight with binding to the =
container's JNDI tree then. For example, Tomcat has a read-only JNDI =
tree - no custom binding there. Spring's LocalSessionFactoryBean allows =
for convenient setup of non-JNDI session factories, giving bean =
references to HibernateTransactionManager, HibernateTemplate, or custom =
beans (just like a JndiObjectFactoryBean would too).

Hibernate supports a number of connection providers. As it doesn't =
export the DataSource it uses, you'll have to use a JNDI one to be able =
to share the DataSource. In a Spring application, you can define a =
JndiObjectFactoryBean that takes the DataSource from the same JNDI =
location, to be able to access the same database via the same pool. =
There is no way to enforce the equality, so you'll have to care yourself =
that the respective hibernate.cfg.xml and your JndiObjectFactoryBean =
definition match.

To support transactions spanning both Hibernate Sessions and plain JDBC =
access to the same DataSource, HibernateTransactionManager has a =
dataSource property that should be given the same DataSource reference =
(e.g. from a JndiObjectFactoryBean). It will export a transaction's JDBC =
connection for the specified DataSource then, just like =
DataSourceTransactionManager. Note that this doesn't involve JTA, thus =
no container-specific Hibernate JCA Connector setup - it even works in =
Tomcat. And in contrast to JTA, you can specify the isolation level per =
transaction.

Hibernate's transactional caching is a special issue: It's a hassle when =
using JTA without JCA because of the container-specific =
TransactionManager lookup, but it works nicely with =
HibernateTransactionManager. Thus, I wouldn't recommend =
JtaTransactionManager for accessing a single database via Hibernate =
and/or plain JDBC code from within Spring. HibernateTransactionManager, =
or DataSourceTransactionManager for plain JDBC only, gives the same =
level of convenience (+ custom isolation levels) without the =
container-specific hassle.

Note that we will try to provide similar support for JDO. We won't be =
able to export a JDO transaction's JDBC connection though (for =
transactions spanning plain JDBC access), or specify the isolation level =
per transaction. This is a consequence of JDO being datastore-agnostic, =
not assuming JDBC underneath. We would need to depend on a specific JDO =
implementation for such features.

Finally, if anyone has specific requirements or experiences in terms of =
datastore setup, feedback on our Hibernate support, or actual plans of =
using JDO - let me know! :-)=20

Juergen


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] Spring bean factory XML format

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

Why not replace "name" attribute with "id"? Why do we need a name attribute?

----- Original Message -----
From: "Isabelle Muszynski" <isa...@me...>
To: "Rod Johnson" <rod...@in...>
Cc: <spr...@li...>
Sent: Wednesday, May 28, 2003 8:43 AM
Subject: Re: [Springframework-developer] Spring bean factory XML format


Hi Rod,

There is one thing I do not like about your proposed syntax: you use <ref
name="xxx"> is used in two different contexts, one when you define a bean
that can serve as a reference, and once when you refer to such a bean from
another bean.
That's confusing. It would be better to define with for ex. an id attribute,
and reference with a refid attribute:

<bean name="foo" id="foo"/>
<bean name="bar" id="bar">
  <property name="thefoo" refid="foo/>
  <property name="moo">moo</property>
</bean>
<bean name=baz>
  <property name="bla">blabla</property>
</bean>

Note that bean bar can in turn be referenced from other beans, thanks to its
id attribute. Bean baz cannot be referenced, because it doesn't have an id
attribute.

A validating parser will not help you make sure that bean foo really exists
when referenced, and neither will a DTD.

Isabelle


On Wed, May 28, 2003 at 08:16:10AM +0100, Rod Johnson wrote:
> I've checked in the changes (backward compatible for now).  I'll tidy it
up
> after we decide on a definitive strategy.
>
> JP, thanks for your comments on the XML. The XML certainly can be changed
at
> this stage if we agree on an alternative.
>
> Regards,
> Rod
>
> ----- Original Message -----
> From: "JP Pawlak" <jp....@ti...>
> To: "'jürgen höller [werk3AT]'" <jue...@we...>; "'Rod
> Johnson'" <rod...@in...>;
> <spr...@li...>
> Sent: Wednesday, May 28, 2003 7:56 AM
> Subject: RE : [Springframework-developer] Spring bean factory XML format
>
>
> Hi Rod, Jürgen,
>
> I agree that formalism gains to be changed.
> Mapping properties and CSV looked always strange.
> We can keep compatibility, but release 0.8
> 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="xxx">yyy</bean>
> An alternative could be accepted:
>   <property name="xxx" value="yyy"/>
>
> If the unique value is a bean reference, the body has to be empty:
>   <property name="xxx" ref="zzz"/>
>
> Multiple values:
> I don't like
>   <property name="jumble">
>      <ref name="david"/>
>      <value>literal</value>
>      <ref name="jenny" />
>   </property>
>
> The ref name="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="jumble">
>      <data ref="david"/>
>      <data value="literal"/>
>      <data>literal2</data>
>      <data ref="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...
> > [mailto:spr...@li...]
> >  De la part de jürgen höller [werk3AT]
> > Envoyé : mercredi 28 mai 2003 07:33
> > À : Rod Johnson; spr...@li...
> > Objet : Re: [Springframework-developer] Spring bean factory XML format
> >
> >
> > Hi Rod,
> >
> > 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).
> >
> > 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.
> >
> > 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.
> >
> > 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?
> >
> > Regards,
> > Juergen
> >
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Rod Johnson [mailto:rod...@in...]
> > Gesendet: Di 27.05.2003 22:19
> > An: spr...@li...
> > Cc:
> > Betreff: Re: [Springframework-developer] Spring bean
> > factory XML format
> >
> >
> >
> > 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
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
> >
> >
> > NHYX銲un7+~V
> > /u뙩ʋjƊjطj؝jj vv
> > 蒋9rԢ
> > >ںJ   y˶벋q 箦 G j) Ԯ)~{
> > zZz׹ۢy 鶦ϖ+ʭǢ+떳 ~ G
> >
>
>
>
>
> -------------------------------------------------------
> 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
>
>

--
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] Spring bean factory XML format

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

Hi Rod,

There is one thing I do not like about your proposed syntax: you use <ref n=
ame=3D"xxx"> is used in two different contexts, one when you define a bean =
that can serve as a reference, and once when you refer to such a bean from =
another bean.
That's confusing. It would be better to define with for ex. an id attribute=
, and reference with a refid attribute:

<bean name=3D"foo" id=3D"foo"/>
<bean name=3D"bar" id=3D"bar">
  <property name=3D"thefoo" refid=3D"foo/>
  <property name=3D"moo">moo</property>
</bean>
<bean name=3Dbaz>
  <property name=3D"bla">blabla</property>
</bean>

Note that bean bar can in turn be referenced from other beans, thanks to it=
s id attribute. Bean baz cannot be referenced, because it doesn't have an i=
d attribute.

A validating parser will not help you make sure that bean foo really exists=
 when referenced, and neither will a DTD.

Isabelle


On Wed, May 28, 2003 at 08:16:10AM +0100, Rod Johnson wrote:
> I've checked in the changes (backward compatible for now).  I'll tidy it =
up
> after we decide on a definitive strategy.
>=20
> JP, thanks for your comments on the XML. The XML certainly can be changed=
 at
> this stage if we agree on an alternative.
>=20
> Regards,
> Rod
>=20
> ----- Original Message -----
> From: "JP Pawlak" <jp....@ti...>
> To: "'j=C3=BCrgen h=C3=B6ller [werk3AT]'" <jue...@we...>; =
"'Rod
> Johnson'" <rod...@in...>;
> <spr...@li...>
> Sent: Wednesday, May 28, 2003 7:56 AM
> Subject: RE : [Springframework-developer] Spring bean factory XML format
>=20
>=20
> Hi Rod, J=C3=BCrgen,
>=20
> I agree that formalism gains to be changed.
> Mapping properties and CSV looked always strange.
> We can keep compatibility, but release 0.8
> before fixing the new one would be a bad beginning.
>=20
> I'm not an XML expert, but worked with. I have some remarks:
>=20
> 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.
>=20
> 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"/>
>=20
> If the unique value is a bean reference, the body has to be empty:
>   <property name=3D"xxx" ref=3D"zzz"/>
>=20
> Multiple values:
> I don't like
>   <property name=3D"jumble">
>      <ref name=3D"david"/>
>      <value>literal</value>
>      <ref name=3D"jenny" />
>   </property>
>=20
> The ref name=3D"xxx" has a poor value, we have two entities for only one
> information.
>=20
> 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>
>=20
> The "data" element could have a better name.
>=20
> 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.
>=20
> The property element could only have in its body a text(the sole litteral
> value) or a data elements collection.
>=20
>=20
> Regards,
> Jean-Pierre
>=20
>=20
> > -----Message d'origine-----
> > De : spr...@li...
> > [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
> >
> >
> > Hi Rod,
> >
> > 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).
> >
> > 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=3D"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.
> >
> > 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.
> >
> > 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?
> >
> > Regards,
> > Juergen
> >
> >
> >
> > -----Urspr=C3=BCngliche Nachricht-----
> > Von: Rod Johnson [mailto:rod...@in...]
> > Gesendet: Di 27.05.2003 22:19
> > An: spr...@li...
> > Cc:
> > Betreff: Re: [Springframework-developer] Spring bean
> > factory XML format
> >
> >
> >
> > I've successfully prototyped this idea.
> >
> > The new format looks like:
> >
> > <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>
> >
> > <!--
> > 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>
> >
> > <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>
> >
> > 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=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
> > 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=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
> > 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=3D"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
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
> >
> >
> > N=18HYX=E9=8A=B2un7+~V
> > /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
>=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
>=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
>=20
>=20

--=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

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

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

T25lIG1vcmUgZmVhdHVyZTogSXQncyBlYXN5IHRvIG92ZXJyaWRlIHRoZSBkYXRhYmFzZSBzZXR0
aW5ncyB3aXRoIGEgcHJvcGVydGllcyBmaWxlLg0KDQpJZiB5b3UgZGVmaW5lIGEgUHJvcGVydHlS
ZXNvdXJjZUNvbmZpZ3VyZXIsIHlvdSdsbCBvdmVycmlkZSBhbnkgYXBwbGljYXRpb25Db250ZXh0
LnhtbCBzZXR0aW5ncyB3aXRoIHRoZSBkZWZpbml0aW9ucyBpbiB0aGUgcmVzcGVjdGl2ZSBwcm9w
ZXJ0aWVzIGZpbGUuIFRoaXMgaXMgbWFpbmx5IHRhcmdldHRlZCBhdCBoaWRpbmcgZXZlcnl0aGlu
ZyBidXQgYSBmZXcgc2V0dGluZ3MgZnJvbSBzeXN0ZW0gYWRtaW5pc3RyYXRvcnMuIEFuIGFkbWlu
IHNob3VsZCBzb2xlbHkgaGF2ZSB0byB0b3VjaCBhIGZpbGUgbGlrZSBhZG1pbi5wcm9wZXJ0aWVz
LCBuZXZlciBhcHBsaWNhdGlvbkNvbnRleHQueG1sLg0KDQpBbiBleGFtcGxlIFByb3BlcnR5UmVz
b3VyY2VDb25maWd1cmVyIGRlZmluaXRpb246DQoNCgk8YmVhbiBuYW1lPSJhZG1pbkNvbmZpZyIg
Y2xhc3M9ImNvbS5pbnRlcmZhY2UyMS5jb250ZXh0LnN1cHBvcnQuUHJvcGVydHlSZXNvdXJjZUNv
bmZpZ3VyZXIiPg0KCQk8cHJvcGVydHkgbmFtZT0ibG9jYXRpb24iPldFQi1JTkYvYWRtaW4ucHJv
cGVydGllczwvcHJvcGVydHk+DQoJPC9iZWFuPg0KDQpUaGUgYWRtaW4ucHJvcGVydGllcyBmaWxl
IGNhbiBjb250YWluIGFueSBudW1iZXIgb2YgbGluZXMgd2l0aCBiZWFuTmFtZS5wcm9wZXJ0eT12
YWx1ZSBzeW50YXgsIGxpa2U6DQoNCglkYXRhU291cmNlLnVybD1qZGJjOm15c3FsOi8vbG9jYWxo
b3N0OjMzMDYvY2J4X2JhY2t1cA0KDQpUaGlzIHdpbGwgb2J2aW91c2x5IHdvcmsgd2l0aCBhbnkg
ZGF0YVNvdXJjZSBkZWZpbml0aW9uIGV4Y2VwdCB0aGUgSk5ESSBvbmUuIE5vdGUgdGhhdCB1c2lu
ZyBtdWx0aXBsZSBEYXRhU291cmNlcyBzaW1wbHkgbWVhbnMgZGVmaW5pbmcgbXVsdGlwbGUgb25l
cyBpbiBhcHBsaWNhdGlvbkNvbnRleHQueG1sLCBnaXZpbmcgdGhlIHVuaXF1ZSBiZWFuIG5hbWVz
IQ0KDQpCVFcsIEkndmUganVzdCBuYW1lZCB0aGUgRHJpdmVyTWFuYWdlckRhdGFTb3VyY2UgKGFu
ZCB0aHVzIFNpbmdsZUNvbm5lY3Rpb25EYXRhU291cmNlKSBwcm9wZXJ0aWVzIGFjY29yZGluZyB0
byB0aGUgQ29tbW9ucyBEQkNQIG9uZXMsIHRvIGF2b2lkIGNvbmZ1c2lvbi4gSXQncyBub3cgImRy
aXZlckNsYXNzTmFtZSIgYW5kICJ1c2VybmFtZSIgd2l0aCBhbnkgb2YgdGhlIDMuDQoNCkp1ZXJn
ZW4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogasO8cmdlbiBow7ZsbGVy
IFt3ZXJrM0FUXSANClNlbnQ6IFR1ZXNkYXksIE1heSAyNywgMjAwMyAxMDoxOSBQTQ0KVG86IHNw
cmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQpTdWJqZWN0OiBS
ZTogW1NwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJdIERhdGFTb3VyY2Ugc2V0dXAgaW4gYW4NCkFw
cGxpY2F0aW9uQ29udGV4dA0KDQoNClRoZSBwcmV2aW91cyBtYWlsIGFzc3VtZXMgdGhhdCB5b3Ug
cHJvdmlkZSBzcGVjaWFsIGFwcGxpY2F0aW9uQ29udGV4dC54bWwgZmlsZXMgZm9yIHRlc3Qgb3Ig
c3RhbmRhbG9uZSBlbnZpcm9ubWVudHMsIHdpdGggYWx0ZXJuYXRlIGRhdGFTb3VyY2UgZGVmaW5p
dGlvbnMuIFRoaXMgYWxsb3dzIGZvciBjb252ZW5pZW50IGNvbmZpZ3VyYXRpb24gdmlhIHRoZSBi
ZWFuIGZhY3RvcnkuDQogDQpBbiBhbHRlcm5hdGl2ZSB3YXkgaXMgdG8gc2V0IHVwIGEgbW9jayBK
TkRJIGVudmlyb25tZW50IChjb20uaW50ZXJmYWNlMjEuam5kaS5tb2NrKS4gVGhlIGV4YWN0bHkg
c2FtZSBhcHBsaWNhdGlvbkNvbnRleHQueG1sIGZpbGUgbGlrZSB3aXRoaW4gYSBKMkVFIGNvbnRh
aW5lciBjYW4gYmUgdXNlZCB0aGVuIChpbmNsdWRpbmcgYSBKbmRpT2JqZWN0RmFjdG9yeUJlYW4g
ZGVmaW5pdGlvbiksIGlmIGEgRGF0YVNvdXJjZSBsaWtlIFNpbmdsZUNvbm5lY3Rpb25EYXRhU291
cmNlIGlzIG1hbnVhbGx5IGJvdW5kIHRvIHRoZSBleHBlY3RlZCBKTkRJIGxvY2F0aW9uLiBUaGlz
IHdpbGwgYWxzbyB3b3JrIHdpdGggcGVyc2lzdGVuY2UgdG9vbGtpdHMgbGlrZSBIaWJlcm5hdGUg
dGhhdCB1c2UgdGhlIEpOREkgRGF0YVNvdXJjZSAtIG5vIGNvbmZpZyBjaGFuZ2UgcmVxdWlyZWQg
aGVyZSB0b28uDQogDQpJbiBhbnkgY2FzZSwgdGhlIGFwcGxpY2F0aW9uQ29udGV4dC54bWwgbmVl
ZHMgdG8gYmUgcmVhZCBieSBhIEZpbGVTeXN0ZW1YbWxBcHBsaWNhdGlvbkNvbnRleHQgaW5zdGVh
ZCBvZiBhIFhtbFdlYkFwcGxpY2F0aW9uQ29udGV4dC4gSWYgeW91IHNldCB0aGUgd29ya2luZyBk
aXJlY3Rvcnkgb2YgYSB0ZXN0IGVudmlyb25tZW50IHRvIHlvdXIgd2ViIGFwcCByb290LCBldmVu
IGFsbCB0aGUgcmVsYXRpdmUgcGF0aHMgd2lsbCB3b3JrLiBUaGUgbG9nNEoncyBzeXN0ZW0gcHJv
cGVydHkga25vd24gYXMgd2ViQXBwUm9vdEtleSBjYW4gYmUgaW5pdGlhbGl6ZWQgZWFzaWx5IHdp
dGggTG9nNGpDb25maWd1cmVyLCB0byBiZSBhYmxlIHRvIHVzZSB0aGUgc2FtZSByZWxhdGl2ZSBw
YXRocyBpbiB0aGUgTG9nNEogY29uZmlnIGZpbGUuIFdlIGFyZSB1c2luZyBzdWNoIGEgc2V0dXAg
c3VjY2Vzc2Z1bGx5IGluIGEgcHJvamVjdCBhdCB3ZXJrM0FULg0KIA0KSnVlcmdlbg0KIA0KIA0K
DQoJLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IGrDvHJnZW4gaMO2
bGxlciBbd2VyazNBVF0gDQoJR2VzZW5kZXQ6IERpIDI3LjA1LjIwMDMgMjA6MjkgDQoJQW46IHNw
cmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KCUNjOiANCglC
ZXRyZWZmOiBbU3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcl0gRGF0YVNvdXJjZSBzZXR1cCBpbiBh
biBBcHBsaWNhdGlvbkNvbnRleHQNCgkNCgkNCg0KCU9uIGFuIG9jY2FzaW9uLCBzb21lIGV4YW1w
bGVzIGZvciBzZXR0aW5nIHVwIGEgRGF0YVNvdXJjZSBpbiBhIFNwcmluZyBBcHBsaWNhdGlvbkNv
bnRleHQuIEFsbCBvZiB0aGVtIGNhbiBiZSBwYXNzZWQgdG8gdGhlIGRhdGFTb3VyY2UgcHJvcGVy
dHkgb2YgRGF0YVNvdXJjZVRyYW5zYWN0aW9uTWFuYWdlciwgSmRiY1RlbXBsYXRlLCBvciBjdXN0
b20gYmVhbnMgYXMgYmVhbiByZWZlcmVuY2UuIFN3aXRjaGluZyBiZXR3ZWVuIHRoZW0gaXMgdGh1
cyBhIG1hdHRlciBvZiBjb25maWd1cmF0aW9uIC0ganVzdCBhY3RpdmF0ZSB0aGUgcmVzcGVjdGl2
ZSBiZWFuIGRlZmluaXRpb24uDQoJDQoJDQoJQSBtb2NrIERhdGFTb3VyY2UgdGhhdCB3cmFwcyBh
IHNpbmdsZSBjb25uZWN0aW9uIChtYWlubHkgZm9yIHRlc3Qgc3VpdGVzKToNCgkNCgk8YmVhbiBu
YW1lPSJkYXRhU291cmNlIiBjbGFzcz0iY29tLmludGVyZmFjZTIxLmpkYmMuZGF0YXNvdXJjZS5T
aW5nbGVDb25uZWN0aW9uRGF0YVNvdXJjZSI+DQoJICAgICAgICA8cHJvcGVydHkgbmFtZT0ic3Vw
cHJlc3NDbG9zZSI+dHJ1ZTwvcHJvcGVydHk+DQoJICAgICAgICA8cHJvcGVydHkgbmFtZT0iZHJp
dmVyTmFtZSI+Y29tLm15c3FsLmpkYmMuRHJpdmVyPC9wcm9wZXJ0eT4NCgkgICAgICAgIDxwcm9w
ZXJ0eSBuYW1lPSJ1cmwiPmpkYmM6bXlzcWw6Ly9sb2NhbGhvc3Q6MzMwNi9jYng8L3Byb3BlcnR5
Pg0KCSAgICAgICAgPHByb3BlcnR5IG5hbWU9InVzZXIiPnJvb3Q8L3Byb3BlcnR5Pg0KCTwvYmVh
bj4NCgkNCgkNCglBIG1vY2sgRGF0YVNvdXJjZSB0aGF0IGNyZWF0ZXMgYSBuZXcgY29ubmVjdGlv
biBvbiBldmVyeSBnZXRDb25uZWN0aW9uIGNhbGw6DQoJDQoJPGJlYW4gbmFtZT0iZGF0YVNvdXJj
ZSIgY2xhc3M9ImNvbS5pbnRlcmZhY2UyMS5qZGJjLmRhdGFzb3VyY2UuRHJpdmVyTWFuYWdlckRh
dGFTb3VyY2UiPg0KCSAgICAgICAgPHByb3BlcnR5IG5hbWU9ImRyaXZlck5hbWUiPmNvbS5teXNx
bC5qZGJjLkRyaXZlcjwvcHJvcGVydHk+DQoJICAgICAgICA8cHJvcGVydHkgbmFtZT0idXJsIj5q
ZGJjOm15c3FsOi8vbG9jYWxob3N0OjMzMDYvY2J4PC9wcm9wZXJ0eT4NCgkgICAgICAgIDxwcm9w
ZXJ0eSBuYW1lPSJ1c2VyIj5yb290PC9wcm9wZXJ0eT4NCgk8L2JlYW4+DQoJDQoJDQoJQW4gZXhh
bXBsZSBmb3IgYSBwb29saW5nIEFwYWNoZSBDb21tb25zIERCQ1AgRGF0YVNvdXJjZToNCgkNCgk8
YmVhbiBuYW1lPSJkYXRhU291cmNlIiBjbGFzcz0ib3JnLmFwYWNoZS5jb21tb25zLmRiY3AuQmFz
aWNEYXRhU291cmNlIj4NCgkgICAgICAgIDxwcm9wZXJ0eSBuYW1lPSJkcml2ZXJDbGFzc05hbWUi
PmNvbS5teXNxbC5qZGJjLkRyaXZlcjwvcHJvcGVydHk+DQoJICAgICAgICA8cHJvcGVydHkgbmFt
ZT0idXJsIj5qZGJjOm15c3FsOi8vbG9jYWxob3N0OjMzMDYvY2J4PC9wcm9wZXJ0eT4NCgkgICAg
ICAgIDxwcm9wZXJ0eSBuYW1lPSJ1c2VybmFtZSI+cm9vdDwvcHJvcGVydHk+DQoJICAgICAgICA8
cHJvcGVydHkgbmFtZT0idmFsaWRhdGlvblF1ZXJ5Ij5TRUxFQ1QgKiBGUk9NIGxhbmd1YWdlPC9w
cm9wZXJ0eT4NCgk8L2JlYW4+DQoJDQoJDQoJVGhlIHByZWZlcnJlZCB3YXkgaW4gYSBKMkVFIGNv
bnRhaW5lciAtIGEgSk5ESSBEYXRhU291cmNlOg0KCQ0KCTxiZWFuIG5hbWU9ImRhdGFTb3VyY2Ui
IGNsYXNzPSJjb20uaW50ZXJmYWNlMjEuam5kaS5KbmRpT2JqZWN0RmFjdG9yeUJlYW4iPg0KCSAg
ICAgICAgPHByb3BlcnR5IG5hbWU9ImpuZGlOYW1lIj5qZGJjL2NieDwvcHJvcGVydHk+DQoJPC9i
ZWFuPg0KCQ0KCQ0KCURJIErDvHJnZW4gSMO2bGxlcg0KCVNlbmlvciBTeXN0ZW0gQXJjaGl0ZWN0
DQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgkNCgl3ZXJrM0FUUyAt
IGRpdmlzaW9uIHN5c3RlbWVudHdpY2tsdW5nDQoJcGFydCBvZiB3ZXJrM0FUIGludGVybmV0bWVk
aWVuIG9lZw0KCQ0KCWV1cm9wYXBsYXR6IDQNCglBIC0gNDAyMCBsaW56DQoJDQoJdC4gICs0MyAo
MCkgNzMyIDcxIDY1IDI5IDUwMg0KCWYuICArNDMgKDApIDczMiA3MSA2NSAyOSAzDQoJanVlcmdl
bi5ob2VsbGVyQHdlcmszYXQuY29tDQoJd3d3LndlcmszYXQuY29tDQoJX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCgl3ZXJrM0FUUyAtIFdJUiBFTlRXSUNLRUxOIEVSRk9M
Rw0K

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

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

I've checked in the changes (backward compatible for now).  I'll tidy it up
after we decide on a definitive strategy.

JP, thanks for your comments on the XML. The XML certainly can be changed at
this stage if we agree on an alternative.

Regards,
Rod

----- Original Message -----
From: "JP Pawlak" <jp....@ti...>
To: "'jürgen höller [werk3AT]'" <jue...@we...>; "'Rod
Johnson'" <rod...@in...>;
<spr...@li...>
Sent: Wednesday, May 28, 2003 7:56 AM
Subject: RE : [Springframework-developer] Spring bean factory XML format


Hi Rod, Jürgen,

I agree that formalism gains to be changed.
Mapping properties and CSV looked always strange.
We can keep compatibility, but release 0.8
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="xxx">yyy</bean>
An alternative could be accepted:
  <property name="xxx" value="yyy"/>

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

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

The ref name="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="jumble">
     <data ref="david"/>
     <data value="literal"/>
     <data>literal2</data>
     <data ref="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...
> [mailto:spr...@li...]
>  De la part de jürgen höller [werk3AT]
> Envoyé : mercredi 28 mai 2003 07:33
> À : Rod Johnson; spr...@li...
> Objet : Re: [Springframework-developer] Spring bean factory XML format
>
>
> Hi Rod,
>
> 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).
>
> 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.
>
> 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.
>
> 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?
>
> Regards,
> Juergen
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Rod Johnson [mailto:rod...@in...]
> Gesendet: Di 27.05.2003 22:19
> An: spr...@li...
> Cc:
> Betreff: Re: [Springframework-developer] Spring bean
> factory XML format
>
>
>
> 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
>
>
>
>
> -------------------------------------------------------
> 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
>
>
> NHYX銲un7+~V
> /u뙩ʋjƊjطj؝jj vv
> 蒋9rԢ
> >ںJ   y˶벋q 箦 G j) Ԯ)~{
> zZz׹ۢy 鶦ϖ+ʭǢ+떳 ~ G
>




-------------------------------------------------------
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