You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Tim O'Brien <to...@discursive.com> on 2004/01/13 08:04:50 UTC

[configuration] ConfigurationFactory

Am I correct in observing that initDigesterSectionRules is going to only 
create PropertiesConfiguration, Dom4JConfiguration, and 
Hier...Configuration object which correspond to entries in the file 
system.  If so, any interest in adding the ability to load all three 
types from the classpath?

In addition, it seem that ConfigurationFactory could be (possibly) 
simplified by taking all Digester rule definitions, putting them into an 
XML rule set, and making it extremely explicit.  The only way for an 
end-user to know valid XML structure is to reverse engineer the Digester 
rules in ConfigurationFactory.

Reactions?

Tim


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


Re: [configuration] ConfigurationFactory

Posted by Oliver Heger <he...@med.uni-marburg.de>.
Emmanuel Bourg schrieb:

> 
> Tim O'Brien wrote:
> 
>> Am I correct in observing that initDigesterSectionRules is going to 
>> only create PropertiesConfiguration, Dom4JConfiguration, and 
>> Hier...Configuration object which correspond to entries in the file 
>> system.  If so, any interest in adding the ability to load all three 
>> types from the classpath?
> 
> 
> Why not.
The URLs provided for the (sub) configurations are resolved relatively 
to the URL from which the ConfigurationFactory object is loaded. So if 
the ConfigurationFactory itself is loaded from a URL (e.g. specifying a 
jar or a classpath entry), the sub elements can also be retrieved from 
there. (Of course it is possible to specify absolute URLs, too.)

But you are right, if the XML file of the ConfigurationFactory is loaded 
from a file, you cannot load configurations from the classpath.

Oli

> 
> 
>> In addition, it seem that ConfigurationFactory could be (possibly) 
>> simplified by taking all Digester rule definitions, putting them into 
>> an XML rule set, and making it extremely explicit.  The only way for 
>> an end-user to know valid XML structure is to reverse engineer the 
>> Digester rules in ConfigurationFactory.
> 
> 
> It seems Eric commited an XML rule set in /conf last month but it's only 
> used in TestConfigurationFactory. This change would cut some code, that 
> seems interesting, however it would not replace a tutorial or a DTD to 
> document the file format properly.
> 
> Emmanuel Bourg
> 



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


Re: [configuration] ConfigurationFactory

Posted by Emmanuel Bourg <e....@cross-systems.com>.
Tim O'Brien wrote:
> Am I correct in observing that initDigesterSectionRules is going to only 
> create PropertiesConfiguration, Dom4JConfiguration, and 
> Hier...Configuration object which correspond to entries in the file 
> system.  If so, any interest in adding the ability to load all three 
> types from the classpath?

Why not.


> In addition, it seem that ConfigurationFactory could be (possibly) 
> simplified by taking all Digester rule definitions, putting them into an 
> XML rule set, and making it extremely explicit.  The only way for an 
> end-user to know valid XML structure is to reverse engineer the Digester 
> rules in ConfigurationFactory.

It seems Eric commited an XML rule set in /conf last month but it's only 
used in TestConfigurationFactory. This change would cut some code, that 
seems interesting, however it would not replace a tutorial or a DTD to 
document the file format properly.

Emmanuel Bourg