• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Devaka Cooray
  • Knute Snortum
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar
  • Tim Holloway
  • salvin francis

What are Best Practice Recommendations for Java EE 7 Property File Configuration?  RSS feed

Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Where does application configuration belong in modern Java EE applications? What best practice(s) recommendations do people have?

By application configuration, I mean settings like 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) as well as those relating business logic (things that one might be tempted to store as constants in classes, e.g. days for something to expire, etc).

1) We are deploying to a Java EE 7 server (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?

Can you shoot lasers out of your eyes? Don't look at this tiny ad:
ScroogeXHTML - small and flexible RTF to HTML converter library
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!