You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <aa...@apache.org> on 2009/12/13 21:45:20 UTC
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
Re: XML file changes: dropping .driver.xml
Posted by Michael Gentry <mg...@masslight.net>.
Keep in mind the password encoder doesn't store location information.
The JDBC connection setting would remain the same unless you swap out
the driver.xml file. So I don't think putting the driver in
cayenne.xml helps.
mrg
On Sun, Dec 13, 2009 at 3:45 PM, Andrus Adamchik <aa...@apache.org> wrote:
> 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
>
Re: XML file changes: dropping .driver.xml
Posted by Andrey Razumovsky <ra...@gmail.com>.
It depends on whether same application can access more than one database on
*one server*. If so, you must really use dynamic creation of DataNodes.
But the most common case is when there is one connection, but you do not
know it when you're building war archive. Then you can use
JNDIDataSourceFactory for your datanodes and configure DB settings in
application server using its JNDI container.
15 декабря 2009 г. 14:01 пользователь Рябицкий Евгений <
eryabitskiy@diasoft.ru> написал:
> Didn't understand the question. :(
> We are producing only war archive.
> This war archive can be deployed on hundreds of servers... So there is used
> external configuration file (like log4j.properties) to configure DB
> settings.
>
> Evgeny.
>
>
> -----Original Message-----
> From: Andrey Razumovsky [mailto:razumovsky.andrey@gmail.com]
> Sent: Monday, December 14, 2009 10:38 AM
> To: dev@cayenne.apache.org
> Subject: Re: XML file changes: dropping .driver.xml
>
> Hi,
> Why can't you use JNDI for different server deployments?
>
> 14 декабря 2009 г. 10:29 пользователь Рябицкий Евгений <
> eryabitskiy@diasoft.ru> написал:
>
> >
> > 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:aadamchik@apache.org]
> > Sent: Sunday, December 13, 2009 11:45 PM
> > To: dev@cayenne.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
> >
>
>
>
> --
> Andrey
>
--
Andrey
RE: XML file changes: dropping .driver.xml
Posted by Рябицкий Евгений <er...@diasoft.ru>.
Didn't understand the question. :(
We are producing only war archive.
This war archive can be deployed on hundreds of servers... So there is used external configuration file (like log4j.properties) to configure DB settings.
Evgeny.
-----Original Message-----
From: Andrey Razumovsky [mailto:razumovsky.andrey@gmail.com]
Sent: Monday, December 14, 2009 10:38 AM
To: dev@cayenne.apache.org
Subject: Re: XML file changes: dropping .driver.xml
Hi,
Why can't you use JNDI for different server deployments?
14 декабря 2009 г. 10:29 пользователь Рябицкий Евгений <
eryabitskiy@diasoft.ru> написал:
>
> 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:aadamchik@apache.org]
> Sent: Sunday, December 13, 2009 11:45 PM
> To: dev@cayenne.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
>
--
Andrey
Re: XML file changes: dropping .driver.xml
Posted by Andrey Razumovsky <ra...@gmail.com>.
Hi,
Why can't you use JNDI for different server deployments?
14 декабря 2009 г. 10:29 пользователь Рябицкий Евгений <
eryabitskiy@diasoft.ru> написал:
>
> 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:aadamchik@apache.org]
> Sent: Sunday, December 13, 2009 11:45 PM
> To: dev@cayenne.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
>
--
Andrey
Re: XML file changes: dropping .driver.xml
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Dec 14, 2009, at 2:29 AM, Рябицкий Евгений wrote:
> I have some ideas about dynamic adding of DataNodes. Is it possible?
Could you start a new thread on that and explain what scenario you are
trying to handle.
Andrus
Re: XML file changes: dropping .driver.xml
Posted by Andrus Adamchik <an...@objectstyle.org>.
I am sure it doesn't.
Honestly I feel like the password encoder piece complexity warrants
its own DataSourceFactory with its own configuration (via properties?
e.g. it may extend a DBCP factory, so the property file is amended
with extra properties). IMO it offers so many options that it is not a
good pick for the default factory that should be as vanilla as possible.
I'd love to kick out of the Modeler all the non-ORM related special
integration modules (e.g. JGroups configuration), so this may be one
other thing to treat as a "bundled extension" so to speak.
Andrus
On Dec 14, 2009, at 11:59 AM, Michael Gentry wrote:
> I'd have to verify this, but I don't think the DBCP option supports
> the password encryption feature. What I did in the past was use Ant
> to swap different driver.xml files out for different builds. All used
> the encrypted password feature, but different driver.xml files. Also,
> the DBCP can be a bit of a pain to use as I discovered, but if this is
> cleaner in 3.1 then that'll help.
>
> mrg
>
>
> 2009/12/14 Andrus Adamchik <an...@objectstyle.org>:
>> 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:aadamchik@apache.org]
>>> Sent: Sunday, December 13, 2009 11:45 PM
>>> To: dev@cayenne.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
>>>
>>
>>
>
Re: XML file changes: dropping .driver.xml
Posted by Michael Gentry <mg...@masslight.net>.
I'd have to verify this, but I don't think the DBCP option supports
the password encryption feature. What I did in the past was use Ant
to swap different driver.xml files out for different builds. All used
the encrypted password feature, but different driver.xml files. Also,
the DBCP can be a bit of a pain to use as I discovered, but if this is
cleaner in 3.1 then that'll help.
mrg
2009/12/14 Andrus Adamchik <an...@objectstyle.org>:
> 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:aadamchik@apache.org]
>> Sent: Sunday, December 13, 2009 11:45 PM
>> To: dev@cayenne.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
>>
>
>
Re: XML file changes: dropping .driver.xml
Posted by Michael Gentry <mg...@masslight.net>.
+1
2009/12/14 Andrus Adamchik <an...@objectstyle.org>:
> Another related thing... for the unit tests we have command line overrides
> of the DataSource parameters (-DcayenneJdbcUrl=...). Maybe honor these
> System properties universally across all Cayenne-provided DataSource
> factories? Then we don't need a JNDI hack and any environment can be
> reconfigured easily on startup.
>
> Andrus
Re: XML file changes: dropping .driver.xml
Posted by Andrus Adamchik <an...@objectstyle.org>.
Another related thing... for the unit tests we have command line
overrides of the DataSource parameters (-DcayenneJdbcUrl=...). Maybe
honor these System properties universally across all Cayenne-provided
DataSource factories? Then we don't need a JNDI hack and any
environment can be reconfigured easily on startup.
Andrus
On Dec 14, 2009, at 9:49 AM, Andrus Adamchik wrote:
> 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:aadamchik@apache.org]
>> Sent: Sunday, December 13, 2009 11:45 PM
>> To: dev@cayenne.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
>>
>
>
Re: XML file changes: dropping .driver.xml
Posted by Andrus Adamchik <an...@objectstyle.org>.
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:aadamchik@apache.org]
> Sent: Sunday, December 13, 2009 11:45 PM
> To: dev@cayenne.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
>
RE: XML file changes: dropping .driver.xml
Posted by Рябицкий Евгений <er...@diasoft.ru>.
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:aadamchik@apache.org]
Sent: Sunday, December 13, 2009 11:45 PM
To: dev@cayenne.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