river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Grahn <jgr...@simulexinc.com>
Subject Re: Groovy Configuration
Date Thu, 12 Mar 2009 15:58:41 GMT
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.


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

View raw message