This question probably could go in a variety of topic areas so hopefully this is the best one.
I have a general "Best Practices" question that I'm sure has come up before.
We have a properties file that contains a path to where we save files. On my computer that property is C:\Temp\Files, on dev it is D:\Share\Files and on prod it is Z:\Share\Files
The properties file is bundled into the war and distributed to each platform.
On dev: We change the path and hand out the war
On prod: We change the path and hand out the war
What bugs me:
I don't like the idea of having to change this, however I don't like the idea of having the properties file outside the war (as we make changes to this properties file it would have to be reflected on each server and each new server).
Oh yeah, this application doesn't have a database.
Ideally I would like something like this:
3 properties files (local, dev, prod) inside the war
A method to tell the war that it is on prod,dev,test
That way when we create a new prod environment we just have to make one change. And if we change the properties file it is still bundled in the war.
The question is, what is the best practice for doing this? Yet another properties file outside the war that just has one setting? Or some other method to let the application know that it is on local/dev/war?
My suggestion is to have only 1 properties file. This way, you're running the same code in dev, testing, and production (no branches in code that say: If testing, do this; if production, do that ... even if it's simply loading different files). I would have that properties file outside the war file so that it's accessible during the installation process.
Is there a defined process for updating the war file? If not, there should be. If possible, automate that process (at my company, we rolled our own installer for our flagship product -- it's tied to WebLogic, but we have control over various files like these). This way you have control over that file, so if you need to make changes to it, those changes are done as part of that process (either automatically through an installation/upgrade process, or manually by someone following the process script). At the simplest level, you could have a properties file utility that inspects the properties file and performs the necessary upgrades (I'd suggest having a properties file meta-property defining the version of the properties file; use either a comment or a property like "__Version=126.96.36.199" for that).
Alternatively, you could use Java's Preferences API and create a user interface to set specific preferences. If you do that, somebody has to go into that screen or whatever and set those preferences for every installation, but you don't have to worry about where the properties file goes.
Piscis Babelis est parvus, flavus, et hiridicus, et est probabiliter insolitissima raritas in toto mundo.
Joel McNary wrote:My suggestion is to have only 1 properties file.
Yes. I usually use the environment name in the property name:
And use a custom property utility class which, given a property name, appends the environment name, using the default value if no environment-specific value is found.
I've seen other people use the "property file processor" Joel suggests. Whichever works.
Joel McNary wrote:
Is there a defined process for updating the war file? If not, there should be. If possible, automate that process
I agree. And source control, if you aren't already using it.
Ahh thanks guys! I like the idea of the properties file being broken down by name (dev.filepath / prod.filepath / client.filepath) instead of three different properties files.
Thanks for the tips on version control and such, these are all things I'm planning on implementing. My only real concern is that I want the deployment to be as seamless as humanly possible. I really dislike external dependencies because they are just another thing that has to be documented.
What about this:
Right now I'm leaning towards a "Run Once" style setup (similar to apps like Drupal) where the person would deploy the war, hit this particular JSP page and configure the machine to be on admin/dev/client. This installer page would eventually have more options (if needed). The only thing I need to do is either make that JSP self deleting or make it only accessable to localhost. This setup page could also do some generic connection tests to make sure everything is live and running, basically an admin panel.