You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Borut Bolčina <bo...@najdi.si> on 2006/01/26 09:21:24 UTC
[Configuration] Wish list
Hi,
I've been using Commons Configuration successfully in several projects.
Besides XPath support I have 3 more feature wishes:
*[1] Getting Properties out of Configuration*
When using already written software components, some methods take
Properties as input parameter. If using CompositeConfiguration as a
central point for accesing properties, it would be desirable to get
Properties out of PropertiesConfiguration which is part of
CompositeConfiguration. Example of wanted functionality:
Configuration propertiesConfiguration = config.getConfiguration(2);
Properties properties = propertiesConfiguration.getProperties();
Asume 3rd entry in configuration.xml is <properties>.
*[2] Inclusion of DatabaseConfiguration in configuration.xml*
It woould be nice to introduce something like <database> tag in
configuration.xml. The content of the tag would be connection string for
the database. Example:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<configuration>
<xml fileName="prop1.xml"/>
<xml fileName="prop2.xml"/>
<properties fileName="prop3.properties"/>
<database
connect="jdbc:mysql://delovc10.noviforum.si/feeds?user=foo&password=bar"/>
</configuration>
*[3] Getting configurations out of configuration.xml could be done by
name and not by index.*
So, instead of
config.getConfiguration(2)
one could write
config.getConfiguration("entryThree");
A new attribute for each entry should be introduced, something like:
<configuration>
<xml id="entryOne" fileName="prop1.xml"/>
<xml id="entryTwo" fileName="prop2.xml"/>
<properties id="entryThree" fileName="prop3.properties"/>
<database id="entryFour"
connect="jdbc:mysql://delovc10.noviforum.si/feeds?user=foo&password=bar"/>
</configuration>
What do you think?
Regards,
Borut Bolčina
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [Configuration] Wish list
Posted by Oliver Heger <ol...@t-online.de>.
Borut Bolčina wrote:
> Hi, sorry for late response, quite busy days...
>
> On 28.1.2006 11:45, Oliver Heger wrote:
>
>>Borut Bolčina wrote:
>>
>>
>>
>>>Hello Oliver,
>>>I understand now. I suppose each configuration class can have a well
>>>defined set of accessor methods (settings) that can be included in
>>>configuration.xml. If so, then making a schema is a no-brainer.
>>>
>>>
>>
>>That's correct, but we need to keep in mind that new accessor methods
>>may be added in a new release. Then the schema has to be updated.
>>
>>
> Yes. There should be versioned shemas on some public server. I guess
> API should not change several times a year.
>
>>
>>
>>>When agreed upon, you can send me sample example files and I will make
>>>an XML Schema (xsd).
>>>
>>>bye,
>>>Borut
>>>
>>>
>>
>>Okay, the skeleton of a configuration definition file looks like the
>>following:
>>
>><configuration>
>> <override>
>> <!-- Definition of configuration sources that override properties -->
>> </override>
>> <additional>
>> <!-- Definition of configuration sources that are combined -->
>> </additional>
>></configuration>
>>
>>Both the <override> and <additional> elements are optional. It is
>>possible that configuration sources are defined outside these elements
>>(i.e. as direct children of the root node), then they are treated as if
>>they were placed inside an <override> section. (This is perhaps a bit
>>ugly, but I fear we will have to keep this because of backwards
>>compatibility.)
>>
>>
> I think it can be done, but yes, it is ugly.
>
>>A definition of a configuration source at the moment simply consists of
>>one of the tags mentioned in the howto about ConfigurationFactory
>>(http://jakarta.apache.org/commons/configuration/howto_configurationfactory.html).
>>It can have attributes that correspond to the setter methods defined in
>>the configuration class represented by this tag (the information, which
>>class is used by which tag can also be found in the howto document,
>>section "The configuration definition file"). I think it will be
>>necessary to look up the JavaDocs for these classes to find out the set
>>of attributes needed by a tag.
>>
>>
> I'll look it up.
>
>>Currently only primitive values can be set this way. I would like to
>>enhance this to also support arbitrary objects. This will be required
>>for things like reloading strategies or expression engines. My idea
>>about how such a complex declaration could look like is to define these
>>object settings as sub elements of the tag for the configuration source,
>>e.g.:
>>
>><properties fileName="my.properties">
>> <reloadingStrategy
>>class="o.a.c.configuration.reloading.FileChangedReloadingStrategy"
>> refreshDelay="10000"/>
>></properties>
>>
>>The sub elements' names would correspond to the names of the setter
>>methods in the configuration class. In theory this game could be
>>continued if the object defined in the sub element has itself complex
>>settings, which in turn could be defined in sub (sub) elements. I guess,
>>here it becomes complex, but such a format would really be convenient to
>>setup your configurations.
>>
>>
> Those objects can be accounted for by *any* element in schema
> language, but this means some sections of the configuration file will
> not be validated. Since the majority of them will be simple, a shema
> will cover most user needs. In case some complex objects
> initialization will become more common, their validation can be added
> into the schema later.
>
>>What do you think? Is this all information you need for a schema?
>>
>>
> For starters yes.
>
>>Oliver
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>>
>>
> --
> bLOG <http://www.delo.si/blog/borutb/>
>
Sounds good! I hope I find some time soon to start with the
implementation of the enhanced features for ConfigurationFactory. Then
the XML format will become more specific.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [Configuration] Wish list
Posted by Borut Bolčina <bo...@najdi.si>.
Hi, sorry for late response, quite busy days...
On 28.1.2006 11:45, Oliver Heger wrote:
> Borut Bolčina wrote:
>
>
>> Hello Oliver,
>> I understand now. I suppose each configuration class can have a well
>> defined set of accessor methods (settings) that can be included in
>> configuration.xml. If so, then making a schema is a no-brainer.
>>
>
> That's correct, but we need to keep in mind that new accessor methods
> may be added in a new release. Then the schema has to be updated.
>
Yes. There should be versioned shemas on some public server. I guess API
should not change several times a year.
>
>> When agreed upon, you can send me sample example files and I will make
>> an XML Schema (xsd).
>>
>> bye,
>> Borut
>>
>
> Okay, the skeleton of a configuration definition file looks like the
> following:
>
> <configuration>
> <override>
> <!-- Definition of configuration sources that override properties -->
> </override>
> <additional>
> <!-- Definition of configuration sources that are combined -->
> </additional>
> </configuration>
>
> Both the <override> and <additional> elements are optional. It is
> possible that configuration sources are defined outside these elements
> (i.e. as direct children of the root node), then they are treated as if
> they were placed inside an <override> section. (This is perhaps a bit
> ugly, but I fear we will have to keep this because of backwards
> compatibility.)
>
I think it can be done, but yes, it is ugly.
> A definition of a configuration source at the moment simply consists of
> one of the tags mentioned in the howto about ConfigurationFactory
> (http://jakarta.apache.org/commons/configuration/howto_configurationfactory.html).
> It can have attributes that correspond to the setter methods defined in
> the configuration class represented by this tag (the information, which
> class is used by which tag can also be found in the howto document,
> section "The configuration definition file"). I think it will be
> necessary to look up the JavaDocs for these classes to find out the set
> of attributes needed by a tag.
>
I'll look it up.
> Currently only primitive values can be set this way. I would like to
> enhance this to also support arbitrary objects. This will be required
> for things like reloading strategies or expression engines. My idea
> about how such a complex declaration could look like is to define these
> object settings as sub elements of the tag for the configuration source,
> e.g.:
>
> <properties fileName="my.properties">
> <reloadingStrategy
> class="o.a.c.configuration.reloading.FileChangedReloadingStrategy"
> refreshDelay="10000"/>
> </properties>
>
> The sub elements' names would correspond to the names of the setter
> methods in the configuration class. In theory this game could be
> continued if the object defined in the sub element has itself complex
> settings, which in turn could be defined in sub (sub) elements. I guess,
> here it becomes complex, but such a format would really be convenient to
> setup your configurations.
>
Those objects can be accounted for by *any* element in schema language,
but this means some sections of the configuration file will not be
validated. Since the majority of them will be simple, a shema will cover
most user needs. In case some complex objects initialization will become
more common, their validation can be added into the schema later.
> What do you think? Is this all information you need for a schema?
>
For starters yes.
> Oliver
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
--
bLOG <http://www.delo.si/blog/borutb/>
Re: [Configuration] Wish list
Posted by Oliver Heger <ol...@t-online.de>.
Borut Bolčina wrote:
> Hello Oliver,
> I understand now. I suppose each configuration class can have a well
> defined set of accessor methods (settings) that can be included in
> configuration.xml. If so, then making a schema is a no-brainer.
That's correct, but we need to keep in mind that new accessor methods
may be added in a new release. Then the schema has to be updated.
> When agreed upon, you can send me sample example files and I will make
> an XML Schema (xsd).
>
> bye,
> Borut
Okay, the skeleton of a configuration definition file looks like the
following:
<configuration>
<override>
<!-- Definition of configuration sources that override properties -->
</override>
<additional>
<!-- Definition of configuration sources that are combined -->
</additional>
</configuration>
Both the <override> and <additional> elements are optional. It is
possible that configuration sources are defined outside these elements
(i.e. as direct children of the root node), then they are treated as if
they were placed inside an <override> section. (This is perhaps a bit
ugly, but I fear we will have to keep this because of backwards
compatibility.)
A definition of a configuration source at the moment simply consists of
one of the tags mentioned in the howto about ConfigurationFactory
(http://jakarta.apache.org/commons/configuration/howto_configurationfactory.html).
It can have attributes that correspond to the setter methods defined in
the configuration class represented by this tag (the information, which
class is used by which tag can also be found in the howto document,
section "The configuration definition file"). I think it will be
necessary to look up the JavaDocs for these classes to find out the set
of attributes needed by a tag.
Currently only primitive values can be set this way. I would like to
enhance this to also support arbitrary objects. This will be required
for things like reloading strategies or expression engines. My idea
about how such a complex declaration could look like is to define these
object settings as sub elements of the tag for the configuration source,
e.g.:
<properties fileName="my.properties">
<reloadingStrategy
class="o.a.c.configuration.reloading.FileChangedReloadingStrategy"
refreshDelay="10000"/>
</properties>
The sub elements' names would correspond to the names of the setter
methods in the configuration class. In theory this game could be
continued if the object defined in the sub element has itself complex
settings, which in turn could be defined in sub (sub) elements. I guess,
here it becomes complex, but such a format would really be convenient to
setup your configurations.
What do you think? Is this all information you need for a schema?
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [Configuration] Wish list
Posted by Borut Bolčina <bo...@najdi.si>.
Hello Oliver,
I understand now. I suppose each configuration class can have a well
defined set of accessor methods (settings) that can be included in
configuration.xml. If so, then making a schema is a no-brainer. When
agreed upon, you can send me sample example files and I will make an XML
Schema (xsd).
bye,
Borut
Oliver Heger pravi:
> Borut Bolčina wrote:
>
>
>> On 26.1.2006 20:53, Oliver Heger wrote:
>>
>>
>>> If a schema is capable to deal with the required flexibility, it would
>>> be really cool to have one. However the XML can become very variable:
>>>
>>> One feature that is already supported is the ability of setting
>>> properties on the newly created Configuration objects. For instance you
>>> can write something like that:
>>>
>>> <properties fileName="..." lineDelimiter=";"
>>> throwExceptionOnMissing="true"/>
>>>
>>>
>> Hmmm. IMO setting properties like this isn't in the spirit of
>> separating concerns. Putting entries in this configuration for
>> configurations file (we are talking about configuration.xml aren't
>> we?) introduces another place to look for keys and values. That is
>> added complexity. It should be just as easy to have this entries in
>> regular property file referenced by configuration.xml entry. Don't you
>> think? What is this added value to justify the above example?
>>
>
> This is probably a missunderstanding. Yes, we are talking about the XML
> file read by ConfigurationFactory. In this file you define your
> configuration objects. Each configuration class can have a set of fields
> (and corresponding accessor methods) that control their behavior, e.g.
> setThrowExceptionOnMissing() or setListDelimiter() (both defined in
> AbstractConfiguration). There must be a way of setting values for these
> fields in the configuration definition file. Otherwise you are forced to
> call these methods by hand after you have retrieved the
> CompositeConfiguration from the ConfigurationFactory.
>
> Oliver
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
--
bLOG <http://www.delo.si/blog/borutb/>
--
Naključna *izjava tedna* iz tednika Mladina:
Re: [Configuration] Wish list
Posted by Oliver Heger <ol...@t-online.de>.
Borut Bolčina wrote:
>
> On 26.1.2006 20:53, Oliver Heger wrote:
>
>> If a schema is capable to deal with the required flexibility, it would
>> be really cool to have one. However the XML can become very variable:
>>
>> One feature that is already supported is the ability of setting
>> properties on the newly created Configuration objects. For instance you
>> can write something like that:
>>
>> <properties fileName="..." lineDelimiter=";"
>> throwExceptionOnMissing="true"/>
>>
>
> Hmmm. IMO setting properties like this isn't in the spirit of
> separating concerns. Putting entries in this configuration for
> configurations file (we are talking about configuration.xml aren't
> we?) introduces another place to look for keys and values. That is
> added complexity. It should be just as easy to have this entries in
> regular property file referenced by configuration.xml entry. Don't you
> think? What is this added value to justify the above example?
This is probably a missunderstanding. Yes, we are talking about the XML
file read by ConfigurationFactory. In this file you define your
configuration objects. Each configuration class can have a set of fields
(and corresponding accessor methods) that control their behavior, e.g.
setThrowExceptionOnMissing() or setListDelimiter() (both defined in
AbstractConfiguration). There must be a way of setting values for these
fields in the configuration definition file. Otherwise you are forced to
call these methods by hand after you have retrieved the
CompositeConfiguration from the ConfigurationFactory.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [Configuration] Wish list
Posted by Borut Bolčina <bo...@najdi.si>.
On 26.1.2006 20:53, Oliver Heger wrote:
> If a schema is capable to deal with the required flexibility, it would
> be really cool to have one. However the XML can become very variable:
>
> One feature that is already supported is the ability of setting
> properties on the newly created Configuration objects. For instance you
> can write something like that:
>
> <properties fileName="..." lineDelimiter=";"
> throwExceptionOnMissing="true"/>
>
Hmmm. IMO setting properties like this isn't in the spirit of separating
concerns. Putting entries in this configuration for configurations file
(we are talking about configuration.xml aren't we?) introduces another
place to look for keys and values. That is added complexity. It should
be just as easy to have this entries in regular property file referenced
by configuration.xml entry. Don't you think? What is this added value to
justify the above example?
> Here for each property of a concrete configuration implementation a
> corresponding attribute can be specified (this is internally handled by
> Commons-Digester ATM).
>
> There are requests to enhance this initialization syntax to also support
> more complex objects, e.g. reloading strategies. To handle this in a
> generic way I think about implementing a mechanism that allows to
> declare arbitrary objects to be created including their initialization
> parameters.
>
> Could a schema handle such stuff?
>
There is power in XML Schema, but it has its limits. There should be
solid base elements which have (optional) parameters and there can be
elements for which we can not predict their names in advance. Of course
this elements then can't be validated.
-Borut
> Oliver
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [Configuration] Wish list
Posted by Oliver Heger <ol...@t-online.de>.
<snip>
>>
>>>
>>> *[2] Inclusion of DatabaseConfiguration in configuration.xml*
>>> It woould be nice to introduce something like <database> tag in
>>> configuration.xml. The content of the tag would be connection string
>>> for the database. Example:
>>>
>>> <?xml version="1.0" encoding="ISO-8859-1" ?>
>>> <configuration>
>>> <xml fileName="prop1.xml"/>
>>> <xml fileName="prop2.xml"/>
>>> <properties fileName="prop3.properties"/>
>>> <database
>>> connect="jdbc:mysql://delovc10.noviforum.si/feeds?user=foo&password=bar"/>
>>>
>>> </configuration>
>>
>> Of course, DatabaseConfiguration should be supported. In addition I
>> would like to have a mechanism for defining custom tags and including
>> user defined configuration classes.
>
> When I work with (unknown) XML files, the first thing it comes to my
> mind is: "Is there a schema for it?". It really helps building XML
> files and preventing run time errors. I can make XML Schema for
> configuration.xml, and when consolidated with you and other
> developers, should be made available at some URL. Schema can be
> flexible about additional elements you are mentioning.
If a schema is capable to deal with the required flexibility, it would
be really cool to have one. However the XML can become very variable:
One feature that is already supported is the ability of setting
properties on the newly created Configuration objects. For instance you
can write something like that:
<properties fileName="..." lineDelimiter=";"
throwExceptionOnMissing="true"/>
Here for each property of a concrete configuration implementation a
corresponding attribute can be specified (this is internally handled by
Commons-Digester ATM).
There are requests to enhance this initialization syntax to also support
more complex objects, e.g. reloading strategies. To handle this in a
generic way I think about implementing a mechanism that allows to
declare arbitrary objects to be created including their initialization
parameters.
Could a schema handle such stuff?
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [Configuration] Wish list
Posted by Borut Bolčina <bo...@najdi.si>.
Hello Oliver,
On 26.1.2006 12:09, Oliver Heger wrote:
> Hi,
>
> these are some good points. I plan some enhancements for
> ConfigurationFactory and related classes and will take this into
> account. Further comments below.
>
> Borut Bolčina wrote:
>> Hi,
>>
>> I've been using Commons Configuration successfully in several
>> projects. Besides XPath support I have 3 more feature wishes:
>>
>> *[1] Getting Properties out of Configuration*
>> When using already written software components, some methods take
>> Properties as input parameter. If using CompositeConfiguration as a
>> central point for accesing properties, it would be desirable to get
>> Properties out of PropertiesConfiguration which is part of
>> CompositeConfiguration. Example of wanted functionality:
>>
>> Configuration propertiesConfiguration = config.getConfiguration(2);
>> Properties properties = propertiesConfiguration.getProperties();
>>
>> Asume 3rd entry in configuration.xml is <properties>.
> This one has been answered by Jörg.
...and already in my code :-)
>
>>
>> *[2] Inclusion of DatabaseConfiguration in configuration.xml*
>> It woould be nice to introduce something like <database> tag in
>> configuration.xml. The content of the tag would be connection string
>> for the database. Example:
>>
>> <?xml version="1.0" encoding="ISO-8859-1" ?>
>> <configuration>
>> <xml fileName="prop1.xml"/>
>> <xml fileName="prop2.xml"/>
>> <properties fileName="prop3.properties"/>
>> <database
>> connect="jdbc:mysql://delovc10.noviforum.si/feeds?user=foo&password=bar"/>
>>
>> </configuration>
> Of course, DatabaseConfiguration should be supported. In addition I
> would like to have a mechanism for defining custom tags and including
> user defined configuration classes.
When I work with (unknown) XML files, the first thing it comes to my
mind is: "Is there a schema for it?". It really helps building XML files
and preventing run time errors. I can make XML Schema for
configuration.xml, and when consolidated with you and other developers,
should be made available at some URL. Schema can be flexible about
additional elements you are mentioning.
>
>>
>> *[3] Getting configurations out of configuration.xml could be done by
>> name and not by index.*
>> So, instead of
>> config.getConfiguration(2)
>> one could write
>> config.getConfiguration("entryThree");
>>
>> A new attribute for each entry should be introduced, something like:
>> <configuration>
>> <xml id="entryOne" fileName="prop1.xml"/>
>> <xml id="entryTwo" fileName="prop2.xml"/>
>> <properties id="entryThree" fileName="prop3.properties"/>
>> <database id="entryFour"
>> connect="jdbc:mysql://delovc10.noviforum.si/feeds?user=foo&password=bar"/>
>>
>> </configuration>
>>
> This is a feature I have missed myself. Using the subset() method you
> can access specific sets of properties, but sometimes you really need
> access to the Configuration object, e.g. for changing some settings. I
> will implement this.
Using subset() for my case is not applicable. I don't want to merge xml
properties at some element. Feels like workaround, which is exactly what
I want to avoid - that is why I chose Configuration to handle my
properties as uniformly as possible. My code looks much nicer and is way
shorter too!
One other thing. I plan to store 100.000 entries in database properties.
Didn't measure the performance yet. Any comments on that?
Thanks
>
> Oliver
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [Configuration] Wish list
Posted by Oliver Heger <he...@med.uni-marburg.de>.
Hi,
these are some good points. I plan some enhancements for
ConfigurationFactory and related classes and will take this into
account. Further comments below.
Borut Bolčina wrote:
> Hi,
>
> I've been using Commons Configuration successfully in several projects.
> Besides XPath support I have 3 more feature wishes:
>
> *[1] Getting Properties out of Configuration*
> When using already written software components, some methods take
> Properties as input parameter. If using CompositeConfiguration as a
> central point for accesing properties, it would be desirable to get
> Properties out of PropertiesConfiguration which is part of
> CompositeConfiguration. Example of wanted functionality:
>
> Configuration propertiesConfiguration = config.getConfiguration(2);
> Properties properties = propertiesConfiguration.getProperties();
>
> Asume 3rd entry in configuration.xml is <properties>.
This one has been answered by Jörg.
>
> *[2] Inclusion of DatabaseConfiguration in configuration.xml*
> It woould be nice to introduce something like <database> tag in
> configuration.xml. The content of the tag would be connection string for
> the database. Example:
>
> <?xml version="1.0" encoding="ISO-8859-1" ?>
> <configuration>
> <xml fileName="prop1.xml"/>
> <xml fileName="prop2.xml"/>
> <properties fileName="prop3.properties"/>
> <database
> connect="jdbc:mysql://delovc10.noviforum.si/feeds?user=foo&password=bar"/>
> </configuration>
Of course, DatabaseConfiguration should be supported. In addition I
would like to have a mechanism for defining custom tags and including
user defined configuration classes.
>
> *[3] Getting configurations out of configuration.xml could be done by
> name and not by index.*
> So, instead of
> config.getConfiguration(2)
> one could write
> config.getConfiguration("entryThree");
>
> A new attribute for each entry should be introduced, something like:
> <configuration>
> <xml id="entryOne" fileName="prop1.xml"/>
> <xml id="entryTwo" fileName="prop2.xml"/>
> <properties id="entryThree" fileName="prop3.properties"/>
> <database id="entryFour"
> connect="jdbc:mysql://delovc10.noviforum.si/feeds?user=foo&password=bar"/>
> </configuration>
>
This is a feature I have missed myself. Using the subset() method you
can access specific sets of properties, but sometimes you really need
access to the Configuration object, e.g. for changing some settings. I
will implement this.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [Configuration] Wish list
Posted by Oliver Heger <ol...@t-online.de>.
Emmanuel Bourg wrote:
> For this we might provide a simple way of configuring a
> DatabaseConfiguration by fetching a DataSource through JNDI. The
> configuration descriptor would look like this :
>
> <configuration>
> <database jndi="jdbc/MyDB" table="conf" keyColumn="key"
> valueColumn="value"/>
> </configuration>
>
> We may also propose to configure a DataSource using DBCP with
> attributes specifying a driver name, URL, user and password. But I'm
> not sure I want to enter this territory, sooner or later we'll be
> asked to provide a way of configuring the connection pool, changing
> the implementation, tunning the parameters, etc.. and that's not
> really the responsibility of [configuration]. ConfigurationFactory
> should remain a simple way or building a configuration declaratively,
> it should not turn into a complex configuration framework.
>
> Emmanuel Bourg
>
I agree, but we should allow some mechanism to plug in custom
initialization code. So if somebody needs complex configuration, it can
be implemented on top of the existing features.
ATM I am working on a way of declaring objects in configuration files,
which can be used for simple initialization of configuration sources in
a definition file for ConfigurationFactory. I hope I can commit some
results soon.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [Configuration] Wish list
Posted by Emmanuel Bourg <eb...@apache.org>.
Borut Bolčina wrote:
> *[2] Inclusion of DatabaseConfiguration in configuration.xml*
> It woould be nice to introduce something like <database> tag in
> configuration.xml. The content of the tag would be connection string for
> the database. Example:
>
> <?xml version="1.0" encoding="ISO-8859-1" ?>
> <configuration>
> <xml fileName="prop1.xml"/>
> <xml fileName="prop2.xml"/>
> <properties fileName="prop3.properties"/>
> <database
> connect="jdbc:mysql://delovc10.noviforum.si/feeds?user=foo&password=bar"/>
> </configuration>
For this we might provide a simple way of configuring a
DatabaseConfiguration by fetching a DataSource through JNDI. The
configuration descriptor would look like this :
<configuration>
<database jndi="jdbc/MyDB" table="conf" keyColumn="key"
valueColumn="value"/>
</configuration>
We may also propose to configure a DataSource using DBCP with attributes
specifying a driver name, URL, user and password. But I'm not sure I
want to enter this territory, sooner or later we'll be asked to provide
a way of configuring the connection pool, changing the implementation,
tunning the parameters, etc.. and that's not really the responsibility
of [configuration]. ConfigurationFactory should remain a simple way or
building a configuration declaratively, it should not turn into a
complex configuration framework.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
[configuration] other languages (perl, php, etc)
Posted by Moran Ben-David <mo...@placebase.com>.
In my company we have a recurring need to read our hierarchy of Commons
Configuration (text) files from languages other than Java. Does anyone know
of any projects out there that offer libraries that adhere to
commons-configuration's file formats? Especially the non-xml file format.
I am specifically interested in PHP and Perl at the moment. While our core
work is in Java, we often use perl and php to glue things together.
Thanks,
Moran Ben-David
www.placebase.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org