BlueMold Commons is a configuration framework and collection of tools,
grown out of a need for simplicity. Designed to be used easily with minimal code and effort.
The focus is on improving the speed of development while reducing complexity and simplifying
maintenance. Usage of the framework can be minimal or extensive and can
easily be applied after the fact to an existing project.
An average developer should be able to use a framework without being a guru or
needing to study technical manuals to "unlock" a framework's usefulness.
The Commons starts with a configuration framework and continues with additional
components built on that framework. By thinking of components as configuration driven resources,
the framework starts with a base abstraction for resource from which all other components are
derived. The framework includes logging, factory abstractions, properties and bean factories.
All of these components are straight forward, can be used right away without
any configuration since their default settings are used when there is no configuration present.
Configuration is always an afterthought, so let's not try to engineer human nature.
Instead lets make refactoring as simple as possible. Configuration should be easy to
introduce in small steps. Testing usually gets put last as well. Configuration and testing go hand in hand
where one can be used to accomplish the other. Tests need to be created that run
many different configurations and testing can be driven by configuration.
We need to make this simple to do even when
procrastination and the pursuit of more interesting things makes this the last consideration.
To make components work well in a multitude of situations with little to no configuration,
the framework takes advantage of the classloader hierarchy and treats each classloader as a separate context.
Each context inherits it's configuration from it's parent
and then provides overriding values for it's own configuration.
This introduces a few object oriented principles to configuration.
Let's look at an example, the classes in one classloader can be configured to use log4j
for logging and the classes in another classloader can be configured to use apache commons logging.
Meanwhile the parent classloader is using java logging, which is default and requires no explicit configuration.
Finally forth classloader is inheriting the use of java logging from the configuration in the parent classloader.
Let's look at another example. Suppose there is a singleton class that represents an icon image.
Upon initialization the class will attempt to locate an image file and load it for use.
By default the configuration provides default locations with precedence and even a default icon file in the
classpath along side the singleton class. The singleton's precedence places an values provided by the configuration
first followed by a location in the working directory under resources and finally the location of the
default icon file in the classpath. This precedence allows the resource to be overridden
in a couple simple ways. From the application's perspective it does not matter. The application simply asks for an
instance of the icon class to use for rendering.
Resources can be simple and static or be configurable or pull data from an external source like a file.
Resources can also be capable of pulling data from multiple sources especially when those sources
are designed to override one another. This bring up another feature of the framework. Overridden configuration values
can be used to provide precedence rather than simple overriding. Take for example a bean factory.
For the parent context the location of a bean definition file is specified where as
a child context has the location of an overriding bean definition file. The child context then
has the same beans available to the parent context except for those replaced by the overriding bean definition.
To obtain a binary distribution or the source go to the
BlueMold Commons project on SourceForge.net