XML Property File Configuration

Hi,

I've currently got an java application which uses Quartz to schedule jobs. The jobs typically go to various regional databases and populate another consolidated database to get a consolidated view of the data. It also schedules routine tasks such as nightly batch activities and archiving.

The configuration data i.e job, trigger and database connection details are held in an XML config file and read by the java process.

However, today a problem occurred. A member of the team had accidental coped the production XML config file to UAT and changed some of the regional DB values to UAT values, but not the consolidated DB connection details. As a result we had erroneous UAT data in production and some details were duplicated (one from prod and one from UAT. As you can imagine this was a nightmare!

As a result I've proposed getting the DB connection details out of the xml config file and putting it in a unix vi properties file with property value pairs. This will split the job / triggers and connection details. The property file name would be propertyfile.properties.prod and propertyfile.properties.uat and the correct file read in depending on property set in the unix user .profile file.

This seems a bit complex. I was just wondering if anyone had similar problems and how the resolved it / if anyone has any advice to help create a fool-proof solution.

Your help ould be much appreciated
bowemcAsked:
Who is Participating?
 
objectsConnect With a Mentor Commented:
> but it won't in itself prevent rogue edits such as the one you've mentioned.

of course it will. You obviously would not deploy the production file in the test environment.
And you don't need to backup it up, that won't help at all.

0
 
CEHJCommented:
Back up the config files? If you want to do it more flexibly, you could even use a versioning system for the config files, then you can keep track of edits, particularly who's allowed to make them, and roll them back if they're wrong
0
 
bowemcAuthor Commented:
Hi Cehj,

I'm looking for a way to ensure my production DB connection details are not used in a config file unless in prod, or at least reducing the likelihood of. I can't see how back-up or conversioning can help with this???
0
 
objectsCommented:
db connection details should be installed in a separate file, that way you have one version in production and another in testing/development

0
 
CEHJCommented:
>>This will split the job / triggers and connection details.

That's probably a good idea, but it won't in itself prevent rogue edits such as the one you've mentioned. The best thing to do is to restrict write access and keep backups then things can be restored easily
0
All Courses

From novice to tech pro — start learning today.