Jini 2.0 Configuration Files

[hammett <ha...@apache.org>]

Jini 2.0 was just released. It supports a new type of configuration files
that is very interesting (at least to me). In fact there is a
ConfigurationProvider that exposes Configuration implementations. By now the
only Configuration implementation is the ConfigurationFile.

The ConfigurationFile supports a subset of Java code! So a use could be:

  Configuration config =
            ConfigurationProvider.getInstance("my_config_file.config");

  ExpectedClass instance = (ExpectedClass) config.getEntry(
            "mynamespace.myclass.mysettingkey",
            "objectname",
            ExpectedClass.class);

And the my_config_file.config file:

import mynamespace.*;

mynamespace.myclass.mysettingkey
{
    objectname = new ExpectedClass("someconfig");
}

mynamespace.myclass.mysettingkey2
{
    map = new HashMap();
    map.add( "key", "value");
}


I think it's a evolution and should be considered as a different
configuration strategy that avalon could support.
More on that can be found at
http://pandonia.canberra.edu.au/java/jini/tutorial/Config.xml


Thoughs?

hammett


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: Jini 2.0 Configuration Files

[Leo Simons <le...@apache.org>]

hammett wrote:
> Jini 2.0 was just released. It supports a new type of configuration
<snip/>
> The ConfigurationFile supports a subset of Java code
<snip/>
> Thoughs?

well....ugh! A *real* scripting language works much nicer IMNSHO....for 
example, you can use BeanShell to not support a subset of java, but a 
superset that is very clean!

One could also use javascript, python, ruby, whatever. Once you make the 
(sometimes, admittedly questionable) decision that your configuration is 
allowed to "act" directly on your component (as opposed to the 
conceptually very clean avalon-style configuration where a component is 
allowed to "read" from its configuration, but the configuration itself 
is passive), it makes no sense at all to invent a new language (be it 
Jelly, Droolz, xmlbeans, or Jini 2.0 config files).

Here's an example of how simple this actually is:
---
Object getComponent( Factory factory, Container container ) // fragment
     throws ConfigurationException
{
   ComponentEntry entry = factory.getEntry( /* ... */ );
   InputStream script = entry.getConfigScript();

   Interpreter i = new Interpreter();

   try
   {
     i.set( "entry", entry );
     i.set( "container", container );
     i.source( script ); // actual configuration at this point

     return i.get( "component" );
   }
   catch( Error e )
   {
     throw new ConfigurationException( e );
   }
}
---
your config script might look like:
---
component = entry.getInstance();
component.setParameter( container.get( "someDependencyKey" ) );
component.setBlah( container.get( "somethingelse" ) );
---

cheers!

- Leo



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org