[Configuration]Problems with JNDIConfiguration - was ConfigurationFactory and hierarchicalDom4j

[Oliver Heger <Ol...@t-online.de>]

When trying to add a unit test to check all XML elements supported by 
ConfigurationFactory I faced a problem with JNDIConfiguration. This 
class seems to be incompatible with ConfigurationFactory when used in 
the <additional> section.

I did not much further research, but I suspect that the problem is in 
getKeys(), which always returns an empty iterator though getString() 
returns values for some keys. I also found out that the getProperty() 
method always throws an exception which would cause further problems if 
a correct iterator was returned. I suppose it would be better to 
delegate to getString() instead(?).

Attached is a patch for TestConfigurationFactory that demonstrates the 
problem. The other file is a configuration definition file that must be 
placed in the conf directory.

Oliver

Eric Pugh wrote:

>Okay, I put the missing code back in..   It would be nice to have a unit test that caught that.
>
>Eric
>
>  
>
>>-----Original Message-----
>>From: Oliver Heger [mailto:hegero@med.uni-marburg.de]
>>Sent: Friday, January 23, 2004 11:07 AM
>>To: Jakarta Commons Developers List
>>Subject: Re: ConfigurationFactory and hierarchicalDom4j
>>
>>
>>This is strange: If you have a look at the source xrefs for the 
>>ConfigurationFactory class at 
>>http://jakarta.apache.org/commons/configuration/xref/org/apach
>>e/commons/configuration/ConfigurationFactory.html
>>you will see that the missing rule is present. So it must have been 
>>accidently deleted in one of the last commits(?).
>>Oliver
>>
>>Eric Pugh schrieb:
>>
>>    
>>
>>>Oliver, would you like to submit a patch for this?  Also, 
>>>      
>>>
>>if you could submit a unit test showing the problem..  Not 
>>good when all the unit tests pass, but a bug still exists!
>>    
>>
>>>In terms of a release, basically we are just wrangling over 
>>>      
>>>
>>whether to throw a ConfigurationException..  At this point, 
>>the feeling seems to be that no good solution really exists 
>>right now.  We need (in Configuration 2 or 1.5 or whatever) 
>>to refactor the process of loading a configuration object 
>>from the process of having a configuration object.   That way 
>>cool stuff like multiple reloading strategies etc become possible.
>>    
>>
>>>At this point, there are a coupld throws Exception that I 
>>>      
>>>
>>am going to replace with a checked 
>>ConfigurationInitializationException or ConfigurationLoadException...
>>    
>>
>>>So, 1.0 is coming down the pike very soon..   
>>>
>>>Eric
>>>  -----Original Message-----
>>>  From: Oliver Kim [mailto:Oliver.Kim@TELUS.COM]
>>>  Sent: Friday, January 23, 2004 8:27 AM
>>>  To: epugh@upstate.com; hps@intermeta.de; oliver.heger@t-online.de
>>>  Subject: ConfigurationFactory and hierarchicalDom4j
>>>
>>>
>>>  You guys probably would have figured this out pretty 
>>>      
>>>
>>quickly, but since I found it, I thought I'd let you know...
>>    
>>
>>>  The following code snipped should contain a rule for 
>>>      
>>>
>>hierarchicalDom4j:
>>    
>>
>>>      protected void initDigesterSectionRules(Digester digester,
>>>      String matchString, boolean additional)
>>>      {
>>>          setupDigesterInstance(
>>>              digester,
>>>              matchString + "properties",
>>>              new 
>>>      
>>>
>>BasePathConfigurationFactory(PropertiesConfiguration.class),
>>    
>>
>>>              METH_LOAD,
>>>              additional);
>>>          setupDigesterInstance(
>>>              digester,
>>>              matchString + "dom4j",
>>>              new 
>>>      
>>>
>>BasePathConfigurationFactory(DOM4JConfiguration.class),
>>    
>>
>>>              METH_LOAD,
>>>              additional);
>>>          setupDigesterInstance(
>>>              digester,
>>>              matchString + "jndi",
>>>              new JNDIConfigurationFactory(),
>>>              null,
>>>              additional);
>>>      }
>>>
>>>
>>>  Like so:
>>>
>>>      protected void initDigesterSectionRules(Digester digester,
>>>      String matchString, boolean additional)
>>>      {
>>>          setupDigesterInstance(
>>>              digester,
>>>              matchString + "properties",
>>>              new 
>>>      
>>>
>>BasePathConfigurationFactory(PropertiesConfiguration.class),
>>    
>>
>>>              METH_LOAD,
>>>              additional);
>>>          setupDigesterInstance(
>>>              digester,
>>>              matchString + "dom4j",
>>>              new 
>>>      
>>>
>>BasePathConfigurationFactory(DOM4JConfiguration.class),
>>    
>>
>>>              METH_LOAD,
>>>              additional);
>>>          setupDigesterInstance(
>>>              digester,
>>>              matchString + "hierarchicalDom4j",
>>>              new 
>>>      
>>>
>>BasePathConfigurationFactory(HierarchicalDOM4JConfiguration.class),
>>    
>>
>>>              METH_LOAD,
>>>              additional);
>>>          setupDigesterInstance(
>>>              digester,
>>>              matchString + "jndi",
>>>              new JNDIConfigurationFactory(),
>>>              null,
>>>              additional);
>>>      }
>>>
>>>  It seems to work fine once you do this.
>>>
>>>  As an aside?  How close do you think Configuration is to 
>>>      
>>>
>>release?  I'm considering using it in one of my projects.
>>    
>>
>>>  Thanks,
>>>
>>>  Oliver Kim
>>>      
>>>
>>-- 
>>Oliver Heger
>>Zentrale Informationsverarbeitung (ZIV) / Bereich Anwenderverfahren
>>Klinikum der Philipps-Universität Marburg
>>Bunsenstraße 3,
>>D-35037 Marburg
>>Tel: +49 6421 28-66592
>>mailto:oliver.heger@med.uni-marburg.de
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>    
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>  
>