9

Hey I an working on the product which is live at multiple portals. The product is developed in GWT, JAVA, Hibernate.

My question is : Whether there is any alternative of using property file in java.

My Requirement :

  1. For one property key there are multiple values in live portal for each different portal.

  2. Each time I change property file, I need to make the war again.

  3. The loading of any of the property should not be time-consuming.

Any help or suggession would be apprecialble !!!

4
10

I find that JSON files mapped to my own classes does wonders. A few annotations are usually all that's needed to tell the JSON libs how to serialize the class. Outside of this you pretty much live in your code for the rest of the time and get all the benefits of it (refactors, compiler checks, code complete etc).

If you require more strict format and validation of the files then I go for XML by first creating an XSD. Then through JAXB generate the classes, from then on it's the same deal as JSON above. Bit more involved though, only go this route if you require exchanging the data in these files with system that naturally "speak" XML or if you need a strict validation but dont want to spend the time doing it manually.

Yaml can make a pretty good candidate for config. I tried it recently in a python project and I must say it was really nice ! Not sure what the Java yaml work is like though but I would be very surprised if one could not find a good resource to deal with the yaml format.

3
  • 1
    The one caution against using JSON for configuration, is that it doesn't support comments. This is a backwards step from properties files for the person doing the configuration, as they can't temporarily comment out parts of the config, or add explanations. Bower has this problem and it's very contentious and frankly a bit of a silly oversight. In short, JSON is good for data interchange, not so good as a document format. – drrob Feb 22 '18 at 17:06
  • @drrob. You make a good point. That said, from experience once getting configs stored in a structured format I find that the best way to interact with the config is ofter to create editors for it in some form or another. In which case comments in the config file itself become irrelevant – Newtopian Feb 22 '18 at 17:51
  • fair point! Comments are if anything a pain when you have the program modify a config file, because preserving them in a round trip from parser to generator is a hassle. Like a game's settings, you would edit via the game's user interface. Json would be perfect for that kind of config file. – drrob Feb 22 '18 at 21:10
7

You may want to consider YAML

The Dropwizard framework in Java uses YAML for its external configuration. This is easier to work with than JSON since there are no braces.

You can use Jackson to unmarshal the YAML into DTOs with the Jackson Data format YAML module.

Here is an example YAML configuration for configuring the SLF4J within Dropwizard:

logging:

  level: WARN

  # Logger-specific levels.
  loggers:

    # Set specific levels
    "com.sun.jersey.api.client": DEBUG
    "com.yammer": INFO
    "org.multibit": DEBUG

  # ...
  # Settings for logging to stdout.
  console:

    # If true, write log statements to stdout.
    enabled: true

    # Do not display log statements below this threshold to stdout.
    threshold: ALL

  # Settings for logging to a file.
  file:

    # If true, write log statements to a file.
    enabled: false

    # Do not write log statements below this threshold to the file.
    threshold: ALL

    # The file to which current statements will be logged.
    currentLogFilename: /var/log/example/developer.log

    # When the log file rotates, the archived log will be renamed to this and gzipped. The
    # %d is replaced with the previous day (yyyy-MM-dd). Custom rolling windows can be created
    # by passing a SimpleDateFormat-compatible format as an argument: "%d{yyyy-MM-dd-hh}".
    archivedLogFilenamePattern: /var/log/example/developer-%d.log.gz

    # The number of archived files to keep.
    archivedFileCount: 5

    # The timezone used to format dates. HINT: USE THE DEFAULT, UTC.
    timeZone: UTC
3

We use XML and save configuration files in external resources (out of war/jar).

The configuration loading should not be a problem (even if you save it in database), because you don't load it frequently (don't you?). If you need update the configuration runtime, you can use file monitor API to get notified when file changed, or just a timer loop to pull data.

2

One option is store your configuration in a data base. This way you can change properties on the fly.

You don't actually have to install something like MySQL or PostgreSQL, you can use something really minimal such as SQLite or H2.

You can also employ a JMX bean and you can modify it also on the fly.

1

Have you looked at Typesafe Config ? A quick list of features (taken from the link)

  • implemented in plain Java with no dependencies
  • supports files in three formats: Java properties, JSON, and a human-friendly JSON superset
  • merges multiple files across all formats
  • can load from files, URLs, or classpath
  • good support for "nesting" (treat any subtree of the config the same as the whole config)
  • users can override the config with Java system properties, java -Dmyapp.foo.bar=10
  • supports configuring an app, with its framework and libraries, all from a single file such as application.conf
  • parses duration and size settings, "512k" or "10 seconds"
  • converts types, so if you ask for a boolean and the value is the string "yes", or you ask for a float and the value is an int, it will figure it out.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.