commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Heger" <o.he...@qubix.de>
Subject Re: [configuration]HierarchicalConfiguration
Date Mon, 13 Oct 2003 18:14:51 GMT
My attachment was eaten. Try to zip it...

----- Original Message -----
From: "Oliver Heger" <o.heger@qubix.de>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>;
<epugh@upstate.com>
Sent: Monday, October 13, 2003 7:58 PM
Subject: Re: [configuration]HierarchicalConfiguration


> 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 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
> 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.
>
> 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.
>
> 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
> >
> > > -----Original Message-----
> > > From: Oliver Heger [mailto:o.heger@qubix.de]
> > > 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.
> > >
>
>


----------------------------------------------------------------------------
----


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