If you think of it, the only value of .driver.xml (or a <data-
source>..</data-source> inside cayenne.xml for that matter) is that it
can be edited in the Modeler. If a user overrides the Modeler-provided
XML file, this functionality is lost, and configuration can be
provided in a number of different ways.
1. DBCPDataSourceFactory - this is the closest to what you are
doing... Only instead of swapping .driver.xml, you'll be swapping
dbcp.properties
2. JNDIDataSourceFactory - if you are in a web container, there's no
reason not to use it
3. Custom factory. Should be very easy to write to load JDBC data from
somewhere, based either on o.a.c.conn package or commons-dbcp.
So I still feel like there's no value in keeping that file.
(As a side note, I already committed this change to the 3.1 project
loader/saver last night (the one we are not using yet), but there
won't be a problem to roll it back. So I am not using the fact that it
is already there as an argument to keep it).
Andrus
On Dec 14, 2009, at 2:29 AM, ςΡΒΙΓΛΙΚ εΧΗΕΞΙΚ wrote:
>
> Let me share my usage experience:
> We don't use driver.xml at all. Just some empty file.
> Usually there is one node and DataSource for this Node is overridden
> by our configuration. We can't just build-in it in cayenne.xml
> because data base configuration can various on different server
> deployments.
> I mean that when all database settings are strongly set in
> cayenne.xml (that is inside your JAR/WAR) you can't change it so easy.
>
> I have some ideas about dynamic adding of DataNodes. Is it possible?
>
> Evgeny.
>
>
>
> -----Original Message-----
> From: Andrus Adamchik [mailto:aadamchi..pache.org]
> Sent: Sunday, December 13, 2009 11:45 PM
> To: de..ayenne.apache.org
> Subject: XML file changes: dropping .driver.xml
>
> Since I am rewriting the project load/save code, I am going to add one
> more format change - move .driver.xml stuff into cayenne.xml. The
> original motivation for a separate file was to allow users to swap it
> in different deployment environments, e.g. to protect their production
> password. Now we have the password encoder facility that does not
> require file swapping, and most JEE environments are using JNDI
> anyways, so makes sense to reduce the complexity, and store the
> <driver>..</driver> section right in cayenne.xml.
>
> Andrus
>
This archive was generated by hypermail 2.0.0 : Mon Dec 14 2009 - 09:49:52 EST