[configuration][PATCH]addProperty

[Oliver Heger <o....@qubix.de>]

Eric,

I have created the patch for refactoring the addProperty() method.
AbstractConfiguration.addProperty() now only handles collection and string
properties with multiple values and then delegates to the abstract
addPropertyDirect() method.

The stuff with the containers was moved to
BaseConfiguration.addPropertyDirect(). The unit tests run fine.

There is a little thing more I changed: I made the nested Container class in
AbstractConfiguration static. The reason is that I have a static nested
class HierarchicalProperties.Node that needs to create instances of
Container. This is impossible with Container being nonstatic unless I make
the Node class nonstatic, too; but I don't like that because it would make
usage of this class more complicated for clients of HierarchicalProperties
(normally clients need not access this class directly, but there might be
cases where it could make sense). Was there any specific reason for making
Container nonstatic?


Regards
Oli

----- Original Message -----
From: "Eric Pugh" <ep...@upstate.com>
To: "'Oliver Heger'" <o....@qubix.de>; "'Jakarta Commons Developers List'"
<co...@jakarta.apache.org>
Sent: Tuesday, October 14, 2003 10:40 AM
Subject: RE: [configuration]HierarchicalConfiguration


> Oliver,
>
> So, if I understand properly, the reason is so that we refactor out the
code
> so that you don't have to do a cut'n'paste job from the
> AbstractConfiguration to your new subclass..
>
> Seems reasonable enough..  Why don't you submit a patch with your next
chunk
> of code then?
>
> Oh, and the attachements came through okay for me!
>
> Eric
>

Re: [configuration][PATCH]addProperty

[Oliver Heger <o....@qubix.de>]

Eric,

thank you, I checked it out and everything seems to be fine.

At the moment I am still working on a Configuration implementation that is
able to store hierarchical properties in a more suitable structure. I plan
to write an alternative version of DOM4jConfiguration that makes use of this
class to provide better support for tree-like XML documents. I also want to
implement a first approach for a Digester (or general XML-enabled)
interface.

I hope that I can soon deliver some results. Then we can talk about some
optimizations and how this stuff can be integrated best with the actual code
base.

A coverage rate of 59% for the unit tests seems to be indeed quite low. I
promise to keep an eye on this with my own classes.

Oli

----- Original Message -----
From: "Eric Pugh" <ep...@upstate.com>
To: "'Oliver Heger'" <o....@qubix.de>; "'Jakarta Commons Developer List'"
<co...@jakarta.apache.org>
Sent: Friday, October 17, 2003 10:31 AM
Subject: RE: [configuration][PATCH]addProperty


> Oliver,
>
> I have applied your patch.  Do you want to check things out?  I also added
> in some more maven reports.  I thought our coverage with unit tests was
> going to be steller, but according to JCoverage, we only have 59% coverage
> of the code base.
>
> At any rate, let me know how things go..  I am updating the website as I
> write this...
>
> Eric
>


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

RE: [configuration][PATCH]addProperty

[Eric Pugh <ep...@upstate.com>]

Oliver,

I have applied your patch.  Do you want to check things out?  I also added
in some more maven reports.  I thought our coverage with unit tests was
going to be steller, but according to JCoverage, we only have 59% coverage
of the code base.

At any rate, let me know how things go..  I am updating the website as I
write this...

Eric

> -----Original Message-----
> From: Oliver Heger [mailto:o.heger@qubix.de]
> Sent: Tuesday, October 14, 2003 1:58 PM
> To: Jakarta Commons Developer List; epugh@upstate.com
> Subject: [configuration][PATCH]addProperty
>
>
> Eric,
>
> I have created the patch for refactoring the addProperty() method.
> AbstractConfiguration.addProperty() now only handles
> collection and string
> properties with multiple values and then delegates to the abstract
> addPropertyDirect() method.
>
> The stuff with the containers was moved to
> BaseConfiguration.addPropertyDirect(). The unit tests run fine.
>
> There is a little thing more I changed: I made the nested
> Container class in
> AbstractConfiguration static. The reason is that I have a
> static nested
> class HierarchicalProperties.Node that needs to create instances of
> Container. This is impossible with Container being nonstatic
> unless I make
> the Node class nonstatic, too; but I don't like that because
> it would make
> usage of this class more complicated for clients of
> HierarchicalProperties
> (normally clients need not access this class directly, but
> there might be
> cases where it could make sense). Was there any specific
> reason for making
> Container nonstatic?
>
>
> Regards
> Oli
>
> ----- Original Message -----
> From: "Eric Pugh" <ep...@upstate.com>
> To: "'Oliver Heger'" <o....@qubix.de>; "'Jakarta Commons
> Developers List'"
> <co...@jakarta.apache.org>
> Sent: Tuesday, October 14, 2003 10:40 AM
> Subject: RE: [configuration]HierarchicalConfiguration
>
>
> > Oliver,
> >
> > So, if I understand properly, the reason is so that we
> refactor out the
> code
> > so that you don't have to do a cut'n'paste job from the
> > AbstractConfiguration to your new subclass..
> >
> > Seems reasonable enough..  Why don't you submit a patch
> with your next
> chunk
> > of code then?
> >
> > Oh, and the attachements came through okay for me!
> >
> > Eric
> >
>
>


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