I've used 3: the application using a "where am I" look at
cgi.http_host when it starts up; and setting an application scope
variable for the dsn.
I've also done 2: placed a ini file on each server, outside the web root
and outside source control. It contains a handful of vars that ONLY have
to do with that specific box (correct datasource, that machine's name /
IP, the word "dev", "prod", etc, perhaps a 'app license key'). Something
like this sets things up OnApplicationStart:
<cfset settingsFilePath = 'some path/' & application.ApplicationName &
'.ini' />
... Application.dsn =
trim(GetProfileString(settingsFilePath,"settings","dsn"));
You probably get the idea already...
Al
On 9/21/2011 11:27 AM, Alan Williamson (aw2.0 cloud experts) wrote:
Chris its an age old problem and something to be honest with you the
J2EE Servlet standard dropped the ball on .. the ability to pass in
parameters to a WAR file.
The ways around this are:
1/ Name all your datasources with symbolic names (mymaindb) and then
resolve that lookup on the /etc/hosts file on your various
production/staging/testing boxes.
or
2/ Look for a file in a given location outside the war deployment that
can then tell you application the information it needs to know
or
3/ Have it work out based on the host IP address where it is and make
decisions accordingly
For us, Option#1 has always been the route for us and never gave us
any major problems.
chris schiffman wrote:
Hello,
Is there a way to package up an OPENBD war file, so when it's
deployed, it's environment aware? ie: if the war file is deployed on
a development server, the datasource points to the development
database.. deployed on production, it points to the production db..
Or is best to just keep different versions?
Thanks for any help,
-chris
--
official tag/function reference: http://openbd.org/manual/
mailing list - http://groups.google.com/group/openbd?hl=en