0

I'm researching what is the best way to store application configuration data while supporting hierarchy and dynamic loading.

Data examples:

  • Where to locate each column (we would display a lot of tables)
  • How to visualize data in each column or cell (for example some column may have different ways to show the same metric)
  • Data format (date or numbers)

Hierarchy means:

I have a state that has several districts, so there will be default configuration, but a state can override parts (or all) of the default configuration and a district can override parts of the state configuration.

Dynamic loading means:

Ability to dynamically load and apply new configuration without needing a server restart or even user login.

Configuration storing format (can be files or DB):

  • XML – that's what I was using in the past
  • JSON - so I can read JSON from a config file or database and have it as an object in the app memory
  • Key-Value pairs
  • other formats?

What are your thoughts/knowledge about this subject?

Thank you!

Improve this question
2
  • Java has a Properties class that's made for reading in and writing out sets of key/value pairs. Far as i've seen, it's the standard for dealing with arbitrary sets of configuration values. It even lets you construct chains/trees of Properties objects, so you can have defaults in the parent that a child overrides. Commented Dec 6, 2011 at 21:58
  • stackoverflow.com/questions/12144/… Commented Dec 8, 2011 at 16:50

3 Answers 3

Reset to default
2

A long time ago I wrote something to do similar. It wasn't intended to be hierarchical. It relied on every Component having a unique and reasonable name. This was before XML and JSON were trendy, so I just used Properties.

Essentially, you start at the top Window, look at all of it's Components, and, based on it's type (lots of instanceofs) call a method (nowadays you'd give it a fancier name like "Marshaller" :-)) to write out the relevant info that the user might change and want to restore. Apply recursively. You'll get something like:

MainFrame.background=#FFFFFF MainFrame.bounds=200,100,400,500 ... MainFrame.Divider.x=122 ... MainFrame.DataPanel.DataTable.Columns.1.x=423 MainFrame.DataPanel.DataTable.Columns.1.width=22 MainFrame.DataPanel.DataTable.Columns.1.sortedby=Name

You could probably finagle this to be hierarchical, but nowadays it's probably better to use XML or JSON. But the basic concept might apply. You could use DIP or something to determine the proper Marshaller.

Maybe this will give you a few ideas. Maybe there isn't a standard way. I'm surprised that nobody has responded with "oh yeah, use Apache this or Guava that or JGoodies" etc.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

+1: I saw this technique being used about 20 years ago to build GUI applications with the X Window system. Each component level had two attributes (type and children) that specified the component's type and the list of child components (represented as nested properties). The combination of those two attributes made it possible for a simple, recursive algorithm to create the entire hierarchy of GUI components for an application. Thus, in your example, there would be MainFrame.type=... (whatever class implements the main frame of an application) and MainFrame.children=Divider,DataPanel.
0

I am the maintainer of a configuration-file parser library called Config4J. From the details you provide in your question, I don't think Config4J is 100% suitable for your needs. However, some parts of its documentation might provide useful inspiration for you.

I recommend you skim-read Chapters 2 and 3 of the "Getting Started" manual to gain a good-enough overview of the syntax and API. Then read Part II ("Configuration-driven Object Creation") and Part III ("The Config4JMS Case Study") of the "Practical Usage" manual. Links to HTML and PDF versions of all the manuals are provided at the bottom of the Config4J website.

Improve this answer

Comments

0

Well, there's always the Java Preferences API. Then you don't have to worry about any of these things.

Addenda:

The popularity (or lack of) likely stem from the fact that, out of the box, Preferences is global across the system or the user. So, applications and such would need to make their own namespaces within the Preferences tree. Folks are more used to each instance having their own properties file and going from there.

As for more complicated structures, the Preferences API is a tree structure, like an XML DOM. You located nodes in the tree and work below those nodes. So you can layer structured data on top of that representation.

The API is old much like the java logging API is old. But the design is pretty basic and useful, so there wasn't much call for updating it. The collections framework is old as well, but we live with that happily (mostly) every day.

Improve this answer

3 Comments

I checked Java preferences but everything I find online looks really really old - can it be that not many use it? Also, can I do more complex things than key-value pairs?
Properties are also somewhat hierarchical. But a bit awkward.
But the hierarchy is more convention rather than a first class concept with direct support by the API.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.