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