1

I'm trying to implement a tier-specific fallback system for my properties.

I know more advanced frameworks like Spring have built in support for this, but I'm using the more minimal Spark Java framework.

Say I have the following structure - 

src/
  main/
    resources/
      properties/
        dev/
          |- application.properties
          |- ValidationMessages.properties
          |- log4j.properties
        prod/
          |- application.properties
          |- ValidationMessages.properties
          |- log4j.properties
        test/
          |- application.properties
          |- ValidationMessages.properties
          |- log4j.properties

        application.properties
        ValidationMessages.properties
        log4j.properties

I'd like properties to be sourced as follows. Assume I have a system config APP.TIER that lets me know at runtime what the current tier is (test, dev, prod, etc...)

  1. Any top-level "shared" file (e.g. properties/application.properties) should apply to all tiers
  2. Any tier-specific properties in (e.g. properties/${APP.TIER}/application.properties) should override common values

With application properties at least I can load them programmatically at the start of my main() method and have them available app wide (example). I can also control the order in which they get loaded so I ensure I manually apply the above fallback logic.

However for 3rd party plugins (e.g. ValidationMessages.properties used by Hibernate or log4j.properties used by log4j) I don't have control over how the properties are loaded.

Is there a generic framework that supports this type of property sourcing? I know maven supports profiles and filtering but that means I'll have to build a separate JAR file for each tier, which doesn't seem great practice.

user2490003
  • 10,706
  • 17
  • 79
  • 155
  • Actually, the Properties class has a [constructor](https://docs.oracle.com/javase/10/docs/api/java/util/Properties.html#%3Cinit%3E%28java.util.Properties%29) that accepts a fallback Properties object. You can use that to build a fallback chain. – VGR Aug 28 '18 at 02:41
  • Thanks. That's what I have been using when I mentioned I loaded the `applications.properties` programmatically. That works great. The issue is when other libraries load their configs, I have no control over what order and fallback logic they use. I know it's bad practice to circumvent their logic but I'm new to Java and i was wondering if this was a solved problem - i.e. is there a library or framework that implements fallbacks and serves it to the 3rd party plugin? – user2490003 Aug 28 '18 at 04:13

0 Answers0