RE: [Configuration] Formatting of dom4j digester tag
Humm... I thinking that either hierarchical or hierarchicalDom4j.. I don't have a problem with long names, I think long and explicit is better then short and confusing! I lean towards removing the attribute from ConfigurationFactory to keep things as clean as possible. I think then that we should maybe lay out a road map of things to get done prior to getting out of sandbox: 1) Resolve the node name for hierarchical in dom4j. 2) Finish updating the docs. 3) Maybe get a jdbc configuration? I would love a JDBCConfiguration object, I haven't quite taken the time to put one together, but I recall someone mentioning they had one.. And then get the 1.0 release done as part of moving out of the sandbox... Are you by chance going to be attending the javapolis conference? (http://www.bejug.org/bejugPortal/appmanager/BeJUG/JP03) Eric -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Sunday, November 16, 2003 7:06 PM To: Jakarta Commons Developers List Subject: Re: [Configuration] Formatting of dom4j digester tag Eric, I think you are right with that className attribute. I have only restored support for it (for in the actual implementation it was not even evaluated) because the examples in the overview.html all had a className attribute. And at this time this was the easiest possibility to include HierarchicalDOM4JConfiguration as a configuration source for ConfigurationFactory. From a user's point of view it is surely cleaner to have a separate XML element. Should I change the code in ConfigurationFactory to completely get rid off this attribute (in theory it can be set for all other elements as well, but this doesn't make much sense)? Which element name do you prefer? hierarchical, hierarchicalDom4j, hieraDom4j, ...? (I have always trouble with comming up with a meaningful name). Hey, I really would like to see commons configuration comming out of the sandbox! Oli Eric Pugh wrote: Oliver, I was looking through the docs, and the /examples.html was a great way to go! Something that kinda jumped out at me, having really looked at the examples is the case where we want to load up a HierarchicalDOM4JConfiguration: dom4j className=org.apache.commons.configuration.HierarchicalDOM4J Configuration fileName=tables.xml/ It looks a little weird to have this optional attribute className. I am thinking that we should change instead to: dom4j fileName=gui.xml/ !--normal dom4j -- hierarchicalDom4j fileName=gui.xml/ !--heriarchical dom4j -- or hierarchical fileName=gui.xml/ !--heriarchical dom4j -- I am thinking that this might be a little cleaner.. do you foresee ever havign multiple classes providing the dom4j implementation? The className makes sense if we had 3 or more, but with just two, where the attribute is optional, it seems a little confusing.. any opinons? I am hoping to work towards getting the polish done on commons-configuration and then push for a move out of commons sandbox... Eric - 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]
Re: [Configuration] Formatting of dom4j digester tag
Okay, then I will change the element name to hierarchicalDom4j, remove the support for the className attribute (well I'm not sure if I should really remove this or leave it as undocumented feature; it's about a view lines in ConfigurationFactory that won't hurt) and update the examples and the overview page. At the moment I am also working on the ConfigurationXMLDocument class that allows XML-like processing on Configuration objects including interaction with Digester. I will add a section about this to the examples page, too. Concerning the road map: Is there still interest for the configuration singleton? I think this would be a handy feature. The ConfigurationService class you have written for Turbine would do the major part, wouldn't it? Oh, and I unfortunately don't visit the javapolis conference. Oli Eric Pugh wrote: Humm... I thinking that either hierarchical or hierarchicalDom4j.. I don't have a problem with long names, I think long and explicit is better then short and confusing! I lean towards removing the attribute from ConfigurationFactory to keep things as clean as possible. I think then that we should maybe lay out a road map of things to get done prior to getting out of sandbox: 1) Resolve the node name for hierarchical in dom4j. 2) Finish updating the docs. 3) Maybe get a jdbc configuration? I would love a JDBCConfiguration object, I haven't quite taken the time to put one together, but I recall someone mentioning they had one.. And then get the 1.0 release done as part of moving out of the sandbox... Are you by chance going to be attending the javapolis conference? (http://www.bejug.org/bejugPortal/appmanager/BeJUG/JP03) Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Formatting of dom4j digester tag
Um.. I would suggest just removing the code.. My fear when it comes to undocumented features is that the next committer won't have any idea what is going on, and will accidentally break something, especially if we don't have a unit test backing it up! Yeah, the question about a singleton is a good one.. There is so much opinon back and forth about the value of singletons.. I like them b/c they are easy.. I hate them because inevitably someone want's two configurations etc.. The singleton pattern can be implemented by many different containers if you start going the COP/IOC way.. Basically, I guess if someone wants to provide a good singleton implementation that has unit testing, then I'd be happy to have it. If you are deep and down working on ConfigurationXMLDocument, then would you like to wait for that before looking to move out of sandbox? Eric -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 11:14 AM To: Jakarta Commons Developers List Subject: Re: [Configuration] Formatting of dom4j digester tag Okay, then I will change the element name to hierarchicalDom4j, remove the support for the className attribute (well I'm not sure if I should really remove this or leave it as undocumented feature; it's about a view lines in ConfigurationFactory that won't hurt) and update the examples and the overview page. At the moment I am also working on the ConfigurationXMLDocument class that allows XML-like processing on Configuration objects including interaction with Digester. I will add a section about this to the examples page, too. Concerning the road map: Is there still interest for the configuration singleton? I think this would be a handy feature. The ConfigurationService class you have written for Turbine would do the major part, wouldn't it? Oh, and I unfortunately don't visit the javapolis conference. Oli Eric Pugh wrote: Humm... I thinking that either hierarchical or hierarchicalDom4j.. I don't have a problem with long names, I think long and explicit is better then short and confusing! I lean towards removing the attribute from ConfigurationFactory to keep things as clean as possible. I think then that we should maybe lay out a road map of things to get done prior to getting out of sandbox: 1) Resolve the node name for hierarchical in dom4j. 2) Finish updating the docs. 3) Maybe get a jdbc configuration? I would love a JDBCConfiguration object, I haven't quite taken the time to put one together, but I recall someone mentioning they had one.. And then get the 1.0 release done as part of moving out of the sandbox... Are you by chance going to be attending the javapolis conference? (http://www.bejug.org/bejugPortal/appmanager/BeJUG/JP03) Eric - 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]
Re: [Configuration] Formatting of dom4j digester tag
Eric Pugh wrote: Um.. I would suggest just removing the code.. My fear when it comes to undocumented features is that the next committer won't have any idea what is going on, and will accidentally break something, especially if we don't have a unit test backing it up! Sounds reasonable, I will remove it. Yeah, the question about a singleton is a good one.. There is so much opinon back and forth about the value of singletons.. I like them b/c they are easy.. I hate them because inevitably someone want's two configurations etc.. The singleton pattern can be implemented by many different containers if you start going the COP/IOC way.. Basically, I guess if someone wants to provide a good singleton implementation that has unit testing, then I'd be happy to have it. True. I think it won't be possible to come up with a solution everybody is happy with. My idea was to have a very easy way to access configuration properties without having to bother when and where they are loaded. But this raises a couple of questions, e.g. where to look for the configuration definition file, naming conventions, etc. If you are deep and down working on ConfigurationXMLDocument, then would you like to wait for that before looking to move out of sandbox? Eric ConfigurationXMLDocument is nearly finished. If nothing unexpected happens, I think I will need about two more days for updating the documentation. Then I can provide a final patch (including the other points on my todo list). Oli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Configuration] Formatting of dom4j digester tag
Eric, I think you are right with that className attribute. I have only restored support for it (for in the actual implementation it was not even evaluated) because the examples in the overview.html all had a className attribute. And at this time this was the easiest possibility to include HierarchicalDOM4JConfiguration as a configuration source for ConfigurationFactory. From a user's point of view it is surely cleaner to have a separate XML element. Should I change the code in ConfigurationFactory to completely get rid off this attribute (in theory it can be set for all other elements as well, but this doesn't make much sense)? Which element name do you prefer? hierarchical, hierarchicalDom4j, hieraDom4j, ...? (I have always trouble with comming up with a meaningful name). Hey, I really would like to see commons configuration comming out of the sandbox! Oli Eric Pugh wrote: Oliver, I was looking through the docs, and the /examples.html was a great way to go! Something that kinda jumped out at me, having really looked at the examples is the case where we want to load up a HierarchicalDOM4JConfiguration: dom4j className=org.apache.commons.configuration.HierarchicalDOM4JConfiguration fileName=tables.xml/ It looks a little weird to have this optional attribute className. I am thinking that we should change instead to: dom4j fileName=gui.xml/ !--normal dom4j -- hierarchicalDom4j fileName=gui.xml/ !--heriarchical dom4j -- or hierarchical fileName=gui.xml/ !--heriarchical dom4j -- I am thinking that this might be a little cleaner.. do you foresee ever havign multiple classes providing the dom4j implementation? The className makes sense if we had 3 or more, but with just two, where the attribute is optional, it seems a little confusing.. any opinons? I am hoping to work towards getting the polish done on commons-configuration and then push for a move out of commons sandbox... Eric - 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]
