RE: [Configuration] Issue with subset and substitution
Jörg Schaible wrote on Tuesday, March 30, 2004 12:37 AM: Eric Pugh wrote: If you have a closer look, it is quite obvious, why it does not work, since subset will mask now anything including the system properties. It seems that the values were resolved first in the previous version ... Comments? I think you are right.. I update scarab (scarab.tigris.org) to use the latest, and am having subset issues there as well... I did not want to create an issue in first place, since I was not sure, if such a resolving is really the right thing to do, but we should have a look at the old implementation. Basically I like the SubsetConfiguration a lot more than the old stuff. The (solved) problem with the HierarchicalConfiguration is also just because of a design flaw there and primilary not becasue of Subset itself. Well, I had a look at the old implementation of AbstractConfiguration.subset. Originally it created a new BasicConfiguration and copied all matching keys into it and ... explicitly called interpolate for the values. So we have definately a compatibility problem. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Configuration] Issue with subset and substitution
Jörg Schaible wrote: Additionally I do not grok why the TestJNDIConfiguration now fails for the getKeys call. It seems not to be different from the former implementation, but I am sure, the tests did not fail previously. The test didn't not fail because getKeys() wasn't tested :) My patch basing JNDIConfiguration on AbstractConfiguration added it. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Issue with subset and substitution
Emmanuel Bourg wrote on Tuesday, March 30, 2004 10:40 AM: Jörg Schaible wrote: Additionally I do not grok why the TestJNDIConfiguration now fails for the getKeys call. It seems not to be different from the former implementation, but I am sure, the tests did not fail previously. The test didn't not fail because getKeys() wasn't tested :) My patch basing JNDIConfiguration on AbstractConfiguration added it. :) Ahhh, I didn't had a look at the history of the test. Meanwhile I got also the impression, that this could have never worked with simple-jndi. Maybe we should switch to another implementtaion, since all what we want is to test the general JNDI interface and not that specific implementation. I had a look at JNDIKit from spice now located at codehaus.org. It provides a MemoryContext that could probably easily used. Even more, since this implementation supports also right-to-left namings and arbitrary delimiters so we could also mimic LDAP. I believe JNDIConfiguration would fail badly in this scenario. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Issue with subset and substitution
I am stilling looking around for a better JNDI implementation. With Tomcat, getKeys works properly, I am using JNDIConfiguration in production. Only with simpleJndi does it seem to fail.. Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 9:40 AM To: Jakarta Commons Developers List Subject: Re: [Configuration] Issue with subset and substitution Jörg Schaible wrote: Additionally I do not grok why the TestJNDIConfiguration now fails for the getKeys call. It seems not to be different from the former implementation, but I am sure, the tests did not fail previously. The test didn't not fail because getKeys() wasn't tested :) My patch basing JNDIConfiguration on AbstractConfiguration added it. Emmanuel Bourg - 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] Issue with subset and substitution
So, does that suggest that SubsetConfiguration needs to also call the interpolate? Eric -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 9:39 AM To: Jakarta Commons Developers List Subject: RE: [Configuration] Issue with subset and substitution Jörg Schaible wrote on Tuesday, March 30, 2004 12:37 AM: Eric Pugh wrote: If you have a closer look, it is quite obvious, why it does not work, since subset will mask now anything including the system properties. It seems that the values were resolved first in the previous version ... Comments? I think you are right.. I update scarab (scarab.tigris.org) to use the latest, and am having subset issues there as well... I did not want to create an issue in first place, since I was not sure, if such a resolving is really the right thing to do, but we should have a look at the old implementation. Basically I like the SubsetConfiguration a lot more than the old stuff. The (solved) problem with the HierarchicalConfiguration is also just because of a design flaw there and primilary not becasue of Subset itself. Well, I had a look at the old implementation of AbstractConfiguration.subset. Originally it created a new BasicConfiguration and copied all matching keys into it and ... explicitly called interpolate for the values. So we have definately a compatibility problem. Regards, Jörg - 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] Issue with subset and substitution
Eric Pugh wrote on Tuesday, March 30, 2004 10:59 AM: So, does that suggest that SubsetConfiguration needs to also call the interpolate? Well, see my patch. Works fine again ... but now we have the HierachicalConfiguration problem back. IMHO it would be better to resolve this in a cleaner solution. The current implementation is ... well, a bad hack ? Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Issue with subset and substitution
Eric Pugh wrote on Tuesday, March 30, 2004 10:59 AM: I am stilling looking around for a better JNDI implementation. With Tomcat, getKeys works properly, I am using JNDIConfiguration in production. Only with simpleJndi does it seem to fail.. No wonder if you look at the implementation. Did you also test with a LDAP context ? Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Issue with subset and substitution
No.. Haven't tested it at all with LDAP.. I understand that JNDI is an implementation based on LDAP? but haven't worked with LDAP in java world before.. Need to... Eric -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 10:13 AM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: RE: [Configuration] Issue with subset and substitution Eric Pugh wrote on Tuesday, March 30, 2004 10:59 AM: I am stilling looking around for a better JNDI implementation. With Tomcat, getKeys works properly, I am using JNDIConfiguration in production. Only with simpleJndi does it seem to fail.. No wonder if you look at the implementation. Did you also test with a LDAP context ? Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Issue with subset and substitution
Eric Pugh wrote on Tuesday, March 30, 2004 11:48 AM: No.. Haven't tested it at all with LDAP.. I understand that JNDI is an implementation based on LDAP? No, I mean the JDK comes walso with an LDAP provider for JNDI. The specification even contains nestes keys, but I did not grok that part fully. So basically such an JNDI key (or similar) could be valid: my.prop.to.ldap:cn=me,cn=user,dc=company,dc=org notice the change of the direction for the hierarchy ... but haven't worked with LDAP in java world before.. Need to... Eric Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Issue with subset and substitution
I think you are right.. I update scarab (scarab.tigris.org) to use the
latest, and am having subset issues there as well...
Argh..
Eric
-Original Message-
From: Jörg Schaible [mailto:[EMAIL PROTECTED]
Sent: Monday, March 29, 2004 5:56 PM
To: Jakarta Commons Developers List
Subject: [Configuration] Issue with subset and substitution
Hello folks,
today I've build a SNAPSHOT version of configurations and with
the new subsets I got a failed unit test in my own application.
I've boiled it down to something in commons-configuration that
worked before the subset refactoring:
/**
* Tests subsets and still can resolve elements
*/
public void testSubsetCanResolve() throws Exception
{
cc = new CompositeConfiguration();
final BaseConfiguration config = new BaseConfiguration();
config.addProperty(subset.tempfile, ${java.io.tmp}/file.tmp);
cc.addConfiguration(config);
cc.addConfiguration(ConfigurationConverter.getConfiguration(System
.getProperties()));
Configuration subset = cc.subset(subset);
assertEquals(System.getProperty(java.io.tmp) +
/file.tmp, subset.getString(tempfile));
}
If you have a closer look, it is quite obvious, why it does not
work, since subset will mask now anything including the system
properties. It seems that the values were resolved first in the
previous version ...
Comments?
Regards,
Jörg
-
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] Issue with subset and substitution
The problem HierarchicalConfiguration and related stuff had with SubsetConfiguration has to do with code in the ConfigurationXMLDocument class that tries to determine a correct ConfigurationXMLReader implementation for a passed in Configuration object. This code tests if the Configuration object is instance of HierarchicalConfiguration and this test breaks if a SubsetConfiguration is passed. I originally had suggested to add a getXMLReader() method to the Configuration interface. This would solve out problem now (ConfigurationXMLDocument could simply call this method and work on the returned reader). The reason why we decided against this was to keep the interface simple and not add methods for a probably rarely used feature. Oliver Jörg Schaible schrieb: Eric Pugh wrote: If you have a closer look, it is quite obvious, why it does not work, since subset will mask now anything including the system properties. It seems that the values were resolved first in the previous version ... Comments? I think you are right.. I update scarab (scarab.tigris.org) to use the latest, and am having subset issues there as well... I did not want to create an issue in first place, since I was not sure, if such a resolving is really the right thing to do, but we should have a look at the old implementation. Basically I like the SubsetConfiguration a lot more than the old stuff. The (solved) problem with the HierarchicalConfiguration is also just because of a design flaw there and primilary not becasue of Subset itself. Additionally I do not grok why the TestJNDIConfiguration now fails for the getKeys call. It seems not to be different from the former implementation, but I am sure, the tests did not fail previously. I've created an BugZilla issue for the fixed POM though ... Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inform. Oliver Heger Zentrale Informationsverarbeitung (ZIV) / Bereich Anwenderverfahren Klinikum der Philipps-Universität Marburg Bunsenstraße 3, D-35037 Marburg Tel: +49 6421 28-66592 mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Issue with subset and substitution
Oliver Heger wrote on Tuesday, March 30, 2004 8:31 AM: The problem HierarchicalConfiguration and related stuff had with SubsetConfiguration has to do with code in the ConfigurationXMLDocument class that tries to determine a correct ConfigurationXMLReader implementation for a passed in Configuration object. This code tests if the Configuration object is instance of HierarchicalConfiguration and this test breaks if a SubsetConfiguration is passed. Yes, but this is really ugly. The code relies heavily on internals and if you apply a delegator (like it is done with Subset) it breaks immediately. I originally had suggested to add a getXMLReader() method to the Configuration interface. This would solve out problem now (ConfigurationXMLDocument could simply call this method and work on the returned reader). The reason why we decided against this was to keep the interface simple and not add methods for a probably rarely used feature. IMHO a hierarchical configuration should be directly covered by the standard Configuration interface. Look e.g. at JNDI configuration. This should implement a hierarchical config also, because it *is* a tree. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Configuration] Issue with subset and substitution
I agree that the actual solution is ugly. So what do you suggest? Almost all features of a HierarchicalConfiguration can be used through the Configuration interface; there is just an enhanced syntax for property keys passed in the getter methods. The exception is XML handling. ConfigurationXMLDocument tries to convert a Configuration into a hierarchical XML document. This conversion at the moment makes indeed use of internal knowledge about the objects to convert because HierarchicalConfigurations are per se hierarchical. I think to avoid that the Configuration interface has to be changed. Oliver Jörg Schaible schrieb: Oliver Heger wrote on Tuesday, March 30, 2004 8:31 AM: The problem HierarchicalConfiguration and related stuff had with SubsetConfiguration has to do with code in the ConfigurationXMLDocument class that tries to determine a correct ConfigurationXMLReader implementation for a passed in Configuration object. This code tests if the Configuration object is instance of HierarchicalConfiguration and this test breaks if a SubsetConfiguration is passed. Yes, but this is really ugly. The code relies heavily on internals and if you apply a delegator (like it is done with Subset) it breaks immediately. I originally had suggested to add a getXMLReader() method to the Configuration interface. This would solve out problem now (ConfigurationXMLDocument could simply call this method and work on the returned reader). The reason why we decided against this was to keep the interface simple and not add methods for a probably rarely used feature. IMHO a hierarchical configuration should be directly covered by the standard Configuration interface. Look e.g. at JNDI configuration. This should implement a hierarchical config also, because it *is* a tree. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inform. Oliver Heger Zentrale Informationsverarbeitung (ZIV) / Bereich Anwenderverfahren Klinikum der Philipps-Universität Marburg Bunsenstraße 3, D-35037 Marburg Tel: +49 6421 28-66592 mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Issue with subset and substitution
Oliver Heger wrote on Tuesday, March 30, 2004 9:24 AM: I agree that the actual solution is ugly. So what do you suggest? Almost all features of a HierarchicalConfiguration can be used through the Configuration interface; there is just an enhanced syntax for property keys passed in the getter methods. The exception is XML handling. ConfigurationXMLDocument tries to convert a Configuration into a hierarchical XML document. This conversion at the moment makes indeed use of internal knowledge about the objects to convert because HierarchicalConfigurations are per se hierarchical. I think to avoid that the Configuration interface has to be changed. I would strongly propose to do so, but after 1.0 release. I just mensioned this, because we had to add this workaround to Subset and that we have this problems with Subset now reflects more the design flaws of Configuration itself than a bad implementation of Subset. Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
