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 <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 - 13:09:50 EST