DISCLAIMER: All views are considered my own and you should not draw any conclusions on associates.
In developing a Java Application, one of the issue you will come across is external configuration files, especially if you are making a server application, and the first idea to solve this is to bundle it up with the project. That idea doesn't scale well at all when you want to put the application on multiple servers. The next idea is to allow the user to enter in an IP Addr to connect to when running the jar file. No one wants to do that everytime they run the jar file... Okay, so let's do what companies tend to do and pick a specific directory to store configuration files in. Bingo! This makes the most sense to do, but you have to be careful since Java is platform agonistic. Windows has its own directory structure and Linux/Unix has its own structure (I'm sure there are more, but these are the major targets for servers). You have to take this into account. I tend to be afraid of making my own directories for configuration, but you know? I am starting to care less and am just doing it.
1. Select/create an external configuration directory that will contain the config files. In Linux, that might be /etc/myapp or /opt/com/mycompany/myapp, or /var/lib/myapp, depending on circumstances. Or one of several other possible locations. /usr/local/etc used to be popular, as did /usr/local/myapp/etc. In Windows, you're more or less on your own, although SYSTEM_DRIVE:\Program Files\mycompany\myapp is popular. Or Documents and Settings, although that one's a bit "iffy" for servers.
2. Define a JNDI property that resolves to the pathname of that configuration directory. The webapp will do a JNDI lookup to get this value. The default value is in web.xml, but in Tomcat I can override it in the webapp Context.
3. If I want default property files, I put them in the application classpath and use the request getResource methods to access them.
4. In some cases, especially for volatile properties in database apps, I'll keep a properties table. I also find this useful for storing properties that are shared between multiple instances of the app (if there are any).