Welcome to Commons!

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