Re: [loom] [dna] Properties in component configurations

Whether I go with the ConfigUtil or a pre-processor, I think we still 
have an issue with regard to portable components.  If someone writes a 
block with properties in its configuration using loom and then tries to 
deploy on a container that does not provide this functionality, they 
will get a nasty surprise.

I guess using a component dependency is overkill, but complete 
transparency doesn't sound right to me either.

Once we come up with something I am volunteering to implement it, Jason 
did all the work for me anyway it seems.

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net

Peter Donald wrote:

>I definetly prefer this way. If I understand you correctly what you want to be 
>able to do is something like variable interpolation in configuration ala
>
><foo>
>  <dir>${loom.home}</dir>
></foo>
>
>If you look in the CLIMain class in Loom you will see that we actually do this 
>for kernel.xml. 
>
>final Properties params = new Properties();
>params.setProperty( "loom.home", home.getAbsolutePath() );
>final Configuration root = ConfigUtil.expandValues( original, params );
>
>So loom.home will be expanded in config xml. You could easily expand this to 
>work with all components aswell. Maybe expand a set of default properties + 
>any defined in SAR-INF/config.properties or something.
>
>Alternatively you could use Jexl (http://jakarta.apache.org/commons/jexl) to 
>expand properties (which is what maven uses). Jexl is good in that you get to 
>do manipulation on objects (string caternating or cutting etc) and can invoke 
>methods etc on values.
>
>The final method would be to treat the whole config.xml as a jelly script and 
>process it. 
>
>The ConfigUtil post-processes the configuration after parsing but a far better 
>approach would be to write an XMLFilterImpl that expands the variables it 
>finds etc.
>
>  
>