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:[EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> > To: "'Jakarta Commons Developers List'" > <[EMAIL PROTECTED]> > Cc: "'Konstantin Shaposhnikov'" <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > 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:[EMAIL PROTECTED] > > > 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: [EMAIL PROTECTED] > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
