Apache Examples and Configuration cases

[Werner Keil]

Hi,

Beside a seemingly popular Apache Commons Configuration (see http://mvnrepository.com/artifact/commons-configuration/commons-configuration/1.9 for 1.9, older versions are equally used by e.g.Google APIs like AdSense, Neo4J, JBoss and many others) which we also used for a Test Automation / DevOps solution at a major airline, there's another Apache Incubator project, JClouds where configuration is described here:

http://jclouds.incubator.apache.org/documentation/reference/jclouds-api/

Parts like EnterpriseConfigurationModule use the Google Guice flavor of Depencency Injection, so at least JSR 330 sounds like a common denominator an SE/Desktop or Mobile/Embedded capable config JSR could find beneficial.

Werner

[Werner Keil]

As mentioned on Twitter as a more persistent link, here's another Apache approach to configuration, DeltaSpike Configuration:

http://deltaspike.apache.org/configuration.html

Werner

[Anatole Tresch]

Yes, Also much of the concepts are very similar to what I proposed (e.g. Scope==ConfigSource,Aggregate=ConfigResolver). A difference is that the precedence of scopes/ConfigSource is defined by the aggregate, instead as a priority on the scope/ConfigSource. IMO this is more flexible, since the same scope/config source may be included in different aggregates. Priorities on scope level may clash or at least make it more cumbersome to define the ordering required, whereas with configuration on aggregate level you can easily reuse scopes more or less arbitrarily.

But many of the things in Deltaspike look very promising, The ones of you who did not yet, should really have a look at it!

[Werner Keil]

One more Apache related example is Felix Preferences Service:

http://felix.apache.org/site/apache-felix-preferences-service.html

implementing OSGi Preferences:

http://www.osgi.org/javadoc/r4v42/org/osgi/service/prefs/Preferences.html

It may be similar but slightly more platform neutral than e.g. java.util.preferences, so for both SE/ME and EE scenarios using such preferences as a backing option for configuration seems worth a thought.

Werner

[Anatole Tresch]

IMO using preferences trees as low level representation of configuration is not bad, since it provides a comprehensive and intuitive representation, which also for error analysis is quite useful. But my experience shows we should consider a few points:

• util.Prefernces in the JDK has numerous flaws
• bad design with abstract classes that constrain different things, including the synchronization of access, or are difficult to adapt
• platform dependent default behaviour (file storage vs. Windows registry  etc)
• no out of the box support for different subtree providers
• but the main concern is, that there is no separation between presentation (the nodes) and the model, which makes it very cumbersome to be used in a EE context. We implemented such a separation in the bank, including a complete subtree model spi and node context management, but given this experience IMO util.preferences is too much crap to build a configuration JSR on top of it. Despite the fact that we would only be able to use it in a feasible way, if we would replace the PreferencesFactory, which may be incompatible with people that already did register their own factory.
• most preferences models seem to model a tree of nodes, with properties on the nodes. IMO this has some disadvantages:
• by exposing the tree structure to the API users, you enable clients to cache and access any node in your tree, at any time from any thread. This leads to greater complexity in a multi-threaded, multi-tenancy system, and thus requires more synchronization than would be needed in many cases. In multi-threaded high parallell access this design tends to lead to dead-locks or starvation issues quickly. Especially when preferences nodes are also mutable, like the JDK Preferences API. IMO most of the configuration remains quite stable about an application/servers runtime, so I would argue, to define immutable semantics on the configuration aspects, where possible.
• This means not that configuration cannot change, but I would allow the change by another isolated API, thus separating read of configuration and update of configuration explicitly. Reading clients can also easily be informed on config changes by listening on according ConfigChange events.

So summarizing organizing configuration in a configuration tree (or preferences) would quite probably be a feasible design, when the following points are considered:

• access by default is only reading
  
• the model and the tree structure should be separated, so referenced node instances can be invalidated without harming the whole configuration model.
  
• writing/changing operations are modeled separately.
  
• From each node, access of values by property identifier is still possible (or even encouraged).
  
• Looking at the complexities of complex application product installations (like we have) I additionally would argue, that I would like to access/support several configuration/pref trees:
  
• default trees (corresponding what I called aggregates before) for each default aggregate
• a tree for each scope
• trees for each custom aggregate

Based on such a "low level" representation we might define more advanced services as useful...

-Anatole