Re: XML file changes: dropping .driver.xml

From: Michael Gentry (mgentr..asslight.net)
Date: Mon Dec 14 2009 - 11:59:01 EST

  • Next message: Michael Gentry: "Re: XML file changes: dropping .driver.xml"

    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 <andru..bjectstyle.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: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 - 11:59:56 EST