FAQ
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

Search Discussions

  • Рябицкий Евгений at Dec 14, 2009 at 7:30 am
    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
    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 Razumovsky at Dec 14, 2009 at 7:38 am
    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
    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
  • Рябицкий Евгений at Dec 15, 2009 at 11:02 am
    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
    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
    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 Razumovsky at Dec 15, 2009 at 12:11 pm
    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
    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
    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
  • Andrus Adamchik at Dec 14, 2009 at 2:49 pm
    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
    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
  • Andrus Adamchik at Dec 14, 2009 at 3:03 pm
    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
    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
  • Michael Gentry at Dec 14, 2009 at 5:00 pm
    +1

    2009/12/14 Andrus Adamchik <andrus@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
  • Michael Gentry at Dec 14, 2009 at 4:59 pm
    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 <andrus@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
    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
  • Andrus Adamchik at Dec 14, 2009 at 6:09 pm
    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 <andrus@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
    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
  • Andrus Adamchik at Dec 14, 2009 at 4:07 pm

    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
  • Michael Gentry at Dec 14, 2009 at 1:59 pm
    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 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedDec 13, '09 at 8:45p
activeDec 15, '09 at 12:11p
posts12
users5
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase