Yeah, I tried to generalize this configuration a few times without much success. Swapping files is certainly one way to do it (see a recently removed "cdeploy" task). My issue with it is that connection info is stored with the project and is saved in SCM. I'd like to externalize it if possible.

We'll see how the DI container work goes. Defining DataSourceFactories is certainly in scope for the container. Maybe we'll add something similar to what Olga just did for the unit tests - system property driven configuration.

Andrus


On Nov 18, 2009, at 12:34 PM, Andrey Razumovsky wrote:
I see. Actually here we use other approach. We have

"cayenne.xml" - that is looking to DB via driver.xml and JDBC
"cayenne.xml.web" - that is looking via JNDI.

They both refer to same dataMap. In development we use cayenne.xml, during the build process we replace it with cayenne.xml.web (using Ant or Maven).
No weird jars are required!

2009/11/18 Andrus Adamchik <[email protected]>


On Nov 18, 2009, at 12:22 PM, Andrey Razumovsky wrote:

2009/11/18 Andrus Adamchik <[email protected]>

(did we use in the past in situations similar to the current JNDI hack??)


Andrus, could you describe more in detail this JNDI hack? I wish we could
get rid of cayenne-modeler.jar


http://cayenne.apache.org/doc/using-jndi.html

(see "Development with JNDI DataNodes")

The reason why Modeler is need is to read the preferences DB. I am planning to replace custom Cayenne-driven Modeler preferences DB with standard Java Preferences API, and move all the preference read code to Cayenne core. Then
we can get rid of Modeler dependency for JNDI hack.

Andrus




--
Andrey

Reply via email to