You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Oliver Heger <Ol...@t-online.de> on 2003/10/30 19:14:38 UTC
[configuration]Enhanced patch and some thoughts
Hi,
I have added an enhanced version of the HierarchicalConfiguration patch
to bugzilla (because of its size): Bug 24262. In this patch there is
also an XMLReader implementation that operates on a BaseConfiguration
instance rather than HierarchicalConfiguration. This makes it possible
to perform XML processing on all kind of Confiugration objects and e.g.
pass them to a Digester.
The new parsing functionality for (Base)Configuration objects is
implemented in the BaseConfigurationXMLReader class. There is also a new
base class ConfigurationXMLReader that provides common functionality of
the specific XMLReader classes. An additional class
HierarchicalConfigurationConverter is used by BaseConfigurationXMLReader
and provides means to iterate over the keys defined in a Configuration
and treat them in a structured manner.
I am expecting your feedback...
Finally some thoughts about ConfigurationFactory: This class and some of
the Configuration classes that can be created by this factory load their
data from files. I think that will cause problems for applications that
are deloyed in jars (and that have their configuration also stored in
these archives), e.g. web applications. Wouldn't it be better if the
affected classes used URLs instead? Then it would be possible to
determine a URL to a configuration file (even if it is located in a jar)
in a simmilar way as ClassPropertiesConfiguration work and let the
classes read their data from that URL.
And still another point: I am not very happy with ConfigurationFactory
in the way that it not really constructs a union of the properties it
reads. For instance if two XML files are read that contain similar
elements you cannot obtain the data in the second file because the
search for properties stops when values in the first file are found. I
would prefer to get all properties.
The BasePropertiesConfiguration class provides a way of including other
files into a property file. I think it would be very useful to implement
this feature for other configuration classes, too. Maybe a generic
approach could be found to allow includes of arbirary files in all
configuration classes (e.g. include .properties files in XML files and
vice versa, XML files in XML files etc.). With this approach a developer
could access all properties in his application through a single
configuration object; this is similar to a Unix file system which allows
to mount different disks into one logic directory tree.
As a use case consider web frameworks like struts. Those frameworks
typically define lots of configuration information in a monolithic file
(struts-config.xml), which can be a bottle neck in large projects with
lots of developers. With the generic include facility it would be very
simple to split these large files into arbitrary small portions and link
them together. For the code that processes the configuration these
portions occur as a single logic file.
What do you think?
Regards
Oli
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [configuration]Enhanced patch and some thoughts
Posted by Eric Pugh <ep...@upstate.com>.
That sounds great. Remember, we need to continue the support for the first
use case as well, since that is already in use. Ideally it would be
backwards compatible with the existing XML format, but if you provided the
<override>/<additional> sections then the appropriate logic would be used.
This is defintily going to need good tests, as the logic can be rather
screwy..
Eric
> -----Original Message-----
> From: Oliver Heger [mailto:Oliver.Heger@t-online.de]
> Sent: Friday, October 31, 2003 12:15 PM
> To: Jakarta Commons Developers List
> Subject: Re: [configuration]Enhanced patch and some thoughts
>
>
> Eric,
>
> I am quite interested in this stuff with
> ConfigurationFactory. I think,
> if you don't mind, I will go ahead and try to add an
> implementation of
> this second use case.
>
> Oli
>
> Eric Pugh wrote:
>
> >Wow! Lots of good feedback.. Let me start with the
> ConfigurationFactory.
> >Okay.. CF sucks.. I discovered the problem with the files
> myself recently.
> >What it really should work with is an InputStream or Url..
> , since the xml
> >file that digester uses could be in a jar. So, I totally
> agree with you on
> >that.
> >
> >Okay, second bit, whether a configfactory returns the merged set or
> >properties, or overrides.. I guess there are two seperate
> usecases. The
> >first usecase, which is what it implements now is that you
> have a standard
> >set of properties, so you include them in a jar file and use
> them. But, you
> >want to give the user/deployer the ability to override them,
> so you put
> >either another properties file or jndi or what not ahead of
> the standard.
> >And voila! You can override all your properties.
> >
> >Second use case.. I want to collect all the properties from multiple
> >locations and then merge them into one super Configuration
> object. This
> >would allow me to dynamically add to what is already setup.
> >
> >I think that the ConfigurationFactory should deal with both
> cases.. I see
> >something like:
> ><override>
> >list of locations to look for properties that override the
> onces that come
> >after it. Similar to what is there now.
> ></override>
> ><additional>
> >list of locations to add all the properties into one uber
> Configuration
> >object.
> ></additonal>
> >
> >This would then allow me the ability to do both usecases. I
> would love to
> >see some patches for ConfigurationFactory, that could support this.
> >
> >As an aside, I wrote an Avalon wrapper for the
> ConfigurationFactory based
> >Configuration objects:
> >http://jakarta.apache.org/turbine/fulcrum/fulcrum-configurati
on/index.html
>
>I made it part of fulcrum as I didn't want to bloat c-c with a ton of extra
>dependencies for something that is just a wrapper.
>
>Eric
>
>
>
---------------------------------------------------------------------
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
Re: [configuration]Enhanced patch and some thoughts
Posted by Oliver Heger <Ol...@t-online.de>.
Eric,
I am quite interested in this stuff with ConfigurationFactory. I think,
if you don't mind, I will go ahead and try to add an implementation of
this second use case.
Oli
Eric Pugh wrote:
>Wow! Lots of good feedback.. Let me start with the ConfigurationFactory.
>Okay.. CF sucks.. I discovered the problem with the files myself recently.
>What it really should work with is an InputStream or Url.. , since the xml
>file that digester uses could be in a jar. So, I totally agree with you on
>that.
>
>Okay, second bit, whether a configfactory returns the merged set or
>properties, or overrides.. I guess there are two seperate usecases. The
>first usecase, which is what it implements now is that you have a standard
>set of properties, so you include them in a jar file and use them. But, you
>want to give the user/deployer the ability to override them, so you put
>either another properties file or jndi or what not ahead of the standard.
>And voila! You can override all your properties.
>
>Second use case.. I want to collect all the properties from multiple
>locations and then merge them into one super Configuration object. This
>would allow me to dynamically add to what is already setup.
>
>I think that the ConfigurationFactory should deal with both cases.. I see
>something like:
><override>
>list of locations to look for properties that override the onces that come
>after it. Similar to what is there now.
></override>
><additional>
>list of locations to add all the properties into one uber Configuration
>object.
></additonal>
>
>This would then allow me the ability to do both usecases. I would love to
>see some patches for ConfigurationFactory, that could support this.
>
>As an aside, I wrote an Avalon wrapper for the ConfigurationFactory based
>Configuration objects:
>http://jakarta.apache.org/turbine/fulcrum/fulcrum-configuration/index.html
>
>I made it part of fulcrum as I didn't want to bloat c-c with a ton of extra
>dependencies for something that is just a wrapper.
>
>Eric
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [configuration]Enhanced patch and some thoughts
Posted by Eric Pugh <ep...@upstate.com>.
Wow! Lots of good feedback.. Let me start with the ConfigurationFactory.
Okay.. CF sucks.. I discovered the problem with the files myself recently.
What it really should work with is an InputStream or Url.. , since the xml
file that digester uses could be in a jar. So, I totally agree with you on
that.
Okay, second bit, whether a configfactory returns the merged set or
properties, or overrides.. I guess there are two seperate usecases. The
first usecase, which is what it implements now is that you have a standard
set of properties, so you include them in a jar file and use them. But, you
want to give the user/deployer the ability to override them, so you put
either another properties file or jndi or what not ahead of the standard.
And voila! You can override all your properties.
Second use case.. I want to collect all the properties from multiple
locations and then merge them into one super Configuration object. This
would allow me to dynamically add to what is already setup.
I think that the ConfigurationFactory should deal with both cases.. I see
something like:
<override>
list of locations to look for properties that override the onces that come
after it. Similar to what is there now.
</override>
<additional>
list of locations to add all the properties into one uber Configuration
object.
</additonal>
This would then allow me the ability to do both usecases. I would love to
see some patches for ConfigurationFactory, that could support this.
As an aside, I wrote an Avalon wrapper for the ConfigurationFactory based
Configuration objects:
http://jakarta.apache.org/turbine/fulcrum/fulcrum-configuration/index.html
I made it part of fulcrum as I didn't want to bloat c-c with a ton of extra
dependencies for something that is just a wrapper.
Eric
> -----Original Message-----
> From: Oliver Heger [mailto:Oliver.Heger@t-online.de]
> Sent: Thursday, October 30, 2003 7:15 PM
> To: Jakarta Commons Developer List
> Subject: [configuration]Enhanced patch and some thoughts
>
>
> Hi,
>
> I have added an enhanced version of the
> HierarchicalConfiguration patch
> to bugzilla (because of its size): Bug 24262. In this patch there is
> also an XMLReader implementation that operates on a BaseConfiguration
> instance rather than HierarchicalConfiguration. This makes it
> possible
> to perform XML processing on all kind of Confiugration
> objects and e.g.
> pass them to a Digester.
>
> The new parsing functionality for (Base)Configuration objects is
> implemented in the BaseConfigurationXMLReader class. There is
> also a new
> base class ConfigurationXMLReader that provides common
> functionality of
> the specific XMLReader classes. An additional class
> HierarchicalConfigurationConverter is used by
> BaseConfigurationXMLReader
> and provides means to iterate over the keys defined in a
> Configuration
> and treat them in a structured manner.
>
> I am expecting your feedback...
>
> Finally some thoughts about ConfigurationFactory: This class
> and some of
> the Configuration classes that can be created by this factory
> load their
> data from files. I think that will cause problems for
> applications that
> are deloyed in jars (and that have their configuration also stored in
> these archives), e.g. web applications. Wouldn't it be better if the
> affected classes used URLs instead? Then it would be possible to
> determine a URL to a configuration file (even if it is
> located in a jar)
> in a simmilar way as ClassPropertiesConfiguration work and let the
> classes read their data from that URL.
>
> And still another point: I am not very happy with
> ConfigurationFactory
> in the way that it not really constructs a union of the properties it
> reads. For instance if two XML files are read that contain similar
> elements you cannot obtain the data in the second file because the
> search for properties stops when values in the first file are
> found. I
> would prefer to get all properties.
>
> The BasePropertiesConfiguration class provides a way of
> including other
> files into a property file. I think it would be very useful
> to implement
> this feature for other configuration classes, too. Maybe a generic
> approach could be found to allow includes of arbirary files in all
> configuration classes (e.g. include .properties files in XML
> files and
> vice versa, XML files in XML files etc.). With this approach
> a developer
> could access all properties in his application through a single
> configuration object; this is similar to a Unix file system
> which allows
> to mount different disks into one logic directory tree.
>
> As a use case consider web frameworks like struts. Those frameworks
> typically define lots of configuration information in a
> monolithic file
> (struts-config.xml), which can be a bottle neck in large
> projects with
> lots of developers. With the generic include facility it
> would be very
> simple to split these large files into arbitrary small
> portions and link
> them together. For the code that processes the configuration these
> portions occur as a single logic file.
>
> What do you think?
>
> Regards
> Oli
>
>
> ---------------------------------------------------------------------
> 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