commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Heger" <>
Subject Re: [configuration]HierarchicalConfiguration
Date Mon, 13 Oct 2003 17:58:51 GMT

I'm not sure if I understand what you mean.

My problem with the addProperty() method is not caused by some kind of error
a unit test could detect. It's merly a design issue.

At the moment addProperty() is implemented so that it first handles stuff
related to collections or string values that contain multiple property
values. This is fine because it is a generic feature support by all
configuration classes. But then instead of calling addPropertyDirect() it
calls getPropertyDirect() and performs the adding by hand. Here it creates a
Container if necessary and adds this container by calling
addPropertyDirect(). This part is not compatible with my implementation and
is in my opinion to much tight to a concrete mechanism of storing the

I could of course overwrite addProperty() in my implementation, but then I
would have to copy the first part which deals with the collections.

To demonstrate the direction I am following with my
HierarchicalConfiguration I have attached an early version of a
corresponding unit test. The test of the getProperty() method shows how
single elements of complex property lists can be accessed.


----- Original Message -----
From: "Eric Pugh" <>
To: "'Jakarta Commons Developers List'" <>
Sent: Wednesday, October 10, 2001 12:12 PM
Subject: RE: [configuration]HierarchicalConfiguration

> Can you provide a unit test that demonstrates the problem?  If the problem
> is because of your specific subclass, can you just create a mock version?
> That way we have something firm to lookat, and then we can discuss the
> pro's/con's of moving the methods around...
> Eric
> > -----Original Message-----
> > From: Oliver Heger []
> > Sent: Friday, October 10, 2003 11:32 AM
> > To: Jakarta Commons Developers List
> > Subject: Re: [configuration]HierarchicalConfiguration
> >
> >
> > Hello Eric,
> >
> > I did not mean to remove the whole Container stuff from
> > AbstractConfiguration. I think Containers are still needed
> > (at least) to
> > distinguish results of getPropertyDirect(): is the result a
> > single property
> > of type Collection or is it a list of properties of scalar types?
> >
> > My problem is only with the addProperty() method that is
> > implemented in
> > AbstractConfiguration in a way that it enforces multiple values of a
> > property to be stored in a Container - and I want to do it different.
> >
> > So I would like to suggest to move the part of the
> > AbstractConfiguration.addProperty() method that deals with
> > Container to the
> > addPropertyDirect() method of BaseConfiguration and let
> > AbstractConfiguration.addProperty() call addPropertyDirect
> > instead. This
> > makes it possible to use different storage algorithm in
> > derived classes.
> >
> > As far as I see addProperty() is the only method that assumes such a
> > Container specific storage logic, but there may be other
> > locations I have
> > not found yet.
> >

View raw message