DO NOT REPLY [Bug 24262] - [configuration][PATCH]HierarchicalConfiguration and XMLReader
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=24262. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=24262 [EMAIL PROTECTED] changed: What|Removed |Added Component|Sandbox |Configuration -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24262] - [configuration][PATCH]HierarchicalConfiguration and XMLReader
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24262. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24262 [configuration][PATCH]HierarchicalConfiguration and XMLReader [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-11-14 18:45 --- Becomes obsolete by bug 24472. *** This bug has been marked as a duplicate of 24472 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration][PATCH]HierarchicalConfiguration
Oliver, I wanted to look at your code, but I don't seem to have it as an attachement.. Could you resend it or open a bug and attach it? Thanks.. ERic -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Monday, October 20, 2003 3:02 PM To: Jakarta Commons Developer List Subject: [configuration][PATCH]HierarchicalConfiguration Hi, I have now created a patch with my first implementation of HierarchicalConfiguration and related classes. Here are some remarks to the new classes: HierarchicalConfiguration This is a base class for configuration classes that use a hierarchical schema to store their properties. The class is fully functional and provides meaningful implementations for all abstract methods defined in AbstractConfiguration. HierarchicalDOM4JConfiguration A sub class of HierarchicalConfiguration that allows to parse XML documents using DOM4J. This class does the same as DOM4JConfiguration, but keeps the structure of the parsed documents. Saving of configuration properties is not implemented yet. HierarchicalConfigurationXMLReader This class is a faked SAX parser that operates on HierarchicalConfiguration objects. It processes a configuration object and generates corresponding SAX events that can be caught and evaluated by a ContentHandler implementation. The associated unit test shows how this class can be used to construct a DOM4J document from a configuration object. With this class it should also be possible to feed configuration objects into a Digester. ConfigurationKey This class is used internaly to construct keys and iterate over the single parts a key consists of. I made it public because it may be useful for clients as well. The class hides the concrete syntax of a property key, so instead of dealing with strings, property delimiters, index or attribute markers a client only needs to call methods of this class. There are unit tests for each of these classes; according to the reports they have a quite high coverage rate ;-) Please send me your critics, ideas and suggestions and your thoughts how (and if) to integrate this stuff with the existing code. I think the concept of transforming a Configuration object to XML by using a simplified SAX parser could be useful for non hierarchical configuration objects, too. So it would be nice to have a corresponding implementation. Then there is another idea that came me when I wrote HierarchicalDOM4JConfiguration: How about separating the code for writing configuration objects from the configuration classes? There could be different ConfigurationOutputter classes for different formats (properties, XML, ...). This would have a couple of advantages, e.g. it would allow to save configuration data in another format than it was loaded from. What do you mean? Oli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration][PATCH]HierarchicalConfiguration
Hi, I have now created a patch with my first implementation of HierarchicalConfiguration and related classes. Here are some remarks to the new classes: HierarchicalConfiguration This is a base class for configuration classes that use a hierarchical schema to store their properties. The class is fully functional and provides meaningful implementations for all abstract methods defined in AbstractConfiguration. HierarchicalDOM4JConfiguration A sub class of HierarchicalConfiguration that allows to parse XML documents using DOM4J. This class does the same as DOM4JConfiguration, but keeps the structure of the parsed documents. Saving of configuration properties is not implemented yet. HierarchicalConfigurationXMLReader This class is a faked SAX parser that operates on HierarchicalConfiguration objects. It processes a configuration object and generates corresponding SAX events that can be caught and evaluated by a ContentHandler implementation. The associated unit test shows how this class can be used to construct a DOM4J document from a configuration object. With this class it should also be possible to feed configuration objects into a Digester. ConfigurationKey This class is used internaly to construct keys and iterate over the single parts a key consists of. I made it public because it may be useful for clients as well. The class hides the concrete syntax of a property key, so instead of dealing with strings, property delimiters, index or attribute markers a client only needs to call methods of this class. There are unit tests for each of these classes; according to the reports they have a quite high coverage rate ;-) Please send me your critics, ideas and suggestions and your thoughts how (and if) to integrate this stuff with the existing code. I think the concept of transforming a Configuration object to XML by using a simplified SAX parser could be useful for non hierarchical configuration objects, too. So it would be nice to have a corresponding implementation. Then there is another idea that came me when I wrote HierarchicalDOM4JConfiguration: How about separating the code for writing configuration objects from the configuration classes? There could be different ConfigurationOutputter classes for different formats (properties, XML, ...). This would have a couple of advantages, e.g. it would allow to save configuration data in another format than it was loaded from. What do you mean? Oli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
