Seems like an improvement to me. Since Groovy objects and Java objects
are equivalent in the JVM, does Groovy configuration also leave open the
possibility of a pure Java approach if you desire that as well?
If so, being able to pass in a Java object for initialization purposes
for tests and dynamic loading would be another plus for this approach.
jamesG
Dennis Reedy wrote:
Hi,
While doing some work on a project where I wanted to create a Map of
elements derived from a Jini configuration I came to the usual crashing
halt because the current Jini configuration approach provides Java-like
syntax, but does not provide any 'real' semantics.
So as a way to get what I wanted done (inspired by what Van Simmons had
done with the Compute Server project), I came up with an approach to
use Groovy classes that can be used as a source with the Jini
configuration approach.
The Jini configuration approach defines an interface for obtaining
objects needed to configure applications, such as Exporter or
ProxyPreparer instances, or other application-specific objects, from
configuration files, databases, or other sources. Configuration entries
are identified by a component and a name.
For example, using the following Groovy class:
@Component('french.fry.bean')
class BeanConfig {
Map getServiceMap() {
Map serviceMap = [ 'foo' : new org.rioproject.core.ServiceElement()]
return serviceMap
}
}
One could obtain the serviceMap property using the
Configuration.getEntry() method as follows:
Map<String, ServiceElement> serviceMap =
(Map<String, ServiceElement>)config.getEntry("french.fry.bean",
"serviceMap",
Map.class);
Although this example is trivial, I think you can see the advantage of
using Groovy (POGOs) instead of the static configuration file approach.
All entries you look for will be properties in the Groovy class. They
can be constructed using logic, closures, whatever, and return the value
for the entry accordingly. We also have the advantage of creating
hierarchies of configuration, where POGO configs extend base
configuration classses, provided a much nicer 'overrides' capability
then the approach currently offered with the existing configuration
approach. IMO, this is much more powerful than what we have now, and
also easier to understand.
We have converted all the configuration files in Rio over to POGOs, the
appropriate ConfigurationProvider wiring has been provided, and we
really like it.
I wanted to post this to see if there was any interest on adding this
sort of a capability to River, and to solicit any comments.
Regards
Dennis
