I previously developed an application running in a J2EE environment. In order to access the database I used an InitialContext to get a DataSource, and then use the DataSource to get the connection. This is all good. But now I need to develop additional programs which run the same queries against the same database and I want to reuse code.
My Data Access Object currently is responsible for acquiring the connection. I could rewrite the DAO to have a connection passed in and leave the connection acquisition to the calling program (via DataSource for the J2EE application and via DriverManager for the stand-alone applications) Maybe that is the "Best Practice" pattern - and if so I will switch. However, I was wondering if there was a good way to provide a Context and DataSource for the stand-alone applications and leave the DAO alone.
I understand that the applications could tie back to the J2EE environment for a context factory (I have two which already do this), but I do not want to go that route. It does guarantee that the J2EE app and the stand-alone apps are pointing to the same database, but there are problems. The URL for the actual database is fixed, but in my world the J2EE environment may go up and down and its URL can change over time (the reason for this is outside of my hands and the point of this question is not to debate whether this should happen or how to stop it from happening). Every time the J2EE server bounces we have to shut down, reconfigure, and restart the stand-alone programs - this is very ugly.
It seems to me to be a good idea to have a standard way of acquiring (or faking out) a Context and a DataSource outside of a J2EE environment, and I was hoping someone had already addressed this issue and I just didn't know about it.
WHAT is your favorite color? Blue, no yellow, ahhhhhhh! Tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop