commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henning P. Schmiedehausen" <...@intermeta.de>
Subject Re: [configuration] Loading and Saving
Date Tue, 07 Sep 2004 17:34:07 GMT
Emmanuel Bourg <smanux@lfjr.net> writes:

>Hi all, I'd like to suggest a change to something in [configuration] 
>that has been itching me for quite some time: the inconsistencies 
>between the various file based configurations with regard to data 
>persistence.

>Currently we have several inconsistent constructors, and load()/save() 
>methods between PropertiesConfiguration, XMLConfiguration and 
>HierarchicalXMLConfiguration. For example, XMLConfiguration can be 
>constructed from a File object, but not the others, 
>HierarchicalXMLConfiguration can be loaded from an URL but not saved, 
>PropertiesConfiguration can be loaded directly from an InputStream, etc.

>There are also exception inconsistencies, for example save(OutputStream) 
>throws a ConfigurationException in XMLConfiguration and an IOException 
>in PropertiesConfiguration.

>I summarized these differences in the attached excel sheet (I hope 
>everyone can read it, if not I'll export it to HTML). I think in order 

My Newsreader shredded it to bits, sorry. Can you send it to me via regular
mail (off-list)?

>to provide a clean and well thought out API we must implement the same 
>methods everywhere. Hence I suggest the following:

I like all of this. However, even more I'd like to get 1.0 finally out
of the door. I'm really willing to tell our users, that they can rely
only on the non-deprecated method signatures in the
o.a.c.c.Configuration interface and that everything else can and will
be changed post-1.0, but for the moment, getting this stuff released
is my #1 prio.

I also like the proposal to make the various implementations
pluggable. A small application that needs only PropertiesConfiguration
should not be punished to drag all of the XML libraries
around. Splitting c-c into a "base" package with maybe only
commons-lang and commons-collections as dependencies and one or more
"optional" packages would be a good thing.

However, we are already at rc1 state. Pulling the rc1 back would mean,
that at least I would go ahead an do the Turbine 2.3.1 release on a
snapshot which would IMHO a sad thing.

So please. Let's find an agreement on the get<xxx> semantics, do one
more RC and the CfV the release.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

"Fighting for one's political stand is an honorable action, but re-
 fusing to acknowledge that there might be weaknesses in one's
 position - in order to identify them so that they can be remedied -
 is a large enough problem with the Open Source movement that it
 deserves to be on this list of the top five problems."
                       -- Michelle Levesque, "Fundamental Issues with
                                    Open Source Software Development"

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


Mime
View raw message