RE: [Springframework-developer] AbstractDataFieldMaxValueIncremen ter.dsName

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

Removed dsName property...

D.

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]=20
Sent: Friday, June 20, 2003 11:27 AM
To: Kopylenko, Dmitry; spring-dev-list
Subject: Re: [Springframework-developer]
AbstractDataFieldMaxValueIncrementer.dsName


Dmitriy,
=20
Unfortunately I have to veto: For consistency reasons, we don't have
dataSourceName properties in the whole framework anymore - just =
DataSource
ones. The rationale behind this is that when configured by an =
application
context, it's preferable to use a JndiObjectFactoryBean with the JNDI =
name
of the DataSource - exporting the DataSource as reference:
=20
  <bean id=3D"dataSource" =
class=3D"com.interface21.jndi.JndiObjectFactoryBean">
    <property name=3D"jndiName"><value>jdbc/cbx</value></property>
  </bean>

References can be given to any beans that need access to the DataSource =
via
normal <ref bean=3D"dataSource"/> tags. The nice thing is that such a
DataSource definition can be switched to a direct DataSource instance
easily, e.g. for test environments or standalone applications:
=20
  <bean id=3D"dataSource"
class=3D"com.interface21.jdbc.datasource.DriverManagerDataSource">
    <property
name=3D"driverClassName"><value>com.mysql.jdbc.Driver</value></property>=

    <property
name=3D"url"><value>jdbc:mysql://localhost:3306/test</value></property>
    <property name=3D"username"><value>root</value></property>
  </bean>

One can even use Jakarta's Commons DBCP without any hassle, just by =
adding
the respective JAR files and specifying
"org.apache.commons.dbcp.BasicDataSource" as the class name above.
=20
If DataSource properties are configured manually instead of via the
application context, a call to DataSourceUtils' getDataSourceFromJndi =
is
appropriate (in fact, that's the only reason why this method still =
exists).
As this just causes minimal extra effort, I'm keen on keeping our =
pattern,
to promote a clear strategy for DataSource handling.
=20
So, please remove the dsName property again - I hope I've been able to =
make
the reason clear. Of course, if you consider such additional =
dataSourceName
properties indispensable, we would have to rediscuss the issue - and
consider introducing them to every framework class that features a
DataSource property.
=20
Regards,
Juergen
=20

	-----Urspr=FCngliche Nachricht-----=20
	Von: Kopylenko, Dmitry [mailto:dko...@ac...]=20
	Gesendet: Fr 20.06.2003 15:56=20
	An: 'spring-dev-list'=20
	Cc:=20
	Betreff: [Springframework-developer]
AbstractDataFieldMaxValueIncrementer.dsName
=09
=09

	I've committed the following:=20

	* Added String dsName property to the
AbstractDataFieldMaxValueIncrementer, so the dataSource could be =
resolved
like this:

	public void setDsName(String dsName) {=20
	        this.dsName =3D dsName;=20
	        this.dataSource =3D
DataSourceUtils.getDataSourceFromJndi(this.dsName);=20
	}=20

	Regards,=20
	Dmitriy.=20