aspose file tools*
The moose likes Tomcat and the fly likes general strategies for seperating config from binary code Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Tomcat
Bookmark "general strategies for seperating config from binary code" Watch "general strategies for seperating config from binary code" New topic
Author

general strategies for seperating config from binary code

kirk israel
Greenhorn

Joined: May 28, 2009
Posts: 27
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

Joined: May 28, 2009
Posts: 27
Anyone?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16305
    
  21

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.


Customer surveys are for companies who didn't pay proper attention to begin with.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: general strategies for seperating config from binary code