This week's book giveaway is in the Cloud/Virtualization forum.
We're giving away four copies of Building Blockchain Apps and have Michael Yuan on-line!
See this thread for details.
Win a copy of Building Blockchain Apps this week in the Cloud/Virtualization forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Liutauras Vilda
  • Knute Snortum
  • Bear Bibeault
  • Devaka Cooray
  • Jeanne Boyarsky
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • salvin francis
  • Tim Holloway
  • Piet Souris
  • Frits Walraven

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

Ranch Hand
Posts: 120
  • Mark post as helpful
  • send pies
  • 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
  • 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.
I don't even know how to spell CIA. But this tiny ad does:
Java file APIs (DOC, XLS, PDF, and many more)
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!