MicroBean Configuration

This is the second of a series of posts on some of the personal projects I’ve been working on.  As I hope you’ll see, they all fit together.  The previous post covered MicroBean Configuration API.  The next post covers MicroBean Configuration CDI.

This post covers MicroBean Configuration.  Its website is here, its source code is here and its binaries are available from Maven Central.

MicroBean Configuration is a concrete implementation of MicroBean Configuration API.  Users of MicroBean Configuration API need to know about this project only because it is one possible implementation of the API.  Once it is installed, they do not need to call it.

To install MicroBean Configuration, place its jar file in your classpath.  A call to MicroBean Configuration API‘s Configurations#newInstance() will now succeed.

MicroBean Configuration implements MicroBean Configuration API by providing an implementation of the Configurations class, and by defining a raftload of converters, together with an SPI for defining more.

MicroBean Configuration is written assuming that there will be several, disparate individual configuration systems that it will “front”.  Each is treated as a configuration—that is, a collection of configuration values.  Each is required—when asked for a named configuration value—to not only return the value, but some configuration coordinates for which it is suitable.  This then lets the Configurations class select the maximally specific configuration value from those returned.  I’ve written extensively about configuration coordinates and their importance elsewhere in this blog.

One area worth calling out explicitly is MicroBean Configuration‘s support for resolving configuration disputes.  A configuration dispute arises when two Configurations provide different configuration values with the same specificity, but different configuration coordinates.  For example, one Configuration might return a value suitable for the test environment and the experimental phase (I am making up these axes).  Another might return a value suitable for the experimental phase and the current user.  Both are equally specific given a set of application configuration coordinates that includes the current user, the test environment and the experimental phase.  Which should be chosen?  MicroBean Configuration allows pluggable Arbiters whose job is to resolve disputes such as this.

By default, MicroBean Configuration ships with a Configuration that represents Java system properties.  Other Configuration implementations are planned to front other popular configuration frameworks.

In the next post, we’ll see how MicroBean Configuration API, backed by an implementation such as MicroBean Configuration, can be exposed in a CDI 2.0 environment.