RE: [commons-configuration] IniFile support
Oliver Siegmar wrote on Thursday, April 14, 2005 8:39 AM: Hi, does someone work on the IniFile support? If not, I could do... You might utilize http://www.ubique.ch/code/inieditor/. Lib comes with BSD style license and is very small and easy. You should use only the ctors with the streams though, since the ones with the file names do not close the file afterwards. Available on ibiblio http://www.ibiblio.org/maven/ubique/jars. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] IniFile support
Oliver Siegmar wrote on Thursday, April 14, 2005 11:12 AM: On Thursday 14 April 2005 10:55, Emmanuel Bourg wrote: Oliver Siegmar wrote: Does your implementation has default (a.k.a. global, a.k.a. common) section support? What do you mean by default section exactly ? Currently my implementation does the following: Many application ini files have some kind of default-section. Consider the following ini-file: [snip] well, such a behaviour would be different from all other configuration implemnetations and I don't think it is worth the hassle. You can have the same functionality with CompositeConfiguration either by using two files or two subsections: = % == app.ini: [section1] foo=10 defaults.ini: [section1] foo=30 val=50 CompositeConfiguration config = new CompositeConfiguration(); config.add(new IniConfiguration(app.ini)); config.add(new IniConfiguration(defaults.ini)); assertEquals(10,config.getInt(section1.foo)); assertEquals(50,config.getInt(section1.val)); = % == or = % == app.ini: [default] foo=30 val=50 [section1] foo=10 CompositeConfiguration config = new CompositeConfiguration(); Configuration iniConfig = new IniConfiguration(app.ini); config.add(iniConfig.subset(section1)); config.add(iniConfig.subset(default)); assertEquals(10,config.getInt(foo)); assertEquals(50,config.getInt(val)); = % == this mechanism is portable for all configurations (even mixed ones). You might keep your defaults in a DB and overwrite some from command line. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] DOM vs DOM4J
Emmanuel Bourg wrote: Is there a good reason to keep the configurations using DOM4J instead of their DOM based equivalent ? If there is no difference between the two I'm tempted to remove DOM4JConfiguration and HierarchicalDOM4JConfiguration (or to move them to a contrib directory), and then merge DOMConfiguration into XMLConfiguration and HierarchicalDOMJConfiguration into HierarchicalConfiguration. What do you think ? +1 -- Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] after 1.0.4: unfinished business
Gary Gregory wrote: Then there are questions like: should the memory log really be in CL as opposed to logj4? Well, see the focus of the class. It targets especially unit tests in combination with coverage tools. Personally I can live perfectly with the jdk logger (unless someone wants more sophisticated possibilities and is willing to pay the price in the increased project size for L4J). CL allows me to use the most lightweight implementation during development and using the MemoryLogger I can assure, that the logger code does not have impact on runtime behaviour (still using CL). -- Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [testutils] Is there any commons area for generic test code?
Hi Alex, in our project I have meanwhile also a collection of utility classes, that I use over again in unit tests. It might be good to have a more common pool. This might be also a candidate: http://issues.apache.org/bugzilla/show_bug.cgi?id=27663 -- Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [testutils] Is there any commons area for generic test code?
On Thursday 10 June 2004 16:18, Alex Karasulu wrote: AK On Thu, 2004-06-10 at 05:28, Jörg Schaible wrote: AK Hi Alex, AK AK in our project I have meanwhile also a collection of utility classes, that I AK use over again in unit tests. It might be good to have a more common pool. AK AK Great news Jörg! You put us over the top wrt my personal quota of 3 AK interested people. So you, Micheal Davey and I have shown interest so AK lets roll. :) AK I'll kick start a little sandbox project for common test related code AK shared across ASF projects. AK AK What shall we call it? I figure 'test' is short and to the point. Yes. But I believe we must setup some kind of guide line, what we try to include and what not. E.g. I also have a very simple http server in my test package, because I had to test classes that encapsulate some kind of client-side http-communication. While I see this as candidate, I would rather not want someone to enhance this for multithreading support and so on ... -- Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration]Release 1 and hierarchical configurations
Oliver Heger wrote: There is still the problem that the ConfigurationXMLDocument class is not fully compatible with SubsetConfiguration. I don't think that a quick and clean solution can be found for this problem soon, so I would like to suggest to drop this class and some of its helpers from the 1.0 release. The following files are affected: - ConfigurationXMLDocument.java and its test class TestConfigurationXMLDocument.java. - The three classes ending on XMLReader. Two of them have also test classes. - In the XML howto document the last section starting with XML processing must be removed. - In the conf directory testConfigurationXMLDocument.xml becomes obsolete. In another thread it was mentioned that in future the inherent hierarchical aspects of configuration sources should be more regarded. So I hope that it will be quite easy to re-introduce these classes later with a cleaner design. I was thinking a bit about those hierarchical aspects and how to provide access to them through the Configuration interface. My idea was to introduce an interface like ConfigurationNode that describes a node in a configuration tree. It could look similar to the HierarchicalProperties.Node class. Then a method getRoot() could be added to Configuration that returns the root node of the configuration tree thus providing a tree like view on a configuration. (By the way, there is already a class HierarchicalConfigurationConverter, which provides means to convert a flat configuration into a hierarchical one.) Just popped in my mind: What's the big difference between a Subset and a ConfigurationNode then ? IMHO the Subset *is* the Node for HierarchicalConfigurations ... Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] Cutting a 1.0 Release Help Needed
Eric Pugh wrote: Hi all, In response to a large number of posts I have recieved both on the mailing list and privately regarding when Commons Configuration 1.0 will be released, I have gone ahead and applied the last of the patches for bugs and I would like to cut the RC1 for Commons Configuration. Does that mean, the DOM JDK 1.4 support is not included in 1.0 ? Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Roadmap
Jörg Schaible wrote: I have another idea: We stay with the current class, but change its configuration files. We could define factory elements: factory type=xml className=org.apache.commons.configuration.DOMConfiguration / and use them now in config elements: config type=xml fileName=conf/test.xml [at=mail] / I realized, that such a config element must be defined more general: config type=xml uri=file:/conf/test.xml [at=mail] / or config type=ldap uri=ldap:ou=acme, ... [at=mail] / or config type=db uri=jdbc:...:table#column#key [at=mail] / in the end the factory has to know its own URI ... Then we could deprecate all of the current elements reading a configuration and may provide a DTD even if a customer writes his own configuration format. Additionally we remove the direct dependency for all the implementations from the ConfigurationFactory (no DOM4J, no DB, no JNDI if not used or needed). What do you think? IMHO better now than after release. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Roadmap
Jörg Schaible wrote: Emmanuel Bourg wrote on Thursday, March 04, 2004 2:48 PM: There has been some good ideas coming around [configuration] lately, I'd like to suggest a roadmap to sort what needs to be done before the 1.0 release and what could be added later: configuration 1.0 - make PropertiesConfiguration a full replacement for ExtendedProperties: add headers to .properties files (Bug 26092) and make Configuration extend Map. remove here also the dependency to StringUtils (just used to handle an empty String). Basic idea - if I just use properties and DOM, I would like to have the least number of dependencies as possible. If other lang functionality would have been used here, no problem - but *not* for an empty String test ... - comma separated values revamp - DOM4J dependency removal Working on this. I understand correctly, that this just means support of DOM, but no deprecation of JDOM ? Had less time this weekend than expected, but here it is at least the DOM support: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27498 Working also on a pluggable ConfigurationFactory. What is the intension for the functionality of the current ConfigurationFactory ? Support any Configuration type (= backward compatibility) ? I would introduce an AbtractConfigurationFactory refactoring the common parts. Name of the PluggableConfigurationFactory (ConfigurableConfigurationFactory g) ? Introduce a Jdk14ConfigurationFactory (with least number of dependencies) ? I have another idea: We stay with the current class, but change its configuration files. We could define factory elements: factory type=xml className=org.apache.commons.configuration.DOMConfiguration / and use them now in config elements: config type=xml fileName=conf/test.xml [at=mail] / Then we could deprecate all of the current elements reading a configuration and may provide a DTD even if a customer writes his own configuration format. Additionally we remove the direct dependency for all the implementations from the ConfigurationFactory (no DOM4J, no DB, no JNDI if not used or needed). What do you think? IMHO better now than after release. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] wrong test for CompositeConfiguration.subset ?
Emmanuel Bourg wrote: I tracked back the code to the version in Velocity, this was changed in the revision 1.14 of Configuration.java 3 years ago: http://cvs.apache.org/viewcvs.cgi/jakarta-velocity/src/java/org/apache/velocity/runtime/configuration/Configuration.java?r1=1.13r2=1.14diff_format=h It looks like a workaround to avoid an IndexOutOfBoundException if the key and the prefix have the same length on calling: key.substring(prefix.length() + 1); This feature is not documented in the javadoc and the subset produced is not useful. Even if it has been around for 3 years I think it's safe to assume nobody relies on this. Fine with me. I think also, it is more consistant to return null. Please apply first my patch of http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27427 to this function. You may just remove afterwards the test for equality. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] SubsetConfiguration
Emmanuel Bourg wrote: I have reimplemented the subset code with a decorator, the pros : - the resulting code is much cleaner - it fixes some old quicks - it fixes Bug 27427 OK. Then don't apply it g - no property is copied = more memory efficient - the subset is fully synchronized with its parent configuration Sounds fine. the cons: I should be at home at this hour ;) Good night, Sir! I had to change a test for HierarchicalConfiguration, I hope it doesn't break the initial intent. Better to change the test to sanctify the right behaviour as cement the quirks. :) Regards, Jörg BTW: HierarchicalDOMConfiguration is already running ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] SubsetConfiguration
Hi Eric, Eric Pugh wrote: Guys.. I have been a little remiss keeping up with the flow of patches.. However, this weekend I will go through them all and try and get all the good stuff updated. :) Emmanuel said he already made 27427 obsolete, but I could not see an issue in Bugzilla yet. Also, I think the roadmap is good.. I kinda wish more stuff was post 1.0, I really want to get the release out, but if we have people willing to do the work to incorporate these changes into 1.0, then I'm happy to hold off and keep the patches going. Well, I would also like to have a 1.0 soon, but without the necessity for Dom4J using JDK 1.4. This includes DOMConfiguration, HierarchicalDOMConfiguration and a ConfigurationFactory (similar class) not depedning on Dom4J either. I'll try and get the update on the website as well as an xdoc.. At one point I think there was a roadmap plugin? Really? Never heard of. But Maven is growing rapidly. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] SubsetConfiguration
Jörg Schaible wrote: Hi Eric, Eric Pugh wrote: Guys.. I have been a little remiss keeping up with the flow of patches.. However, this weekend I will go through them all and try and get all the good stuff updated. :) Emmanuel said he already made 27427 obsolete, but I could not see an issue in Bugzilla yet. Ups. Did not recoginze Emmanuel's attachments ... Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] SubsetConfiguration
Hi Emmanuel, Emmanuel Bourg wrote: I had to change a test for HierarchicalConfiguration, I hope it doesn't break the initial intent. after recognizing, that you've attached the diff, I had a look at the changes in the test case. I am not quite sure, that this is really good. Intentionally I thought, you would return an empty configuration only, if the pattern equals the key, but you do so now also if the pattern does not match at all. This will break my usage of Configuration for certain and I am probably not alone here. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Separate Directory for Commons Project files
This change would require the project.xml's for each project in both the jakarta-commons and jakarta-commons-sandbox to have its extends tag adjusted and any relative references to commons-site files adjusted. Well, I am not supposed to give a vote, but I want to remark that such a structure will also allow you to define external global entities in your (Maven) xml files, that can be inherited from the global commons-site project and you might write later on something like: !ENTITY dep-commons-logger-SNAPSHOT SYSTEM file:../commons-site/entities/dep-commons-logger-SNAPSHOT.entity !ENTITY dep-commons-jelly-SNAPSHOT SYSTEM file:../commons-site/entities/dep-commons-jelly-SNAPSHOT.entity dependencies dep-commons-logger-SNAPSHOT; dep-commons-jelly-SNAPSHOT; /dependencies You might do this also for developers or anything else, e.g. in our local project we split the site.jsl in this way: http://www.mail-archive.com/[EMAIL PROTECTED]/msg09093.html So you might gain a lot more with the new structure as originally thought :) Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
