commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Pugh" <>
Subject RE: [configuration] Loading and Saving
Date Wed, 08 Sep 2004 15:17:24 GMT
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

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.


> -----Original Message-----
> From: Henning P. Schmiedehausen []
> Sent: Wednesday, September 08, 2004 4:43 PM
> To:
> Subject: Re: [configuration] Loading and Saving
> "Eric Pugh" <> 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:
> 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
>        +49 9131 50 654 0
> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message