• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Ron McLeod
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Paul Clapham
  • Rob Spoor
  • Junilu Lacar
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Piet Souris
  • Carey Brown

webapp: how to inject separate datasoure in main method vs production

Ranch Hand
Posts: 120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is there anyway to inject different datasources for production vs development?

I want to use jndi for my dataSource when my webapp is deployed. However, sometimes while developing I'll quickly write a main method to test some functionality. How can I use just a regular dataSource connection using url, username, and password when directly running a class outside of jetty?
Posts: 1210
Android Python PHP C++ Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, it's done all the time. Improved testability is one of the main reasons to use Spring's dependency injection capabilities.
There are multiple ways to do it:

Technique 1 - Declare production DS bean and dev DS bean in two different context XMLs or ContextConfig classes
Declare them in two different contexts but give both of them the same bean ID so that DAO bean need not change.
For example, the production context XML "PROJECT/src/resources/datasource-prod.xml":

and the development context XML "PROJECT/test/resources/datasource-dev.xml":

Rest of the beans - controllers, models, DAO - are in a different context XML, say "PROJECT/src/resources/app.xml" (actually, I put beans of each layer in its own context XML to make it easy to mock out entire layers...makes unit testing very easy).

So now for production webapp, you include {app.xml, datasource-prod.xml} in the DispatcherServlet's context locations.

For unit tests, you tell Spring to load {app.xml, datasource-dev.xml} this way:

For your own adhoc test application with main method, you create ClassPathXmlApplicationContext("app.xml, datasource-dev.xml").

The concept is same even if you're using java configuration classes instead of XML - just refactor the prod/dev datasource beans into their own config classes under PROJECT/src/ and PROJECT/test/.

Technique 2 - Use environment variables
The idea here is that values are imported into beans from environment variables or property files. This article explains it in detail.
    Bookmark Topic Watch Topic
  • New Topic