You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Emmanuel Bourg <sm...@lfjr.net> on 2004/09/07 16:04:30 UTC
[configuration] Loading and Saving
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
to provide a clean and well thought out API we must implement the same
methods everywhere. Hence I suggest the following:
- replace BasePathLoader with a FileConfiguration interface. This
interface will declare the load/save methods and the get/setters for the
file name and the base path.
- replace BasePathConfiguration with AbstractFileConfiguration. It
provides a default implementation for the get/setters and for some
load/save methods.
- complete PropertiesConfiguration, XMLConfiguration and
HierarchicalXMLConfiguration with the missing constructors and methods.
What do you think ?
Emmanuel Bourg
Re: [configuration] Loading and Saving
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Oliver Heger wrote:
> In my opinion this would have two advantages:
>
> 1. The logic of loading and storing data is extracted from the
> Configuration classes. In fact we would only need one or two
> Configuration classes that are only responsible for maintaining
> properties.
Well, it's almost the case already, AbstractConfiguration is the main
class handling the properties, the final configurations are only left
with a few constructors, a load(Reader) and a save(Writer) method, they
are just responsible for reading and writing the data.
> 2. It would be possible to store a Configuration with a different Writer
>
> than it was loaded. So it would for instance be possible to read a
> properties file and save it as XML file.
That's an interesting feature and I see it as the main benefit of an
architecture separating the data from the persistence mechanism. But I
don't think it's really a common use case, and copying properties is
still possible if one want to change the file format (we may add a
addAll(Configuration) method to the Configuration interface to achieve
that). I filed a enhancement request to cover this topic:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=31119
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] Loading and Saving
Posted by Oliver Heger <Ol...@t-online.de>.
I agree that all file based configuration classes should work the same way.
I have an alternative suggestion: We could introduce a new package
o.a.c.configuration.io with a couple of ConfigurationReader and
ConfigurationWriter classes. The Readers would be initialized with a
file, a URL or whatever and have a read() method that returns a
Configuration object. The Writers would have an analogous write() method
that stores a given Configuration object to a specified destination.
In my opinion this would have two advantages:
1. The logic of loading and storing data is extracted from the
Configuration classes. In fact we would only need one or two
Configuration classes that are only responsible for maintaining properties.
2. It would be possible to store a Configuration with a different Writer
than it was loaded. So it would for instance be possible to read a
properties file and save it as XML file.
Well, this would certainly cause more work, so it probably cannot be
addressed before the 1.0 release. But what do you think about this idea
in general?
Oliver
Emmanuel Bourg wrote:
> 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
> to provide a clean and well thought out API we must implement the same
> methods everywhere. Hence I suggest the following:
>
> - replace BasePathLoader with a FileConfiguration interface. This
> interface will declare the load/save methods and the get/setters for
> the file name and the base path.
>
> - replace BasePathConfiguration with AbstractFileConfiguration. It
> provides a default implementation for the get/setters and for some
> load/save methods.
>
> - complete PropertiesConfiguration, XMLConfiguration and
> HierarchicalXMLConfiguration with the missing constructors and methods.
>
> What do you think ?
>
> Emmanuel Bourg
>
>------------------------------------------------------------------------
>
>---------------------------------------------------------------------
>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] Loading and Saving
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Emmanuel Bourg <sm...@lfjr.net> writes:
>Henning P. Schmiedehausen wrote:
>> public getString(String propertyName)
>> {
>> String foo = conf.getString(propertyName);
>> if (foo == null)
>> {
>> throw Exception...
>> }
>>
>> return foo;
>> }
>This is not quite equivalent, because null could have 2 different meanings:
>- the property doesn't exist, hence the value is null
>- the property exists, but it's value is null
I was thinking about this after I sent the mail out. However, I
couldn't find a way to configure a property to be configured and
return a null value. Is this possible with c-c? So IMHO the second
meaning never occurs.
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
Re: [configuration] Loading and Saving
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Henning P. Schmiedehausen wrote:
> public getString(String propertyName)
> {
> String foo = conf.getString(propertyName);
> if (foo == null)
> {
> throw Exception...
> }
>
> return foo;
> }
This is not quite equivalent, because null could have 2 different meanings:
- the property doesn't exist, hence the value is null
- the property exists, but it's value is null
The decorator idea is an easy workaround, but with the multiplication of
decorator (one for reloadable configurations, one for extra data types,
etc...) it could become complicated to build a configuration with the
desired behaviour.
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] Loading and Saving
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Emmanuel Bourg <sm...@lfjr.net> writes:
Using a Decorator around Configuration might be the coolest solution
to the return null vs. throw Exception problem. We might add a
decorator that throws an Exception on a null return value.
So if you need this you use e.g.
Configuration conf = ExceptionDecorator.decorate(Turbine.getConfiguration());
with
public class ExceptionDecorator
implements Configuration
{
public static Configuration decorate(Configuration conf)
{
return new ExceptionDecorator(conf);
}
private Configuration conf = null;
private ExceptionDecorator(Configuration conf)
{
this.conf = conf;
}
public getString(String propertyName)
{
String foo = conf.getString(propertyName);
if (foo == null)
{
throw Exception...
}
return foo;
}
[...]
}
and be done with this. There might be even more elegant ways to write
such a decorator. ;-)
Regards
Henning
>Henning P. Schmiedehausen wrote:
>> Don't be too humble. Apache Gump tells us that commons-configuration
>> has seven direct and 71 (!) indirect dependees on commons-configuration:
>>
>> http://brutus.apache.org/gump/public/gump_stats/project_dependees.html
>Nice, I didn't know [configuration] was already included in Gump :) Is
>there a way to track back the projects using it ?
>> For the matter of the switch: Emmanuel: How do you plan to implement
>> this? Additional C'tors taking a boolean? Or a boolean setter?
>I intended to add a boolean setter, but I was still pondering where,
>whether in the Configuration interface or just in AbstractConfiguration ?
>> Personally, I'd still prefer the "two methods for everyone" approach
>> that Hibernate does. getBoolean(String property) returns null if
>> property does not exist and fetchBoolean(String propety) throws an
>> Exception.
>Why not but I'm not sure Eric will like this ;) There was a discussion
>recently on the addition of getters to the Configuration interface
>(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29617) and we debated
>about the length of the API.
>Emmanuel Bourg
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
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
Re: [configuration] Loading and Saving
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Henning P. Schmiedehausen wrote:
> Don't be too humble. Apache Gump tells us that commons-configuration
> has seven direct and 71 (!) indirect dependees on commons-configuration:
>
> http://brutus.apache.org/gump/public/gump_stats/project_dependees.html
Nice, I didn't know [configuration] was already included in Gump :) Is
there a way to track back the projects using it ?
> For the matter of the switch: Emmanuel: How do you plan to implement
> this? Additional C'tors taking a boolean? Or a boolean setter?
I intended to add a boolean setter, but I was still pondering where,
whether in the Configuration interface or just in AbstractConfiguration ?
> Personally, I'd still prefer the "two methods for everyone" approach
> that Hibernate does. getBoolean(String property) returns null if
> property does not exist and fetchBoolean(String propety) throws an
> Exception.
Why not but I'm not sure Eric will like this ;) There was a discussion
recently on the addition of getters to the Configuration interface
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29617) and we debated
about the length of the API.
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] Loading and Saving
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Eric Pugh" <ep...@upstate.com> writes:
>That page is pretty cool! Any idea how to get the list of who the
>dependencies are on, both direct and indirect?
Haven't found it when looking at it for five minutes. We might simply
ask the Gump people.
>I would rather go with a property that controls the behavior of throwing
>exceptions versus null. Especially if the plan is to change in the next
>version to always throwing Exceptions.. I can see a bit of confusion if we
>double the number of methods.. Do I use getBoolean or fetchBoolean? And
>getBoolean/getBooleanThrowExceptionIfMissing seems silly as well!
Yep. Actually, this decorator idea from the Bugzilla thread starts to
look better and better. Because we could have our cake (keep the old
semantics) and eat it too (use a decorator to throw an exception if
return value is null).
>And, I definitly agree w/ Henning on the "no promises beyond Configuration
>interface". In fact, maybe we want to add a note on the homepage about
>it...
>I think it all boils down to, lets see who does what, and that is the path
>we take. How about we cut RC2 late next week? That gives a deadline for
>the various ideas floating about? I'll volunteer to do it next Thursday if
>that sounds good.
>That way we can look at a 1.0 in 2 weeks, and then Henning can cut
>turbine-2.3.1 and I can think about cutting turbine-2.4-M2.
+1 Getting 2.3.1 out of the door before OSCOM would be good. :-) I'd
very much like to get a c-c RC2 ASAP. I will also try to hold Scott from
releasing Torque 3.1.1 before we have c-c 1.0.
Regards
Henning
>Eric
>> -----Original Message-----
>> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
>> Sent: Wednesday, September 08, 2004 4:43 PM
>> To: commons-dev@jakarta.apache.org
>> Subject: Re: [configuration] Loading and Saving
>>
>>
>> "Eric Pugh" <ep...@upstate.com> writes:
>>
>> >nulls, and then dump the nulls in the next version. I wouldn't worry too
>> >much about backwards compatibilty. We're at the 1.0 stage, and
>> don't have
>> >that many users.. I think, as long as we document them, that there are
>>
>> Don't be too humble. Apache Gump tells us that commons-configuration
>> has seven direct and 71 (!) indirect dependees on commons-configuration:
>>
>> http://brutus.apache.org/gump/public/gump_stats/project_dependees.html
>>
>> So we should try to not upset or the users of 71 projects come
>> knocking on our mailboxes. (BTW: commons-lang has 28/235 and
>> commons-collections 73/257. So having a third the user base of commons
>> lang is IMHO already quite some distribution).
>>
>> We simply should choose not to put all of our API in stone. I think we
>> should be willing to guarantee everything that is in the Configuration
>> interface for a while and the C'tors of the implementations. Apart
>> from this: All bets are off. :-)
>>
>> For the matter of the switch: Emmanuel: How do you plan to implement
>> this? Additional C'tors taking a boolean? Or a boolean setter?
>>
>> Personally, I'd still prefer the "two methods for everyone" approach
>> that Hibernate does. getBoolean(String property) returns null if
>> property does not exist and fetchBoolean(String propety) throws an
>> Exception.
>>
>> 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
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
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
RE: [configuration] Loading and Saving
Posted by Eric Pugh <ep...@upstate.com>.
That page is pretty cool! Any idea how to get the list of who the
dependencies are on, both direct and indirect?
I would rather go with a property that controls the behavior of throwing
exceptions versus null. Especially if the plan is to change in the next
version to always throwing Exceptions.. I can see a bit of confusion if we
double the number of methods.. Do I use getBoolean or fetchBoolean? And
getBoolean/getBooleanThrowExceptionIfMissing seems silly as well!
And, I definitly agree w/ Henning on the "no promises beyond Configuration
interface". In fact, maybe we want to add a note on the homepage about
it...
I think it all boils down to, lets see who does what, and that is the path
we take. How about we cut RC2 late next week? That gives a deadline for
the various ideas floating about? I'll volunteer to do it next Thursday if
that sounds good.
That way we can look at a 1.0 in 2 weeks, and then Henning can cut
turbine-2.3.1 and I can think about cutting turbine-2.4-M2.
Eric
> -----Original Message-----
> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> Sent: Wednesday, September 08, 2004 4:43 PM
> To: commons-dev@jakarta.apache.org
> Subject: Re: [configuration] Loading and Saving
>
>
> "Eric Pugh" <ep...@upstate.com> writes:
>
> >nulls, and then dump the nulls in the next version. I wouldn't worry too
> >much about backwards compatibilty. We're at the 1.0 stage, and
> don't have
> >that many users.. I think, as long as we document them, that there are
>
> Don't be too humble. Apache Gump tells us that commons-configuration
> has seven direct and 71 (!) indirect dependees on commons-configuration:
>
> http://brutus.apache.org/gump/public/gump_stats/project_dependees.html
>
> So we should try to not upset or the users of 71 projects come
> knocking on our mailboxes. (BTW: commons-lang has 28/235 and
> commons-collections 73/257. So having a third the user base of commons
> lang is IMHO already quite some distribution).
>
> We simply should choose not to put all of our API in stone. I think we
> should be willing to guarantee everything that is in the Configuration
> interface for a while and the C'tors of the implementations. Apart
> from this: All bets are off. :-)
>
> For the matter of the switch: Emmanuel: How do you plan to implement
> this? Additional C'tors taking a boolean? Or a boolean setter?
>
> Personally, I'd still prefer the "two methods for everyone" approach
> that Hibernate does. getBoolean(String property) returns null if
> property does not exist and fetchBoolean(String propety) throws an
> Exception.
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] Loading and Saving
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Eric Pugh" <ep...@upstate.com> writes:
>nulls, and then dump the nulls in the next version. I wouldn't worry too
>much about backwards compatibilty. We're at the 1.0 stage, and don't have
>that many users.. I think, as long as we document them, that there are
Don't be too humble. Apache Gump tells us that commons-configuration
has seven direct and 71 (!) indirect dependees on commons-configuration:
http://brutus.apache.org/gump/public/gump_stats/project_dependees.html
So we should try to not upset or the users of 71 projects come
knocking on our mailboxes. (BTW: commons-lang has 28/235 and
commons-collections 73/257. So having a third the user base of commons
lang is IMHO already quite some distribution).
We simply should choose not to put all of our API in stone. I think we
should be willing to guarantee everything that is in the Configuration
interface for a while and the C'tors of the implementations. Apart
from this: All bets are off. :-)
For the matter of the switch: Emmanuel: How do you plan to implement
this? Additional C'tors taking a boolean? Or a boolean setter?
Personally, I'd still prefer the "two methods for everyone" approach
that Hibernate does. getBoolean(String property) returns null if
property does not exist and fetchBoolean(String propety) throws an
Exception.
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
Re: [configuration] Loading and Saving
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Emmanuel Bourg <sm...@lfjr.net> writes:
>Henning P. Schmiedehausen wrote:
>> 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.
>Releasing the 1.0 final is also my top priority, while I agree to
>sacrifice features for this (like automatic reloading, support for
>additional types & more configuration formats) I don't want to sacrifice
>quality (API consistency, testing & documentation), that's why I call
>for these changes now. I don't want to be tied to backward compatibility
>concerns once 1.0 is released because we didn't take the time to address
>these inconsistencies.
The C'tors pose no problems as we can add them even after a
release. For the missing methods:
- Are they defined by an interface somewhere? As far as I can see, they
are not. We should then at least define them by an interface (not
Configuration please), so users know what to expect from the various
Configuration implementations.
- Adding the missing methods can be as simple as
public void fooMissing(...) {
throw new UnsupportedOperationException("Not yet implemented");
}
Yeah, not really user friendly but it would help to get the API in shape
without having to write too much new Code.
>Well, the merit of the rc1 is to provide and temporary official release
>that can sweep away the various unofficial snapshots and bring more
>testing and feedback on the project. But I don't consider it good enough
>in this state to become a final release.
The unfortunate thing with rc1 is, that it is missing getVector()
which is crucial to c-c users like Turbine or Torque. And there is
also the changed semantics w.r.t get<xxx>(String propertyName)
(Exception vs. null). So it is not a matter of simple replacing.
As I wrote before, I'm -0 on releasing the current state as 1.0
because of the semantics changes. The same thing basically applies to
the current state as rc2. The rc1 problems are clearly visible. You
drop rc1 into a Turbine application, then it crashed immediately. You
drop the HEAD into a Turbine application, the errors are much more
subtle and hard to find.
>> So please. Let's find an agreement on the get<xxx> semantics, do one
>> more RC and the CfV the release.
>I don't mind if we revert to a null-when-missing semantic now and add a
>switch later for exception-when-missing.
I'm +1 with this. Eric?
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
RE: [configuration] Loading and Saving
Posted by Eric Pugh <ep...@upstate.com>.
I think it boils down to "is anyone doing the work".. If Emmanuel is hot on
getting this done in the very near future, then lets add it. Emmanuel, if
you view this as a 2 week project to properly get done, then lets leave it
for 1.0.1. There is no reason that 1.0.1 can't come out 2 or 3 weeks after
1.0. Heck, there isn't any reason why 1.1 can't come out 2 or 3 weeks after
1.0! Which is I think what we should name the next version that doesn't
have vector and throws Exceptions on missing values..
Personally, I want the switch to be able to throws Exceptions or return
nulls, and then dump the nulls in the next version. I wouldn't worry too
much about backwards compatibilty. We're at the 1.0 stage, and don't have
that many users.. I think, as long as we document them, that there are
backwards compatiblities, then they are okay.
Eric
> -----Original Message-----
> From: Emmanuel Bourg [mailto:smanux@lfjr.net]
> Sent: Wednesday, September 08, 2004 12:45 PM
> To: Jakarta Commons Developers List
> Subject: Re: [configuration] Loading and Saving
>
>
> Henning P. Schmiedehausen wrote:
>
> > 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.
>
> Releasing the 1.0 final is also my top priority, while I agree to
> sacrifice features for this (like automatic reloading, support for
> additional types & more configuration formats) I don't want to sacrifice
> quality (API consistency, testing & documentation), that's why I call
> for these changes now. I don't want to be tied to backward compatibility
> concerns once 1.0 is released because we didn't take the time to address
> these inconsistencies.
>
>
> > 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.
>
> I haven't tested but I think it's already the case, you can use
> PropertiesConfiguration without including the XML libraries.
>
>
> > 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.
>
> Well, the merit of the rc1 is to provide and temporary official release
> that can sweep away the various unofficial snapshots and bring more
> testing and feedback on the project. But I don't consider it good enough
> in this state to become a final release.
>
>
> > So please. Let's find an agreement on the get<xxx> semantics, do one
> > more RC and the CfV the release.
>
> I don't mind if we revert to a null-when-missing semantic now and add a
> switch later for exception-when-missing.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> 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] Loading and Saving
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Henning P. Schmiedehausen wrote:
> 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.
Releasing the 1.0 final is also my top priority, while I agree to
sacrifice features for this (like automatic reloading, support for
additional types & more configuration formats) I don't want to sacrifice
quality (API consistency, testing & documentation), that's why I call
for these changes now. I don't want to be tied to backward compatibility
concerns once 1.0 is released because we didn't take the time to address
these inconsistencies.
> 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.
I haven't tested but I think it's already the case, you can use
PropertiesConfiguration without including the XML libraries.
> 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.
Well, the merit of the rc1 is to provide and temporary official release
that can sweep away the various unofficial snapshots and bring more
testing and feedback on the project. But I don't consider it good enough
in this state to become a final release.
> So please. Let's find an agreement on the get<xxx> semantics, do one
> more RC and the CfV the release.
I don't mind if we revert to a null-when-missing semantic now and add a
switch later for exception-when-missing.
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] Loading and Saving
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Emmanuel Bourg <sm...@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
RE: [configuration] Loading and Saving
Posted by Eric Pugh <ep...@upstate.com>.
Works for me! We keep fixing things on this front in bits and pieces.
Getting closure would be good.
I guess my only misgivings is that I don't want to keep delaying 1.0 while
waiting for more code. But, you do seem to have it quite well thought out,
so if you are stepping up to the plate to do it, I think it's a great idea.
Otherwise, if it's more of an "idea" then lets get 1.0 out, warts and all...
I have to say, I like your email "design doc"!
Eric
> -----Original Message-----
> From: Emmanuel Bourg [mailto:smanux@lfjr.net]
> Sent: Tuesday, September 07, 2004 4:05 PM
> To: Jakarta Commons Developers List
> Subject: [configuration] Loading and Saving
>
>
> 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
> to provide a clean and well thought out API we must implement the same
> methods everywhere. Hence I suggest the following:
>
> - replace BasePathLoader with a FileConfiguration interface. This
> interface will declare the load/save methods and the get/setters for the
> file name and the base path.
>
> - replace BasePathConfiguration with AbstractFileConfiguration. It
> provides a default implementation for the get/setters and for some
> load/save methods.
>
> - complete PropertiesConfiguration, XMLConfiguration and
> HierarchicalXMLConfiguration with the missing constructors and methods.
>
> What do you think ?
>
> Emmanuel Bourg
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org