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 Fri, 10 Oct 2003 09:32:11 GMT
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


Mime
View raw message