Is it bad practice to include properties/configuaration files within jars?

Question

For example:

MyApp is a web app that contains a properties file (server.properties) that describes config data (e.g. server names) for the app. In the development phase, server.properties is located in its own IDE project folder (a logical spot for it).

Now it's time to deploy MyApp. The IDE makes it quite trivial to jar up the class files as well as the supporting config files. Now we just drop the Jar in the appropriate web container and away we go....

A week later... the server config data that MyApp uses needs to change. Which makes more sense?

A. Modify the server.properties file back in IDE land and generate a completely new jar file. Redeploy. (which means bouncing the app for a simple configuration change).

B. Crack open the already deployed Jar and modify the server.properties file? (may have to call a refresh function in MyApp if server.properties is cached... but should not require a full app bounce. Also need to remember to modify source server.properties as well so future deploys don't revert server.properties to the old server names).

C. Make server.properties external to the jar file in the first place. Very similar to B's process, with the minor difference of keeping config data external to the jar (introduces different paths between development and production deploys)

D. Other:

Thanks!

Answer 1

I'd go with D.

Try to load the properties files from outside the .jar then, if that fails, load the properties built into the jar.

This lets you push out a "ready made" configuration with each build (also reduces the complexity of a deployment, if by just one file), while also making overriding configurations possible and reasonably simple.

Answer 2

If you are using Spring then you can make use of the property placeholder to do the work.

<!-- try and resolve the config from the filesystem first and then fallback to the classpath -->
<context:property-placeholder location="file:config.properties, classpath:config.properties"
                              ignore-resource-not-found="true"/>

You can specify a resource on the filesystem and also on the classpath, Spring will first try and resolve all of the properties from the filesystem and then fallback to the classpath. By specifying the "ignore-resource-not-found" attribute as "true" it will prevent Spring from throwing an exception if the file isn't present on the filesystem and allow it to resolve the properties from the classpath instead.

Using this combination also allows you to split the properties over two files, for example you might never want to specify passwords in the file on the classpath and expect them to be specified externally on the filesystem. Any properties missing from the filesystem will be resolved from the classpath.

In a folder containing:

application.jar
config.properties

You should be able to use:

java -jar application.jar

This is a sample config.properties for reference:

# This file contains properties that are used to configure the application
database.url=127.0.0.1
database.port=3306
database.user=root
database.pass=p4ssw0rd

Answer 3

It depends. If the properties file contains data that is intended to be changed by the user of your application or library, than it should reside outside.

If it contains data that is static and you created the properties files just to avoid coding the values in the sourcecode or if the files are localized strings, I'd leave them in the jar. At least because a properties file invites people to change values ;)