On 10/26/07, jimpo <[EMAIL PROTECTED]> wrote: > > > And have two installations of my application server - server A with > datasourceX => unit test db - and server B with datasourceX => the other > db? > And run the tests by deploying the war to server A and the actual > deployment > to server B? Right?
Correct. That's probably one good way to do it - what if you want to keep your > database connections configured inside your application and not use server > datasource - can you think of a solution for that? Use Spring properties to set the database connection details and override with suitable env variables from the command line. A bit painfull, but it will work. If you know all your connection details upfront, there may be a way to use a single environment variable to get Spring to switch connections. I consider this solution to be inferiror to container supplied datasources as it is harder to maintain (you would have to rebuild the binary if you wanted to move your database to a new server as an example) plus it raises some interesting questions around testing - if you embed connection details in the binary, should these not be tested as part of the normal test cycle? Get them wrong and your binary is invalid. Mike. Mike Horwitz wrote: > > > > The easiest way to do this is to configure the database connection as > part > > of the container (as a JNDI resource) rather than embed it in the war > > file. > > In applicationContext-resources.xml uncomment the JNDI lookup and > comment > > out the datasource. > > > > Mike. > > > > On 10/26/07, jimpo <[EMAIL PROTECTED]> wrote: > >> > >> > >> *bump* this one because I think a question still remains unanswered. > >> > >> There is a need for have a) unit tests run against database settings 1 > >> (populated by dbUnit) and b) the real application deployment war run > >> against > >> a different database settings 2 > >> > >> The whole point of dbUnit is to run against a different database, > >> dedicated > >> to unit testing. > >> > >> However I can't figure out how to do a mvn install, so that unit tests > >> are > >> run against a different db than the final war. There must be a way to > do > >> this? > >> > >> > >> > >> > >> Joachim Ansorg-3 wrote: > >> > > >> > Hi Rob, > >> > thanks for the second reply. > >> >>> Did you solve that problem somehow or do you just skip the tests in > >> >>> env-dev? > >> >>> > >> >> > >> >> That's evidently by design. For tests to work reliably they have to > >> have > >> >> the > >> >> DB in a known state. > >> >> > >> >> > >> > I assumed that, too. So I've tried to configure appfuse to use a > >> > different database for the tests, i.e. src/main should use db1 and > >> > src/test/ should use db2. So that the main app and the tests are > >> > independent from each other. > >> > But since I failed I will follow your approach. > >> > And profiles are a good idea, anyway. > >> > > >> > Thanks again, > >> > Joachim > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > > >> > >> -- > >> View this message in context: > >> > http://www.nabble.com/cargo-maven2-plugin%3A-Configuration-for-seperate-test-database--tf4677233s2369.html#a13425371 > >> Sent from the AppFuse - User mailing list archive at Nabble.com. > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > -- > View this message in context: > http://www.nabble.com/cargo-maven2-plugin%3A-Configuration-for-seperate-test-database--tf4677233s2369.html#a13426258 > Sent from the AppFuse - User mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
