(this page is part of the wiki materials for ApacheAvalon; avalon main page in the wiki is AvalonProjectPages)
One of the most common ways that developers work with JavaBeans is to use them as an interface for configuring a component. It makes sense because of all the tooling that comes for free with the java.beans package. Nevertheless there are a number of problems with the JavaBean approach, so they fall short on a number of points.
Avalon Framework has a Configuration and Parameters object that allows us to provide rich configuration options without a lot of overhead. Because there is a standard interface, all users of the Configuration and Parameters objects know how to use them directly. They are really strong on a number of points--mainly because they are focused on one purpose, storing settings for components.
JavaBeans were Java's first stab at reusable components. The concept was pretty cool, but very muched tied to GUI programming. A JavaBean would expose a standard set of properties that were externally editable, and the client of the JavaBean would change the properties to make the bean perform the way that they wanted. Part of the process also allowed for introspection--the process of discovering the beans properties, events, and more by examining the exposed methods.
As a result, we can look at the JavaBeans setter/getter idiom as a form of managing configuration settings. Autodiscovery of properties allows the bean writer to add and remove configuration settings from a bean without destroying software that is already written. As an additional benefit, you have strongly typed properties for each configuration point. From the bean or component writer, there is alot of power in that process--but at an equally high price. Reading and assigning properties using introspection is anywhere between 9x and 15x slower than directly setting the properties.
To escape the necessity for introspection, bean writers tend to agree on a standard set of properties (like the javax.sql.DataSource specification) and then use introspection for vendor specific properties. The advantage of this approach is that if a bean does not support a property, it won't cease to work. Also, the client can directly call a number of methods that they *know* will exist--no matter what vendor supplies the beans.
Avalon's Configuration and Parameters (from this point referred collectively as Configuration) are a very simple tool. Its power lies in its simplicity and its focus. A component can have strongly typed configuration elements, as long as they are one of Java's primitive types or a java.lang.String. In 99% of all cases, that is all a user needs.
Because of the Configuration process, components can easily read the settings and containers can easily manage the settings. More importantly, neither side of the equation (user or provider) needs to use introspection to ever set all the properties for a component. This reduces the *need*
for complex tooling, and increases productivity because we are not concerned with writing complex glue logic or wondering how the magick is performed. When we look at the code for the component and the code for the container, we know exactly what each is doing.
We can easily boil Avalon Configuration into a namespace for configuration points. The Configuration object (as opposed to the Parameters object) allows us to find settings in a heirarchical namespace. The Parameters object allows us to find settings in a flat namespace. Nevertheless, we are using names in either case to find what we want.
What is really better?
That reduces the amount of temporary objects created. |
That makes validation a matter of checking method signatures. |
Nothing special has to be done. |
If you don't catch all the potential runtime exceptions, you're application will crash. |
That may be even more difficult if a group of settings need to be made at one time. |
It requires external MetaData to perform its functions. |
That creates more work for the garbage collector. |
Should we make all Configuration based on a namespace? Should we look at the use of JavaBeans as dumb configuration objects? The latter approach is used by Tomcat and other projects. How do we make it *easy* for a component writer to configure their components, and for the container writer to verify the configuration is valid?