• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

general strategies for seperating config from binary code

 
kirk israel
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So in Tomcat, what are the options for making .xml and .properties files available to functioning code?

I've seen some people put things in [TOMCAT_HOME]\conf\Catalina\localhost - that's nice because it keeps it out of "webapps", but has the gotcha that it's a managed file, so if you happen to remove the .war when the appserver is running, it will happily blow away those files.

Another strategy I've seen is to put it [TOMCAT_HOME]\webapps\[EXPLODED_WAR]\WEB-INF\classes - the down side here seems to be that the war needs to be exploded before you can update the config.

What other ways are there? (and where do people learn this stuff, actually read the dang manual ??? ;-)
 
kirk israel
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Anyone?
 
Tim Holloway
Saloon Keeper
Pie
Posts: 18277
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If it's read-only config information, I normally put it in the WEB-INF/classes (classpath) and load it as a resource. If it's read-write, I store it in a separate external file. For database apps, I prefer a configuration in the database, so that everything's in one place - which can be especially important in disaster recovery.

For smaller, more dynamic config items that are specific to one application instance, I make them JDNI items. That way I can modify them on the fly using the Tomcat console facilities and I can do one-shot overrides using the Tomcat Context. I commonly do that to allow the same WAR to be usable on development, test, and production systems without modification. I can target not only the config files(s) - if any - but also the test/production database.

If I'm keeping a config file as properties, XML, or whatever, and it's not read-only, then (as I said above), I make it external. But I normally do not hard-code its path in the webapp. I use JNDI to inject it from the Tomcat context. This is especially important when my development box is running one OS (Windows) and the production box is running a different OS (Linux), since there are significant differences in how the two OS's organize system files. Though apparently Windows 7 is finally beginning to see the light.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic