Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <000701c38f1e$4e931a00$0101a8c0@eric>
From: "Oliver Heger" <o.heger@qubix.de>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
References: <036c01c15174$1ec7eec0$0100a8c0@IQUITOS>
Subject: Re: [configuration]HierarchicalConfiguration
Date: Fri, 10 Oct 2003 13:04:41 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hello,

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. 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
properties.

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

Greetings
Oli

----- Original Message -----
From: "Eric Pugh" <epugh@upstate.com>
To: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>
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
>


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