commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Pugh" <ep...@upstate.com>
Subject RE: [configuration]HierarchicalConfiguration
Date Wed, 10 Oct 2001 10:12:50 GMT
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.
>
> Now I attach a copy of the posting you have missed:
>
> I thought again about your response and now I agree with you
> that my code
> does something which theoretically Digester could do, too. But using a
> Digester object in my implementation seems to be massive overhead.
>
> The approach with a digester friendly configuration converter
> is a good
> idea, this would be very generic and could support many use
> cases including
> my object creation. Unfortunately it seems to be quite difficult to
> implement such a converter.
>
> A possibility of communicating with Digester would be to let
> a Configuration
> object trigger SAX events. Because Digester implements the
> org.xml.sax.ContentHandler interface it would be able to
> process them (I
> suppose, I didn't look at the source) . This has also the advantage of
> enabling other XMLish style processing for Configuration.
>
> My problem is now that there must be a way of extracting all
> available keys
> from a Configuration object in the correct order to feed them
> into Digester.
> With the actual implementation of BaseConfiguration this seems to be
> impossible because all properties are simply stored in a map.
> Though this is
> a sequenced map their original structure is lost. This is
> especially fatal
> for XML documents whose tree like structure is messed up
> (maybe it is not as
> problematic for plain properties or other configuration
> sources). A simple
> example to proof this would be a document that describes
> database tables as
> in the following fragment:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <config>
>  <table>
>    <name>Users</name>
>    <fields>
>      <field>
>        <name>uid</name>
>        <type>long</type>
>      </field>
>      <field>
>        <name>lastName</name>
>        <type>java.lang.String</type>
>      </field>
>      <field>
>        <name>firstName</name>
>        <type>java.lang.String</type>
>      </field>
>    </fields>
>  </table>
>  <table>
>    <name>documents</name>
>    <fields>
>      <field>
>        <name>docid</name>
>        <type>long</type>
>      </field>
>      <field>
>        <name>docName</name>
>        <type>java.lang.String</type>
>      </field>
>      <field>
>        <name>authorID</name>
>        <type>long</type>
>      </field>
>    </fields>
>  </table>
> </config>
>
> After this document was parsed there is no way to find out
> which fields
> belong to which table. Are there some plans to deal with this
> problem? I
> think it could be worth thinking about it because XML as a
> configuration
> format is quite important and its tree-like structure is one
> of its main
> benefits.
>
> If the tree structure could somehow be saved, it would also
> be possible to
> extend the syntax of the property keys, e.g.
> conf.getList("table(1).fields.field.name");
> would return a vector with the names of all fields of the
> first table or
> something like that.
>
> Regards
> Oli
> > Oliver..
> >
> > Sorry I missed your earlier post..  So, have you looked at
> the Digester
> > commons project?  I think it does similar to what your code
> does..  It
> takes
> > in an XML file with various rules about constructores etc
> and then builds
> > the objects from that.
> >
> > There is also in (I think :-) ) beanutils a simple version
> of Digester
> that
> > hides away a lot of the complexity of digester..
> >
> > Could you highlight how your code and digester are
> different? It seems
> also
> > that what you have done might be better applied to digester
> as a "simple"
> > xml format..
> >
> > Lastly, would it make sense to write a digester friendly
> configuration
> > converter?  In otherwords, something that would take a configuration
> > objects, feed it to digester and get back objects?
> >
> > Eric
>
>
> ----- Original Message -----
> From: "Eric Pugh" <epugh@upstate.com>
> To: "'Jakarta Commons Developers List'"
> <commons-dev@jakarta.apache.org>
> Cc: "'Konstantin Shaposhnikov'" <k8n@tut.by>;
> <Oliver.Heger@t-online.de>
> Sent: Friday, October 10, 2003 11:14 AM
> Subject: RE: [configuration]HierarchicalConfiguration
>
>
> > Oliver, I missed your earlier post about
> HierarchicalConfiguration (can't
> > find it in my email...) but what you are saying is that the
> > addProperty method causes issues because they go to the
> Container object.
> > Then if we move the container stuff to BaseConfiguration
> then you could do
> > your
> > own stuff in addProperty?
> >
> > If we move the container stuff to BaseConfiguration then is
> there any
> reason
> > to keep AbstractConfiguration?  I thought the idea was that since
> > BaseConfiguration was hard to extend from, by adding
> AbstractConfiguration
> > you could extend from that and have most of the methods
> done, just needed
> to
> > reimplement the addPropertyDirect/getPropertyDirect
> methods?  Or would we
> > also move the addProperty/getProperty to BaseConfiguration as well?
> >
> > ERic
> >
> >
> >
> > > -----Original Message-----
> > > From: Oliver Heger [mailto:Oliver.Heger@t-online.de]
> > > Sent: Thursday, October 09, 2003 11:05 AM
> > > To: Jakarta Commons Developer List
> > > Subject: [configuration]HierarchicalConfiguration
> > >
> > >
> > > Hello,
> > >
> > > I am working on a special Configuration implementation called
> > > HierarchicalConfiguration that avoids the problems I have
> > > outlined in my
> > > last posting (messing up structure of hierarchical XML
> > > documents). Therefor
> > > I use my own scheme of storing data.
> > >
> > > My class extends AbstractConfiguration. Implementing the
> > > abstract methods I
> > > found that this base class already makes certain assumptions
> > > about how data
> > > is stored, which makes implementation of some methods
> > > difficult. Especially
> > > addProperty() is problematic because it simply adds new
> > > properties to a
> > > Container object and wants to store this directly. This won't
> > > work with my
> > > implementation.
> > >
> > > In my opinion a better behavior for addProperty() would
> be to process
> > > collections and strings (as it does now) and then pass
> the results to
> > > addPropertyDirect(). The Container stuff could then be
> located in the
> > > addPropertyDirect() implementation of BaseConfiguration. What
> > > do you think
> > > about this?
> > >
> > > Regards
> > > Oli
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


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