What are Best Practice Recommendations for Property File Configuration?

[firepod]

Where does application configuration belong in modern Java EE 7 applications? What best practice(s) recommendations do people have?

By application configuration, I mean settings like those relating business logic (e.g. expiration dates, etc) as well as connectivity settings to services on other boxes, including external ones (e.g. Twitter and our internal Cassandra servers...for things such as hostnames, credentials, retry attempts).

Assumptions:

1) We are deploying to Wildfly 8.1 using a single EAR file, which contains multiple wars and one ejb-jar.

2) We will be deploying to a variety of environments: Unit testing, local dev installs, cloud based infrastructure for UAT, Stress testing and Production environments. Many of our properties will vary with each of these environments.

3) We are not opposed to coupling property configuration to a DI framework if that is the best practice people recommend.

4) All of this is for new development, so we don't have to comply with legacy requirements or restrictions. We're very focused on the current, modern best practices.

Does configuration belong inside or outside of an EAR?

If outside of an EAR, where and how best to reliably access them?

If inside of an EAR we can store it anywhere in the classpath to ease access during execution. But we'd have to re-assemble (and maybe re-build) with each configuration change. And since we'll have multiple environments, we'd need a means to differentiate the files within the EAR. I see two options here: 1) Utilize expected file names (e.g. cassandra.properties) and then build multiple environment specific EARs (eg. appxyz-PROD.ear).

2) Build one EAR (eg. appxyz.ear) and put all of our various environment configuration files inside it, appending an environment variable to each config file name (eg cassandra-PROD.properties). And of course adding an environment variable (to the vm or otherwise), so that the code will know which file to pickup.

What are the best practices people can recommend for solving this common challenge?

Thanks.

[rcd]

In my opinion, configuration should NOT be inside the deployment because, as you noted, you would have to re-assemble it for each environment. That's practically begging for someone to make a mistake.

For our projects, we usually define configuration in two places because we do a lot of clustered applications. Most configuration (anything that should be uniform across all nodes in the cluster) goes in a database table. Anything that can't be in the database (because it needs to be accessed too early during deployment and we may not have a database connection yet) or shouldn't be in the database (because it's specific to that node) goes into the WildFly configuration file in the <system-properties> section.

Then, as part of our build process, we construct a full WildFly instance, add a custom config file plus the deployment and anything else we need (like extra modules), and zip the whole thing up. In the custom config file, we use system property interpolation with reasonable defaults to set database URLs, bind addresses, ports, and anything else that needs to be configured for WildFly itself. So when we need to deploy a build somewhere, we just grab the zip, decompress it, open the config file, and just paste in whatever the appropriate system properties are. It's a simple and uniform process that makes installing or upgrading any environment very easy.

[firepod]

Many thanks for the reply.

Do you happen to know where in the Wildfly docs I can read more about system property interpolation? I checked out the docs and Google it, but didn't find anything.

[rcd]

I'm not sure if it's actually documented anywhere. It's pretty straight-forward to use though. For any situation where you want to use interpolation, instead of putting

myValue

you would put

${myProperty}

and then this somewhere (WildFly puts it between </extensions> and <management> when it rewrites the config file)

<system-properties>

<property name="myProperty" value="myValue"/>

</system-properties>

System property interpolation can also be specified in the form

${myProperty:defaultValue}

which will cause defaultValue to be used if myProperty is not set.

It should also be noted that interpolation may not work everywhere. The WildFly devs have made an effort to support it everywhere, but there may still be some seldom-used areas they missed. If you run into such an area, file a bug report.