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.

MicroBean Configuration API

This is the first 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 next post in the series covers MicroBean Configuration.

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

MicroBean Configuration API is a Java SE API that abstracts over collections of configuration values.  In this regard it is no different from many other Java configuration APIs.  Like many other configuration frameworks, configuration values are always Strings and can be converted.

Where perhaps it is different is: it expresses configurations—collections of configuration values—in terms of their location in configuration space as determined by configuration coordinates.  Other systems tend to use hierarchies of configuration values, but of course configuration space is not hierarchical so there are always problems with the hierarchical approach.

(Also, other systems use configuration coordinates whether they are fully cognizant of what they’re doing or not—one only has to look at the separation of “user” from “system” values in systems like the Java Preferences API.)

Configuration space as an abstract concept is the universe of all configurations.  Some configurations are suitable for certain application deployments and many are not.  Usually there’s one that is suitable for nearly all application deployments of a particular kind, but that one is generally very “defaultish” (one step away from hard-coded values).  For a given application deployment, you want, of course, the maximally specific configuration to apply to it.  To pick this configuration out from all others, you supply configuration coordinates that locate your application deployment in configuration space, and then MicroBean Configuration API finds the most specific or suitable configuration that exists for it.

Sometimes an application is aware of its own configuration coordinates, or the configuration coordinates that it wants to use when seeking a configuration value.  Other times—the vast majority of times—it is not (they are specified “outside” of it, as in the case of other Java configuration frameworks where you “pass in” notions of a “project stage” or other means of locating configuration values suitable for the deployment).  MicroBean Configuration API offers two fundamental flavors of the getValue() method (with convenience overrides) for these two cases: one for getting a configuration value when the configuration coordinates are known, and one for when they are supplied implicitly.

To make MicroBean Configuration API work, you’ll need a concrete implementation of it. Currently there is one implementation—MicroBean Configuration—which is two things: one, a concrete implementation of MicroBean Configuration API, of course, and two, a multiplexing variant of it (i.e. it can front many other configuration systems).  We’ll cover MicroBean Configuration in the next post.