Can I put configuration files in a JAR?

Question

We are discussing in my office what may and may not go in the JAR file. It has been suggested that in poor form there is something that is not a .class file falling into the JAR. Currently we have some XML configurations for Ibatis / etc, some properties files .. regular. However, there is an attempt to extract all such files from the JAR and place them in the local file system of each deployment machine. Does that sound reasonable?

Answer 1

This does not seem reasonable to me. I believe that some application configuration should be in the jar file. Things like ORM mappings, spring config, spring XSD user namespace, other XSD, etc. Should be in most cases at the bank. This is an important part of the deployment artifact.

The fact that this is not a class file does not mean that it should be removed from the can only because it can theoretically be changed without creating a new can. Can you imagine a modification of * .hbm.xml during production? it sounds very scary to me.

I think that some configurations, such as spring xml, are in most cases designed to better organize your application and dependencies, but not to change them at runtime during production.

Answer 2

it's a bad form to have anything that is not a .class file, go to JAR

This is nonsense. It is actually a very good form for hosting resources, such as icons and other data files, that the user uses the code in the JAR along with the code. These are the getResource() and getResourceAsStream() methods for Class and ClassLoader , and this makes for much more reliable applications than using resource paths manually.

However, the configuration files may be different. If they are intended to be changed during or after deployment, then their presence inside the JAR file is rather inconvenient and it is preferable to use them in a separate directory.

Answer 3

If you make changes to the configuration file inside the JAR (without even changing a single line of Java code), the entire JAR needs to be rebuilt and redistributed. Does that sound reasonable?

Answer 4

It is absolutely normal to put non-class files in a JAR file, especially the resources needed for the application (images, localized strings, etc.). Knowing this, you must decide which scenario is appropriate for your situation:

• If the configuration is fixed and will only change when you deploy a new JAR file, put it in the JAR.
• If the configuration needs to be changed manually or by the application, save it to the file system.

If you choose the latter, note that it is good practice to include the default configuration in the JAR file to handle the case where the external configuration file is missing. By default, you can download directly from the JAR or copy to the file system to become a new editable configuration.

Answer 5

Do you want or expect them to be changed without a new version of the code? Then you need to extract them.

If the answer to the question is not yours, you should not extract them, as this will allow you to support messing with them without going through the release process. (Of course, this is also possible if they are in a JAR, but a little less tempting.)

Update: But since you mentioned several machines for deployment, there is a third option: remove them and place them in a public area on a network drive. Manually edited configuration files that replicate on multiple machines (but must be identical) are notorious for not being synchronized.

Answer 6

ORM tools (such as Hibernate or IBatis) should not really change after you deploy the application. So no, I would say that it makes no sense for such files.

Depending on your requirements, application configuration files can be located outside of Jar / War so that they can be changed without having to recreate the bank. Keep in mind that changing application settings in production is imho, bad practice. Changes must first be tested under some preconditions.