[jira] Commented: (CONFIGURATION-285) configuration fileName=local-configuration.xml config-optional=true / does not report parsing errors in local-configuration.xml
[ https://issues.apache.org/jira/browse/CONFIGURATION-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514507 ] Oliver Heger commented on CONFIGURATION-285: I follow your argumentation in principle, but I don't see an easy (and generic) way to find out when a subconfiguration is invalid. So the idea with the event listener approach is to provide a way for implementing this decision yourself. ATM there are no concrete plans for a 1.5 release yet. There are still some JIRA tickets, which need to be addressed. So, unfortunately, I really cannot anticipate a release date. configuration fileName=local-configuration.xml config-optional=true / does not report parsing errors in local-configuration.xml - Key: CONFIGURATION-285 URL: https://issues.apache.org/jira/browse/CONFIGURATION-285 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Thorbjørn Ravn Andersen Assignee: Oliver Heger Fix For: 1.5 I'm trying to build a configuration system to be shared between our Java applications. I therefore want to have optional configurations included from the main configuration file read by DefaultConfigurationBuilder configuration fileName=local-configuration.xml config-optional=true / I have found that if the sub-configuration file is invalid the error is silently ignored. The same without config-options=true results in a ConfigurationException to be thrown (which wraps a ConfigurationRuntimeException which wraps the ConfigurationException which wraps the SAXException). I believe that the behaviour is incorrect. The sub-configuration file should be skipped if not found, but any errors found when parsing the existing file should be logged. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-284) ability to read OS environment variables
[
https://issues.apache.org/jira/browse/CONFIGURATION-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514415
]
Oliver Heger commented on CONFIGURATION-284:
Vasily, many thanks for your contribution.
For the reasons outlined above I am still reluctant to add this feature to the
code base. If you don't mind I would bring this topic again to the commons
developer list and ask whether the opinion to support environment variables in
one of the core libraries has changed in the mean time.
What we could do in any case is adding your code to the WIKI in our examples
section:
http://wiki.apache.org/jakarta-commons/Configuration
ability to read OS environment variables
Key: CONFIGURATION-284
URL: https://issues.apache.org/jira/browse/CONFIGURATION-284
Project: Commons Configuration
Issue Type: New Feature
Components: Interpolation
Reporter: Aksel Schmidt
Priority: Minor
Attachments: EnvironmentConfiguration.java
suggestion:
interpolation with system environment, i.e.
${sys:user.name} reads from systemproperties (as of today)
${sysenv:TEMP} reads from OS environment
these can be parsed from a supported set of OS's - windows read from a set in
a cmd /c, unix/linux from an env etc. (just once on demand)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-285) configuration fileName=local-configuration.xml config-optional=true / does not report parsing errors in local-configuration.xml
[ https://issues.apache.org/jira/browse/CONFIGURATION-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-285: --- Fix Version/s: 1.5 Assignee: Oliver Heger configuration fileName=local-configuration.xml config-optional=true / does not report parsing errors in local-configuration.xml - Key: CONFIGURATION-285 URL: https://issues.apache.org/jira/browse/CONFIGURATION-285 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Thorbjørn Ravn Andersen Assignee: Oliver Heger Fix For: 1.5 I'm trying to build a configuration system to be shared between our Java applications. I therefore want to have optional configurations included from the main configuration file read by DefaultConfigurationBuilder configuration fileName=local-configuration.xml config-optional=true / I have found that if the sub-configuration file is invalid the error is silently ignored. The same without config-options=true results in a ConfigurationException to be thrown (which wraps a ConfigurationRuntimeException which wraps the ConfigurationException which wraps the SAXException). I believe that the behaviour is incorrect. The sub-configuration file should be skipped if not found, but any errors found when parsing the existing file should be logged. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-285) configuration fileName=local-configuration.xml config-optional=true / does not report parsing errors in local-configuration.xml
[ https://issues.apache.org/jira/browse/CONFIGURATION-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-285. Resolution: Fixed DefaultConfigurationBuilder now fires an error event when loading of an optional configuration source fails. If I understand this request correctly, you want to distinguish between cases where an optional configuration cannot be found and where it is present, but loading it causes an error. However this is not possible: Being present is specific for file-based configurations, but an optional configuration could be anything, e.g. a JNDI or database configuration. How could we decide, based on the thrown exceptions, whether the current problem was caused by a non-available configuration source or by a source that is available, but cannot be accessed because of an internal error? With the error listener mechanism you can hook into the process of loading the declared configuration sources. If an error occurs, you are notified and can make this decision yourself based on any criteria suitable for your concrete application and use case. configuration fileName=local-configuration.xml config-optional=true / does not report parsing errors in local-configuration.xml - Key: CONFIGURATION-285 URL: https://issues.apache.org/jira/browse/CONFIGURATION-285 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Thorbjørn Ravn Andersen Assignee: Oliver Heger Fix For: 1.5 I'm trying to build a configuration system to be shared between our Java applications. I therefore want to have optional configurations included from the main configuration file read by DefaultConfigurationBuilder configuration fileName=local-configuration.xml config-optional=true / I have found that if the sub-configuration file is invalid the error is silently ignored. The same without config-options=true results in a ConfigurationException to be thrown (which wraps a ConfigurationRuntimeException which wraps the ConfigurationException which wraps the SAXException). I believe that the behaviour is incorrect. The sub-configuration file should be skipped if not found, but any errors found when parsing the existing file should be logged. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-283) CombinedConfiguration doesn't take escaped characters into account.
[
https://issues.apache.org/jira/browse/CONFIGURATION-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-283.
Resolution: Fixed
A fix was applied to ConfigurationUtils.convertToHierarchical(), which was the
source of the problem.
This is a simple workaround for the problem with ConfigurationUtils.copy(). We
might want to touch this again when this problem is solved. But for the moment
everything works fine.
CombinedConfiguration doesn't take escaped characters into account.
---
Key: CONFIGURATION-283
URL: https://issues.apache.org/jira/browse/CONFIGURATION-283
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.4
Reporter: Franck Valentin
Assignee: Oliver Heger
Fix For: 1.5
Hi,
I've tried to used CombinedConfiguration but it seems escaped characters are
not taken into account :
import org.apache.commons.configuration.CombinedConfiguration;
import org.apache.commons.configuration.ConfigurationException;
import org.apache.commons.configuration.PropertiesConfiguration;
import junit.framework.TestCase;
public class TestProp extends TestCase {
public void testprop() throws ConfigurationException {
// test.properties contains :
//without_escape=aa,bb
//with_escape=aa\,bb
//with_2escapes=aa\\,bb
String prop_filename = c:\\tmp\\test.properties;
PropertiesConfiguration properties_config = new
PropertiesConfiguration(prop_filename);
CombinedConfiguration combined_config = new
CombinedConfiguration();
combined_config.addConfiguration(properties_config);
System.out.println(Properties config);
System.out.println(properties_config.getString(without_escape));
System.out.println(properties_config.getString(with_escape));
System.out.println(properties_config.getString(with_2escapes));
System.out.println(\nCombined config);
System.out.println(combined_config.getString(without_escape));
System.out.println(combined_config.getString(with_escape));
System.out.println(combined_config.getString(with_2escapes));
}
}
Result :
-
Properties config
aa
aa,bb
aa,bb
Combined config
aa
aa
aa
Thanks !
Franck
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-285) configuration fileName=local-configuration.xml config-optional=true / does not report parsing errors in local-configuration.xml
[ https://issues.apache.org/jira/browse/CONFIGURATION-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511852 ] Oliver Heger commented on CONFIGURATION-285: Just to make sure I understand your request correctly: If the config-optional attribute is set to true and loading this sub configuration causes an error, the exception should be logged. Other behavior need not be changed, correct? configuration fileName=local-configuration.xml config-optional=true / does not report parsing errors in local-configuration.xml - Key: CONFIGURATION-285 URL: https://issues.apache.org/jira/browse/CONFIGURATION-285 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Thorbjørn Ravn Andersen I'm trying to build a configuration system to be shared between our Java applications. I therefore want to have optional configurations included from the main configuration file read by DefaultConfigurationBuilder configuration fileName=local-configuration.xml config-optional=true / I have found that if the sub-configuration file is invalid the error is silently ignored. The same without config-options=true results in a ConfigurationException to be thrown (which wraps a ConfigurationRuntimeException which wraps the ConfigurationException which wraps the SAXException). I believe that the behaviour is incorrect. The sub-configuration file should be skipped if not found, but any errors found when parsing the existing file should be logged. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-283) CombinedConfiguration doesn't take escaped characters into account.
[
https://issues.apache.org/jira/browse/CONFIGURATION-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger updated CONFIGURATION-283:
---
Fix Version/s: 1.5
CombinedConfiguration doesn't take escaped characters into account.
---
Key: CONFIGURATION-283
URL: https://issues.apache.org/jira/browse/CONFIGURATION-283
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.4
Reporter: Franck Valentin
Fix For: 1.5
Hi,
I've tried to used CombinedConfiguration but it seems escaped characters are
not taken into account :
import org.apache.commons.configuration.CombinedConfiguration;
import org.apache.commons.configuration.ConfigurationException;
import org.apache.commons.configuration.PropertiesConfiguration;
import junit.framework.TestCase;
public class TestProp extends TestCase {
public void testprop() throws ConfigurationException {
// test.properties contains :
//without_escape=aa,bb
//with_escape=aa\,bb
//with_2escapes=aa\\,bb
String prop_filename = c:\\tmp\\test.properties;
PropertiesConfiguration properties_config = new
PropertiesConfiguration(prop_filename);
CombinedConfiguration combined_config = new
CombinedConfiguration();
combined_config.addConfiguration(properties_config);
System.out.println(Properties config);
System.out.println(properties_config.getString(without_escape));
System.out.println(properties_config.getString(with_escape));
System.out.println(properties_config.getString(with_2escapes));
System.out.println(\nCombined config);
System.out.println(combined_config.getString(without_escape));
System.out.println(combined_config.getString(with_escape));
System.out.println(combined_config.getString(with_2escapes));
}
}
Result :
-
Properties config
aa
aa,bb
aa,bb
Combined config
aa
aa
aa
Thanks !
Franck
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-275) ConfigurationUtils.append() doesn't merge list properties
[ https://issues.apache.org/jira/browse/CONFIGURATION-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511095 ] Oliver Heger commented on CONFIGURATION-275: Actually this seems to be a problem of AbstractConfiguration.addProperty(), which does not handle collection parameters properly when delimiter parsing is disabled. ConfigurationUtils.append() doesn't merge list properties - Key: CONFIGURATION-275 URL: https://issues.apache.org/jira/browse/CONFIGURATION-275 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Emmanuel Bourg Priority: Minor Fix For: 1.5 ConfigurationUtils.append() appends the list object instead of the list elements to the target list. If the list [X, Y] is appended to the list [A, B], the result is [A, B, [X, Y]] instead of [A, B, X, Y] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-282) NPE in HierarchicalConfiguration.fetchNodeList
[ https://issues.apache.org/jira/browse/CONFIGURATION-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511235 ] Oliver Heger commented on CONFIGURATION-282: A fix was committed that initializes the default expression engine every time if it is null. Can you please check whether this solves your problem? Unfortunately I have no idea how to write a unit test that demonstrates the problem. However because the defaultExpressionEngine field is now null at the beginning, code coverage should be complete. There is now some additional overhead because of the required synchronization of the static getDefaultExpressionEngine() method, which also gets called if no specific expression engine is set for a configuration instance. This could be avoided if the default expression engine is fetched once in the constructor of HierarchicalConfiguration and copied into the member field for the local expression engine. The drawback is that this could break existing code that relies on the fact that changing the default expression engine immediately impacts all configuration instances that have no specific expression engine set. So I would prefer making this change only in a major release. NPE in HierarchicalConfiguration.fetchNodeList -- Key: CONFIGURATION-282 URL: https://issues.apache.org/jira/browse/CONFIGURATION-282 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Environment: Linux, Java 1.5 Reporter: Dennis Kieselhorst Assignee: Oliver Heger java.lang.NullPointerException at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222) at org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:667) at org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:633) java.lang.NullPointerException at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1097) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1077) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-282) NPE in HierarchicalConfiguration.fetchNodeList after redeployment
[ https://issues.apache.org/jira/browse/CONFIGURATION-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-282: --- Fix Version/s: 1.5 Summary: NPE in HierarchicalConfiguration.fetchNodeList after redeployment (was: NPE in HierarchicalConfiguration.fetchNodeList) NPE in HierarchicalConfiguration.fetchNodeList after redeployment - Key: CONFIGURATION-282 URL: https://issues.apache.org/jira/browse/CONFIGURATION-282 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Environment: Linux, Java 1.5 Reporter: Dennis Kieselhorst Assignee: Oliver Heger Fix For: 1.5 java.lang.NullPointerException at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222) at org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:667) at org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:633) java.lang.NullPointerException at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1097) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1077) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-275) ConfigurationUtils.append() doesn't merge list properties
[ https://issues.apache.org/jira/browse/CONFIGURATION-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-275. Resolution: Fixed A fix was applied. addProperty() now always obtains an iterator for the property to add using PropertyConverter.toIterator(). If delimiter parsing is disabled, a null delimiter is passed in, so that no splitting is performed. ConfigurationUtils.append() doesn't merge list properties - Key: CONFIGURATION-275 URL: https://issues.apache.org/jira/browse/CONFIGURATION-275 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Emmanuel Bourg Assignee: Oliver Heger Priority: Minor Fix For: 1.5 ConfigurationUtils.append() appends the list object instead of the list elements to the target list. If the list [X, Y] is appended to the list [A, B], the result is [A, B, [X, Y]] instead of [A, B, X, Y] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-284) ability to read OS environment variables
[
https://issues.apache.org/jira/browse/CONFIGURATION-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510903
]
Oliver Heger commented on CONFIGURATION-284:
Joerg, I think this is a misunderstanding: This feature request is about
environment variables, while Configuration so far only supports Java's system
properties.
I had a vague memory that the topic access to environment variables was
discussed before on the commons mailing list, and found this reference:
http://thread.gmane.org/gmane.comp.jakarta.commons.devel/33239/focus=33325
Obviously this thread did not come to a final solution, AFAIK this feature was
not added to one of the commons libraries. If it was (for instance in
commons-lang), it would be really easy to incorporate it into
commons-configuration. But having to implement it ourselves, situation looks
different. The problem I see here is that it will really be difficult to
implement a robust and portable solution, and besides this feature is probably
out of scope for commons-configuration.
From Java 1.5 on, access to environment properties will be possible using
methods of the System class. So when we switch to this version (no idea when
this will happen though) it will be no problem to satisfy this request. But
for the moment I am reluctant.
ability to read OS environment variables
Key: CONFIGURATION-284
URL: https://issues.apache.org/jira/browse/CONFIGURATION-284
Project: Commons Configuration
Issue Type: New Feature
Components: Interpolation
Reporter: Aksel Schmidt
Priority: Minor
suggestion:
interpolation with system environment, i.e.
${sys:user.name} reads from systemproperties (as of today)
${sysenv:TEMP} reads from OS environment
these can be parsed from a supported set of OS's - windows read from a set in
a cmd /c, unix/linux from an env etc. (just once on demand)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-272) ConfigurationUtils.copy results in escaped , characters no longer being escaped
[ https://issues.apache.org/jira/browse/CONFIGURATION-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510904 ] Oliver Heger commented on CONFIGURATION-272: I think the problem here is that ConfigurationUtils operates on plain Configuration objects and does not know about specifics like list delimiters available only for classes derived from AbstractConfiguration. And performing a cast to AbstractConfiguration in these methods would be really ugly IMO. A solution would be to add new copy() and append() methods to AbstractConfiguration with the same semantics. Then we had full control over the copy process and could also determine, which events to generate (maybe it does not make sense to trigger an event for each copied property, but only one event for the whole copy operation). copy() and append() in ConfigurationUtils could then be deprecated, or at least a remark could be added to their documentation that the variants implemented by AbstractConfiguration are preferable. ConfigurationUtils.copy results in escaped , characters no longer being escaped - Key: CONFIGURATION-272 URL: https://issues.apache.org/jira/browse/CONFIGURATION-272 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Environment: commons 1.4 Reporter: John Meagher Assignee: Emmanuel Bourg Fix For: 1.5 When using ConfigurationUtils.copy to go between configuration formats any escaped out , characters are put into the output configuration without the escape character. This results in a different value being returned from getString calls as it now things the property is a list. If 4 escape characters are used instead of the expected 1 then the copy will end up with the correct value, but then the original will end up with the escape character as part of the property value. Example: SomeLongProperty=This is a test\, it is only a test # Ends up right in the copy, but not right in the original SomeOtherProperty=This is also a test, it is also only a test After copy: # Missing \ before , SomeLongProperty=This is a test, it is only a test SomeOtherProperty=This is also a test\, it is also only a test -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-282) NPE in HierarchicalConfiguration.fetchNodeList
[ https://issues.apache.org/jira/browse/CONFIGURATION-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509651 ] Oliver Heger commented on CONFIGURATION-282: So, the cause for this problem seems to be the static field for the default expression engine in HierarchicalConfiguration. After a redeploy it obviously looses its value and is set to null. I guess, it should be possible to initialize it lazily when it is accessed and it is null. But then the getDefaultExpressionEngine() method has to be synchronized. Does anybody have a better idea? There are probably other static fields in other classes, which can cause similar problems. NPE in HierarchicalConfiguration.fetchNodeList -- Key: CONFIGURATION-282 URL: https://issues.apache.org/jira/browse/CONFIGURATION-282 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Environment: Linux, Java 1.5 Reporter: Dennis Kieselhorst java.lang.NullPointerException at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222) at org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:667) at org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:633) java.lang.NullPointerException at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1097) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1077) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-283) CombinedConfiguration doesn't take escaped characters into account.
[
https://issues.apache.org/jira/browse/CONFIGURATION-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509653
]
Oliver Heger commented on CONFIGURATION-283:
Thank you for spotting this.
I had a look at the code, and it seems that this bug is related to
CONFIGURATION-272: Under the hood ConfigurationUtils.copy() is called, which
does not handle list delimiters correctly.
CombinedConfiguration doesn't take escaped characters into account.
---
Key: CONFIGURATION-283
URL: https://issues.apache.org/jira/browse/CONFIGURATION-283
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.4
Reporter: Franck Valentin
Hi,
I've tried to used CombinedConfiguration but it seems escaped characters are
not taken into account :
import org.apache.commons.configuration.CombinedConfiguration;
import org.apache.commons.configuration.ConfigurationException;
import org.apache.commons.configuration.PropertiesConfiguration;
import junit.framework.TestCase;
public class TestProp extends TestCase {
public void testprop() throws ConfigurationException {
// test.properties contains :
//without_escape=aa,bb
//with_escape=aa\,bb
//with_2escapes=aa\\,bb
String prop_filename = c:\\tmp\\test.properties;
PropertiesConfiguration properties_config = new
PropertiesConfiguration(prop_filename);
CombinedConfiguration combined_config = new
CombinedConfiguration();
combined_config.addConfiguration(properties_config);
System.out.println(Properties config);
System.out.println(properties_config.getString(without_escape));
System.out.println(properties_config.getString(with_escape));
System.out.println(properties_config.getString(with_2escapes));
System.out.println(\nCombined config);
System.out.println(combined_config.getString(without_escape));
System.out.println(combined_config.getString(with_escape));
System.out.println(combined_config.getString(with_2escapes));
}
}
Result :
-
Properties config
aa
aa,bb
aa,bb
Combined config
aa
aa
aa
Thanks !
Franck
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-282) NPE in HierarchicalConfiguration.fetchNodeList
[ https://issues.apache.org/jira/browse/CONFIGURATION-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508919 ] Oliver Heger commented on CONFIGURATION-282: A NPE on this line would mean that getExpressionEngine() returns null, which normally should not happen. Is it possible that you do something with serialization or hot-deployment of your application? This could be an explanation why the static defaultExpressionEngine field is null. NPE in HierarchicalConfiguration.fetchNodeList -- Key: CONFIGURATION-282 URL: https://issues.apache.org/jira/browse/CONFIGURATION-282 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Environment: Linux, Java 1.5 Reporter: Dennis Kieselhorst java.lang.NullPointerException at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222) at org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:667) at org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:633) java.lang.NullPointerException at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1097) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1077) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-282) NPE in HierarchicalConfiguration.fetchNodeList
[ https://issues.apache.org/jira/browse/CONFIGURATION-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508306 ] Oliver Heger commented on CONFIGURATION-282: It would really be helpful if you could provide some more information: How did you create the configuration object, which properties were set and which key did you pass in. Since the last release development has been going on, so the line numbers are no longer valid. Thanks. NPE in HierarchicalConfiguration.fetchNodeList -- Key: CONFIGURATION-282 URL: https://issues.apache.org/jira/browse/CONFIGURATION-282 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Environment: Linux, Java 1.5 Reporter: Dennis Kieselhorst java.lang.NullPointerException at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222) at org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:667) at org.apache.commons.configuration.AbstractConfiguration.getBoolean(AbstractConfiguration.java:633) java.lang.NullPointerException at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:721) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.fetchNodeList(AbstractHierarchicalFileConfiguration.java:338) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:284) at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.getProperty(AbstractHierarchicalFileConfiguration.java:319) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1222) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1097) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1077) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-281) JNDIConfiguration::recursiveGetKeys goes out of stack
[ https://issues.apache.org/jira/browse/CONFIGURATION-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-281. Resolution: Fixed A fix was applied. Please check if this works for you. When I find the time I would like to improve JNDIConfiguration: make it a true hierarchical configuration, support updates of the JNDI tree, etc. This would be a good opportunity for adding a maxDepth property. JNDIConfiguration::recursiveGetKeys goes out of stack - Key: CONFIGURATION-281 URL: https://issues.apache.org/jira/browse/CONFIGURATION-281 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Environment: Websphere 5.1 Reporter: Michiel Kalkman Fix For: 1.5 There can be cycles in contexts. Websphere 5.1 certainly does have them. When getKeys() is called on a JNDIConfiguration, eventually recursiveGetKeys() is called, which calls itself for every subcontext. This will never stop if there is a cycle. I would like to suggest the following changes to recursiveGetKeys() to fix this: 1) check for each subcontext if it has been processed before. If so, don't process it. An additional stack argument to recursiveGetKeys() should do the trick here. 2) a maxDepth attribute, like jndi maxDepth=4/. If the number of subcontexts is equal to maxDepth, stop processing. The maxDepth attribute should be optional of course, and have a default value like 911or so. The stack argument could be used to check the amount of subcontexts processed. Because I want to be able to dump the configuration for debugging purposes, this item is of somewhat importance to me. I tested this in 1.2 at work, so I cannot easily test this against 1.4. But as the code of 1.4 seems to be more or less the same, I think the problem still exists. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-281) JNDIConfiguration::recursiveGetKeys goes out of stack
[ https://issues.apache.org/jira/browse/CONFIGURATION-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506670 ] Oliver Heger commented on CONFIGURATION-281: I did some testing and could reproduce the problem with mock objects. 1) fixed the problem, assuming that the involved Context objects have a meaningful implementation of equals() and hashCode(). Why would 2) be necessary in addition to 1)? JNDIConfiguration::recursiveGetKeys goes out of stack - Key: CONFIGURATION-281 URL: https://issues.apache.org/jira/browse/CONFIGURATION-281 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Environment: Websphere 5.1 Reporter: Michiel Kalkman Fix For: 1.5 There can be cycles in contexts. Websphere 5.1 certainly does have them. When getKeys() is called on a JNDIConfiguration, eventually recursiveGetKeys() is called, which calls itself for every subcontext. This will never stop if there is a cycle. I would like to suggest the following changes to recursiveGetKeys() to fix this: 1) check for each subcontext if it has been processed before. If so, don't process it. An additional stack argument to recursiveGetKeys() should do the trick here. 2) a maxDepth attribute, like jndi maxDepth=4/. If the number of subcontexts is equal to maxDepth, stop processing. The maxDepth attribute should be optional of course, and have a default value like 911or so. The stack argument could be used to check the amount of subcontexts processed. Because I want to be able to dump the configuration for debugging purposes, this item is of somewhat importance to me. I tested this in 1.2 at work, so I cannot easily test this against 1.4. But as the code of 1.4 seems to be more or less the same, I think the problem still exists. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-278) ConcurrentModificationException in PropertiesConfigurationLayout
[ https://issues.apache.org/jira/browse/CONFIGURATION-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-278. Resolution: Won't Fix The Javadocs of the most popular configuration classes were updated with notes about threading issues. A similar note was also added to the user guide. PropertiesConfiguration is not thread-safe per se, so closing this issue as won't fix. If desired, a new ticket can be created for requesting means of supporting synchronized configurations. ConcurrentModificationException in PropertiesConfigurationLayout Key: CONFIGURATION-278 URL: https://issues.apache.org/jira/browse/CONFIGURATION-278 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Emmanuel Bourg Fix For: 1.5 PropertiesConfigurationLayout is not thread safe, if a configuration event is received when the configuration is being saved, a ConcurrentModificationException is thrown : java.util.ConcurrentModificationException at org.apache.commons.collections.map.AbstractLinkedMap$LinkIterator.nextEntry(AbstractLinkedMap.java:555) at org.apache.commons.collections.map.AbstractLinkedMap$KeySetIterator.next(AbstractLinkedMap.java:455) at org.apache.commons.configuration.PropertiesConfigurationLayout.save(PropertiesConfigurationLayout.java:455) at org.apache.commons.configuration.PropertiesConfiguration.save(PropertiesConfiguration.java:410) at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:517) at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:484) at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:451) at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:425) at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:373) at org.apache.commons.configuration.AbstractFileConfiguration.possiblySave(AbstractFileConfiguration.java:725) at org.apache.commons.configuration.AbstractFileConfiguration.clearProperty(AbstractFileConfiguration.java:764) at org.apache.commons.configuration.DataConfiguration.clearProperty(DataConfiguration.java:109) at org.apache.commons.configuration.AbstractConfiguration.setProperty(AbstractConfiguration.java:483) This happens easily in a multi threaded application using a central configuration with auto saved enabled. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-277) AbstractConfiguration should handle UnsupportedOperationExceptions in Iterator.remove() gracefully
[
https://issues.apache.org/jira/browse/CONFIGURATION-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-277.
Resolution: Fixed
Fix Version/s: 1.5
A fix was applied that catches the potential UnsupportedOperationException. If
such an exception is caught, clearProperty() will be called for the remaining
properties.
AbstractConfiguration should handle UnsupportedOperationExceptions in
Iterator.remove() gracefully
--
Key: CONFIGURATION-277
URL: https://issues.apache.org/jira/browse/CONFIGURATION-277
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.4
Reporter: Michael Rudolf
Assignee: Oliver Heger
Fix For: 1.5
Hi,
In AbstractConfiguration method clear() on line 533 (see code below) a
possible UnsupportedOperationException is not caught resulting in the
malfunctioning of the whole method. However, the documentation of the
getKeys() method itself warns about relying on the remove() method of
interface Iterator. The clear() method should not propagate that exception,
it should catch it and try the clearProperty(String) approach if the remove()
method is not supported.
Iterator it = getKeys();
while (it.hasNext())
{
String key = (String) it.next();
it.remove();
--- EVIL!
if (containsKey(key))
{
// workaround for Iterators that do not remove the
property on calling remove()
clearProperty(key);
}
Best regards,
Michael
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-280) autoSave and FileChangedReloadingStrategy corrupts configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-280.
Resolution: Fixed
Fix Version/s: 1.5
Patch applied. A test case was also added.
Many thanks!
autoSave and FileChangedReloadingStrategy corrupts configuration
Key: CONFIGURATION-280
URL: https://issues.apache.org/jira/browse/CONFIGURATION-280
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.4
Environment: Linux, Sun Java 5
Reporter: Roman Kurmanowytsch
Assignee: Oliver Heger
Fix For: 1.5
Attachments: autosave_reload.patch.txt
First of all, sorry if this is not a bug. I may have missed some information
on how to make autoSave and FileChangedReloadingStrategy work.
When a change has been detected by the FileChangedReloadingStrategy code, a
clear() followed by a load() is executed in the AbstractFileConfiguration
class (around line 809 of version 1.4). The clear() method leads to a
possiblySave() call which overwrites the configuration. At the end of the
clear() method, the configuration file is empty and the following load()
method loads this empty configuration. The possiblySave() call is invoked via
the work-around (according to the comment in the code) in
AbstractConfiguration (line 538).
I'm using the following code:
CompositeConfiguration config = new CompositeConfiguration();
XMLConfiguration xmlconfig = new XMLConfiguration(config.xml);
FileChangedReloadingStrategy fcrs = new FileChangedReloadingStrategy();
xmlconfig.setReloadingStrategy(fcrs);
config.addConfiguration(new SystemConfiguration());
config.addConfiguration(xmlconfig);
xmlconfig.setAutoSave(true);
...wait for config changes...
A workaround for the problem is to deactivate autoSave in the reload() method
of the AbstractFileConfiguration class. After the configuration is cleared
and loaded, the original autoSave is restored. See the diff below:
806a807,808
boolean autoSaveBak = this.isAutoSave(); // save
the current state
this.setAutoSave(false); // deactivate autoSave to
prevent information loss
813a816
this.setAutoSave(autoSaveBak); // set
autoSave to previous value
The code fragment looks like:
--
if (strategy.reloadingRequired())
{
if (getLogger().isInfoEnabled())
{
getLogger().info(Reloading configuration. URL is
+ getURL());
}
fireEvent(EVENT_RELOAD, null, getURL(), true);
setDetailEvents(false);
boolean autoSaveBak = this.isAutoSave(); // save the
current state
this.setAutoSave(false); // deactivate autoSave to
prevent information loss
try
{
clear();
load();
}
finally
{
this.setAutoSave(autoSaveBak); // set
autoSave to previous value
setDetailEvents(true);
}
fireEvent(EVENT_RELOAD, null, getURL(), false);
// notify the strategy
strategy.reloadingPerformed();
}
--
I hope this is a valid fix.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-279) PropertiesConfiguration dysfunctional if constructed with nonexistent File
[ https://issues.apache.org/jira/browse/CONFIGURATION-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-279. Resolution: Fixed Fix Version/s: 1.5 A fix was applied. Thank you for spotting this. This was a pretty comprehensive analysis of the problem :-) PropertiesConfiguration dysfunctional if constructed with nonexistent File -- Key: CONFIGURATION-279 URL: https://issues.apache.org/jira/browse/CONFIGURATION-279 Project: Commons Configuration Issue Type: Bug Components: Events Notifications Affects Versions: 1.4 Reporter: Tuure Laurinolli Assignee: Oliver Heger Fix For: 1.5 When PropertiesConfiguration is constructed around a File that does not exist, everything seemingly goes well, but saving the configuration only results in an empty file. This differs from constructing a PropertiesConfiguration around a file name passed as String, which appropriately fails at construction-time, since it tries to load() the configuration, which fails. When the nonexistent configuration file is passed as File, this does not happen, since the File constructor in AbstractFileConfiguration specifically tests if the file exists before calling load() and succeeds even if it wasn't called. However, if load() is not called, no PropertiesConfigurationLayout is created or registered to the EventSource, and thus nothing is saved when save() is called on the PropertiesConfiguration. Calling save() actually calls getLayout(), which creates a layout and registers it, but the properties set between construction of the PropertiesConfiguration and calling save() on it are still lost. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-278) ConcurrentModificationException in PropertiesConfigurationLayout
[ https://issues.apache.org/jira/browse/CONFIGURATION-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500685 ] Oliver Heger commented on CONFIGURATION-278: Most of our configuration classes are not thread-safe when they are updated (concurrent read-only access should be unproblematic though). For instance BaseConfiguration uses a plain Map for storing its data. I disagree that unpredictable results in case of concurrent modifications are better than an exception. This would make bugs of this kind nearly undetectable. The tread-safety (or unsafety) of the configuration classes should be clearly documented (I am not sure whether there is already some information about this on our site), then it is up to the user to handle this properly. A decorator for synchronizing configurations is something I also had in mind. This is analogous to the way the Java collections framework handles this topic: plain collections are unsynchronized, but if needed, synchronization can easily be added. I am not sure how such a decorator could be implemented in an elegant way; maybe AOP or dynamic proxies could be a good choice. So I would suggest closing this ticket as WON'T FIX and opening a new one for the decorator. ConcurrentModificationException in PropertiesConfigurationLayout Key: CONFIGURATION-278 URL: https://issues.apache.org/jira/browse/CONFIGURATION-278 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Emmanuel Bourg Fix For: 1.5 PropertiesConfigurationLayout is not thread safe, if a configuration event is received when the configuration is being saved, a ConcurrentModificationException is thrown : java.util.ConcurrentModificationException at org.apache.commons.collections.map.AbstractLinkedMap$LinkIterator.nextEntry(AbstractLinkedMap.java:555) at org.apache.commons.collections.map.AbstractLinkedMap$KeySetIterator.next(AbstractLinkedMap.java:455) at org.apache.commons.configuration.PropertiesConfigurationLayout.save(PropertiesConfigurationLayout.java:455) at org.apache.commons.configuration.PropertiesConfiguration.save(PropertiesConfiguration.java:410) at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:517) at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:484) at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:451) at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:425) at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:373) at org.apache.commons.configuration.AbstractFileConfiguration.possiblySave(AbstractFileConfiguration.java:725) at org.apache.commons.configuration.AbstractFileConfiguration.clearProperty(AbstractFileConfiguration.java:764) at org.apache.commons.configuration.DataConfiguration.clearProperty(DataConfiguration.java:109) at org.apache.commons.configuration.AbstractConfiguration.setProperty(AbstractConfiguration.java:483) This happens easily in a multi threaded application using a central configuration with auto saved enabled. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-3) Drop 1st class dependency on commons-logging
[ https://issues.apache.org/jira/browse/CONFIGURATION-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500818 ] Oliver Heger commented on CONFIGURATION-3: -- An ad-hoc fix for this problem would be to copy the NoLog class into Commons Configuration (with default visibility). This implementation is trivial. Drop 1st class dependency on commons-logging Key: CONFIGURATION-3 URL: https://issues.apache.org/jira/browse/CONFIGURATION-3 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.2 Reporter: Joerg Schaible Priority: Minor Fix For: 2.0 Currently commons-logging is reported as first class dependency in the project reports. This is not true. The only classes that make direct usage of JCL are ConfigurationDynaBean/Class and this only for tracing. It would be nice to eliminate this reference at all and list JCL only as transitive dependency of digester and beanutils. We might support logging with the monitor/listener concept of http://issues.apache.org/bugzilla/show_bug.cgi?id=38929 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-277) AbstractConfiguration should handle UnsupportedOperationExceptions in Iterator.remove() gracefully
[
https://issues.apache.org/jira/browse/CONFIGURATION-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500846
]
Oliver Heger commented on CONFIGURATION-277:
Well, clearProperty() is already invoked in the loop as a fall back if removing
through the iterator does not work. So for an iterator that does not support
the remove() method there are the following possibilities:
(1) If it operates on a disjunct set of keys, clearProperty() will work and
everything is fine.
(2) If it is affected by clearProperty(), a ConcurrentModificationException
will be thrown. In this case, we have basically transformed the
UnsupportedOperationException into another one, so we have not made things
worse.
In case of (2) the implementor of the derived Configuration class is forced to
write a custom clear() implementation. In case of (1) we have made the
implementor's life a bit easier. So we would have a certain gain.
AbstractConfiguration should handle UnsupportedOperationExceptions in
Iterator.remove() gracefully
--
Key: CONFIGURATION-277
URL: https://issues.apache.org/jira/browse/CONFIGURATION-277
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.4
Reporter: Michael Rudolf
Hi,
In AbstractConfiguration method clear() on line 533 (see code below) a
possible UnsupportedOperationException is not caught resulting in the
malfunctioning of the whole method. However, the documentation of the
getKeys() method itself warns about relying on the remove() method of
interface Iterator. The clear() method should not propagate that exception,
it should catch it and try the clearProperty(String) approach if the remove()
method is not supported.
Iterator it = getKeys();
while (it.hasNext())
{
String key = (String) it.next();
it.remove();
--- EVIL!
if (containsKey(key))
{
// workaround for Iterators that do not remove the
property on calling remove()
clearProperty(key);
}
Best regards,
Michael
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-277) AbstractConfiguration should handle UnsupportedOperationExceptions in Iterator.remove() gracefully
[
https://issues.apache.org/jira/browse/CONFIGURATION-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500464
]
Oliver Heger commented on CONFIGURATION-277:
Okay, we can change this.
Is there a concrete Configuration class you have trouble with or is the purpose
of this issue just to avoid pitfalls when creating new Configuration
implementations derived from AbstractConfiguration?
AbstractConfiguration should handle UnsupportedOperationExceptions in
Iterator.remove() gracefully
--
Key: CONFIGURATION-277
URL: https://issues.apache.org/jira/browse/CONFIGURATION-277
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.4
Reporter: Michael Rudolf
Hi,
In AbstractConfiguration method clear() on line 533 (see code below) a
possible UnsupportedOperationException is not caught resulting in the
malfunctioning of the whole method. However, the documentation of the
getKeys() method itself warns about relying on the remove() method of
interface Iterator. The clear() method should not propagate that exception,
it should catch it and try the clearProperty(String) approach if the remove()
method is not supported.
Iterator it = getKeys();
while (it.hasNext())
{
String key = (String) it.next();
it.remove();
--- EVIL!
if (containsKey(key))
{
// workaround for Iterators that do not remove the
property on calling remove()
clearProperty(key);
}
Best regards,
Michael
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-278) ConcurrentModificationException in PropertiesConfigurationLayout
[ https://issues.apache.org/jira/browse/CONFIGURATION-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500225 ] Oliver Heger commented on CONFIGURATION-278: The internally used layoutData map should probably be better synchronized. Just wondering: How can an event be received while the save() method is executed? Is the PropertiesConfiguration object that is accessed by multiple threads properly synchronized? We state that configurations need to be manually synchronized if they are modified concurrently. ConcurrentModificationException in PropertiesConfigurationLayout Key: CONFIGURATION-278 URL: https://issues.apache.org/jira/browse/CONFIGURATION-278 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Emmanuel Bourg Fix For: 1.5 PropertiesConfigurationLayout is not thread safe, if a configuration event is received when the configuration is being saved, a ConcurrentModificationException is thrown : java.util.ConcurrentModificationException at org.apache.commons.collections.map.AbstractLinkedMap$LinkIterator.nextEntry(AbstractLinkedMap.java:555) at org.apache.commons.collections.map.AbstractLinkedMap$KeySetIterator.next(AbstractLinkedMap.java:455) at org.apache.commons.configuration.PropertiesConfigurationLayout.save(PropertiesConfigurationLayout.java:455) at org.apache.commons.configuration.PropertiesConfiguration.save(PropertiesConfiguration.java:410) at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:517) at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:484) at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:451) at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:425) at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:373) at org.apache.commons.configuration.AbstractFileConfiguration.possiblySave(AbstractFileConfiguration.java:725) at org.apache.commons.configuration.AbstractFileConfiguration.clearProperty(AbstractFileConfiguration.java:764) at org.apache.commons.configuration.DataConfiguration.clearProperty(DataConfiguration.java:109) at org.apache.commons.configuration.AbstractConfiguration.setProperty(AbstractConfiguration.java:483) This happens easily in a multi threaded application using a central configuration with auto saved enabled. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (CONFIGURATION-276) java.util.prefs Configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger moved COLLECTIONS-254 to CONFIGURATION-276: Key: CONFIGURATION-276 (was: COLLECTIONS-254) Project: Commons Configuration (was: Commons Collections) java.util.prefs Configuration - Key: CONFIGURATION-276 URL: https://issues.apache.org/jira/browse/CONFIGURATION-276 Project: Commons Configuration Issue Type: Wish Reporter: Michael Rudolf Priority: Minor Hi, I have read that Commons Configuration is intended to be compatible with Java 1.3 but would it be possible to create a configuration backend for the Preferences API provided since Java 1.4? In my project I would like to use a very low-overhead configuration mechanism as is the Preferences API while still having the flexibility and power offered by Commons Configuration. In fact, being able to swap in a config file for testing purposes without changing the code would be wonderful. However, I do not like the idea of providing the end user with such a file or even a database, changing application settings should be done through the UI. If it is not possible to add a preferences backend to the code base due to the backward compatibility policy, could such a backend then possibly be provided in another branch or in a subproject? Best regards, Michael -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-215) Using relative URLs
[
https://issues.apache.org/jira/browse/CONFIGURATION-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-215.
Resolution: Fixed
getSource() methods were added to CompositeConfiguration and
CombinedConfiguration. Please have a look at the Javadocs for an exact
description of the semantics.
Using relative URLs
---
Key: CONFIGURATION-215
URL: https://issues.apache.org/jira/browse/CONFIGURATION-215
Project: Commons Configuration
Issue Type: Improvement
Affects Versions: 1.3
Reporter: Michiel Kalkman
Assigned To: Oliver Heger
Priority: Minor
Fix For: 1.5
It would be useful to be able to specify URLs in configuration item values
that are relative to the configuration.
A sample. I have the following files.
A/config.xml which refers to
B/specificConfigForB.xml which refers to
B/somefile
Now specifying the location of somefile in specificConfigForB.xml should be
possible using a relative URL, such that it is possible to retrieve the
absolute URL of somefile through:
a) the absolute URL of A/config.xml (e.g.: file:/c:/A/config.xml or
http://A/config.xml)
b) the relative URL of somefile specified in B/specificConfigForB.xml (like
somefilesomefile/somefile)
(1) One solution is to make it possible to find the location of the
configuration file that specifies the relative URL. Or more general, commons
config should know where a given configuration item is stored.
In this case it might be an idea to implement a getURL() on the Configuration
interface which uses:
1. the absolute URL of the composite configuration file, (A/config.xml)
2. the relative URL to the specfying configuration file,
(B/specificConfigForB.xml)
3. the relative URL specified (in B/specificConfigForB.xml)
(2) Another solution is to specify a special meta variable (like ${url}) that
can be used to specify the location of the specifying configuration file wrt
the composite configuration file. E.g. somefile${url}/somefile/somefile
would result in ../B/somefile.
(3) Another solution would be to specify a special attribute to indicate that
the value specified is an URL. Like somefile type=URLsomefile/somefile.
The advantage of solution (1) is that no extra semantics are introduced to
the configuration files. Furthermore, it might possibly be useful in
debugging situations. The advantages of solution (2) is that in this manner
other meta variables might be introduced. The disadvantage of solution (3) is
that this one cannot be applied to property files.
See also
http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200606.mbox/[EMAIL
PROTECTED]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-253) FileConfiguration getFile(), getFileName(), getBasePath() are not always consistent
[ https://issues.apache.org/jira/browse/CONFIGURATION-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-253. Resolution: Fixed I think this issue can now be marked as fixed. FileConfiguration getFile(), getFileName(), getBasePath() are not always consistent --- Key: CONFIGURATION-253 URL: https://issues.apache.org/jira/browse/CONFIGURATION-253 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Reporter: Thomas Wabner Assigned To: Oliver Heger Fix For: 1.5 Taken from the maillinglist: I have a properties configuration which is loaded without a problem. Later in my application I will access the file which is aligned to this configuration. final IFileConfiguration _productConf = _conf.getProductConfigurations().get(_productId); log.debug(product conf file + _productConf.getFile()); log.debug(product conf filename + _productConf.getFileName()); log.debug(product conf base path + _productConf.getBasePath()); The methods _productConf.getFile() and _productConf.getFileName() returning null but the getBasePath() returns a path which is correct (like file:/C:/Projects/workspace/myProject/project.properties). Seems for me like a bug because the PropertiesConfiguration is loaded correct and works. By side: I have also set a file reloading strategy for this configuration. Any ideas what's happen in this case or where I can find the problem? It would be nicer to get the File() instead the BasePath which has to be converted into a URL before I can access the whole properties file. Thanks in advance, - Thomas Wabner Thomas, you are right, the conversions between a base path, a file name, and a File are not always consistent. How did you load the configuration (this determines, which internal fields are set)? I would recommend to work with URLs, i.e. the method getURL(). A file-based configuration's URL is always defined. If you like, you can open a Jira ticket for this problem. Thanks. Oliver The file is loaded in this way: _productConf = new ProductConfiguration(); _productConf.load(FileTools.getPathForList(_propductPathList).getPath()); means the load method gets an String and not an File. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-273) Saving with interpolation
[
https://issues.apache.org/jira/browse/CONFIGURATION-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498503
]
Oliver Heger commented on CONFIGURATION-273:
Maybe we could implement this feature in a more generic way: The copy methods
in ConfigurationUtils could support an additional mode, in which interpolation
is automatically performed for affected properties, so that the resulting
configuration only contains properties with resolved variables.
Then you can use arbitrary destination configurations, including file-based
configurations, which can be saved later.
For hierarchical configurations this task is a bit more complicated (they are
not fully supported by the copy() methods of ConfigurationUtils), but it should
be possible, too.
Saving with interpolation
-
Key: CONFIGURATION-273
URL: https://issues.apache.org/jira/browse/CONFIGURATION-273
Project: Commons Configuration
Issue Type: New Feature
Affects Versions: 1.4
Reporter: Daniel Adrian
It will be very nice if you'll add the ability to save a configuration file
with the interpolation data.
so if my config file is :
my_home=127.0.0.1
my_place=Is ${my_home}
when I save the configuration (let's say with save(true)) it will look like
my_home=127.0.0.1
my_place=Is 127.0.0.1
Thank you!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONFIGURATION-274) PropertiesConfiguration.save() does not support escaping the escape character
PropertiesConfiguration.save() does not support escaping the escape character - Key: CONFIGURATION-274 URL: https://issues.apache.org/jira/browse/CONFIGURATION-274 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Oliver Heger Assigned To: Oliver Heger Priority: Minor Fix For: 1.5 When a new property is added to a PropertiesConfiguration, it is possible to escape the escaping character for list delimiters, e.g. conf.addProperty(test.dirs, C:\\Temp,D:\\Data\\); Here the Backslash after Temp must be escaped, otherwise the list delimiter won't be recognized. This works, but when the configuration is saved and loaded again, the backslash that escapes the escape character is dropped. The property is then treated as a single value property with an escaped list delimiter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-274) PropertiesConfiguration.save() does not support escaping the escape character
[ https://issues.apache.org/jira/browse/CONFIGURATION-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-274. Resolution: Fixed A fix has been committed. PropertiesConfiguration.save() does not support escaping the escape character - Key: CONFIGURATION-274 URL: https://issues.apache.org/jira/browse/CONFIGURATION-274 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Oliver Heger Assigned To: Oliver Heger Priority: Minor Fix For: 1.5 When a new property is added to a PropertiesConfiguration, it is possible to escape the escaping character for list delimiters, e.g. conf.addProperty(test.dirs, C:\\Temp,D:\\Data\\); Here the Backslash after Temp must be escaped, otherwise the list delimiter won't be recognized. This works, but when the configuration is saved and loaded again, the backslash that escapes the escape character is dropped. The property is then treated as a single value property with an escaped list delimiter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-269) PropertiesConfiguration.save() generates superfluous escaping character when delimiter parsing is disabled
[ https://issues.apache.org/jira/browse/CONFIGURATION-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497838 ] Oliver Heger commented on CONFIGURATION-269: Splitting is disabled, so the properties should not be splitted. The delimiter parsing disabled flag needs to be checked and, if it is set, the escaping of the list delimiter must be avoided. PropertiesConfiguration.save() generates superfluous escaping character when delimiter parsing is disabled -- Key: CONFIGURATION-269 URL: https://issues.apache.org/jira/browse/CONFIGURATION-269 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Oliver Heger Assigned To: Oliver Heger Fix For: 1.5 PropertiesConfiguration.save() ignores the delimiter parsing disabled flag and escapes all delimiter characters it encounters. When the configuration is loaded again (with delimiter parsing disabled) the values of affected properties contain the escaping character. This bug is very similar to CONFIGURATION-268, but for PropertiesConfiguration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-269) PropertiesConfiguration.save() generates superfluous escaping character when delimiter parsing is disabled
[ https://issues.apache.org/jira/browse/CONFIGURATION-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-269: --- Attachment: Config-269_test.diff The patch looks good. Here is a unit test demonstrating the problem. If you like, go on and apply it. PropertiesConfiguration.save() generates superfluous escaping character when delimiter parsing is disabled -- Key: CONFIGURATION-269 URL: https://issues.apache.org/jira/browse/CONFIGURATION-269 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Oliver Heger Assigned To: Oliver Heger Fix For: 1.5 Attachments: Config-269_test.diff, properties.patch PropertiesConfiguration.save() ignores the delimiter parsing disabled flag and escapes all delimiter characters it encounters. When the configuration is loaded again (with delimiter parsing disabled) the values of affected properties contain the escaping character. This bug is very similar to CONFIGURATION-268, but for PropertiesConfiguration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONFIGURATION-269) PropertiesConfiguration.save() generates superfluous escaping character when delimiter parsing is disabled
PropertiesConfiguration.save() generates superfluous escaping character when delimiter parsing is disabled -- Key: CONFIGURATION-269 URL: https://issues.apache.org/jira/browse/CONFIGURATION-269 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Oliver Heger Assigned To: Oliver Heger Fix For: 1.5 PropertiesConfiguration.save() ignores the delimiter parsing disabled flag and escapes all delimiter characters it encounters. When the configuration is loaded again (with delimiter parsing disabled) the values of affected properties contain the escaping character. This bug is very similar to CONFIGURATION-268, but for PropertiesConfiguration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-268) XMLConfiguration does not fully support disabled delimiter parsing
[ https://issues.apache.org/jira/browse/CONFIGURATION-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-268. Resolution: Fixed A fix was committed. There are also some more unit tests for the pathological cases with escaped and non escaped delimiter characters. XMLConfiguration does not fully support disabled delimiter parsing -- Key: CONFIGURATION-268 URL: https://issues.apache.org/jira/browse/CONFIGURATION-268 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Oliver Heger Assigned To: Oliver Heger Fix For: 1.5 A call to setDelimiterParsingDisabled(true) should completely turn off the mechanism for searching for list delimiters and splitting property values. However XMLConfiguration.save() escapes list delimiters even in this mode. When later such a configuration file is loaded and delimiter parsing is turned off, the values of affected properties will contain the escape character. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-268) XMLConfiguration does not fully support disabled delimiter parsing
[ https://issues.apache.org/jira/browse/CONFIGURATION-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494115 ] Oliver Heger commented on CONFIGURATION-268: Adding new elements would change the indices of list elements in an almost unpredictable way. This could be quite confusing if keys with indices were used. I think I will go for the solution with the special delimiter and add some notes to the Javadocs. I just found out that we do not support escaping the escape character itself (e.g. in dirs value=C:\Temp\,C:\Progs\ the backslash behind Temp would escape the list delimiter). Will try to fix this. XMLConfiguration does not fully support disabled delimiter parsing -- Key: CONFIGURATION-268 URL: https://issues.apache.org/jira/browse/CONFIGURATION-268 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Oliver Heger Assigned To: Oliver Heger Fix For: 1.5 A call to setDelimiterParsingDisabled(true) should completely turn off the mechanism for searching for list delimiters and splitting property values. However XMLConfiguration.save() escapes list delimiters even in this mode. When later such a configuration file is loaded and delimiter parsing is turned off, the values of affected properties will contain the escape character. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONFIGURATION-268) XMLConfiguration does not fully support disabled delimiter parsing
XMLConfiguration does not fully support disabled delimiter parsing -- Key: CONFIGURATION-268 URL: https://issues.apache.org/jira/browse/CONFIGURATION-268 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Oliver Heger Assigned To: Oliver Heger Fix For: 1.5 A call to setDelimiterParsingDisabled(true) should completely turn off the mechanism for searching for list delimiters and splitting property values. However XMLConfiguration.save() escapes list delimiters even in this mode. When later such a configuration file is loaded and delimiter parsing is turned off, the values of affected properties will contain the escape character. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-268) XMLConfiguration does not fully support disabled delimiter parsing
[ https://issues.apache.org/jira/browse/CONFIGURATION-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493945 ] Oliver Heger commented on CONFIGURATION-268: Attributes are also affected, but here the situation is more complicated: We support multiple values for a single attribute, so somebody could do something like this: XMLConfiguration conf = new XMLConfiguration(); conf.setDelimiterParsingDisabled(true); conf.addProperty([EMAIL PROTECTED], 1,2,3); conf.addProperty([EMAIL PROTECTED], 4,5,6); If such a configuration is saved, our current implementation will produce the following element: test attr=1\,2\,3,4\,5\,6/ If this element is loaded when delimiter parsing is disabled, an attribute with two values is created, but the values contain the escaping character. (Note that this is not a problem when delimiters are enabled.) I think if delimiter parsing is disabled, attribute values should be read as they are without doing any modifications like removing escape characters. They may be part of the real attribute value. But because XML does not allow multiple occurrences of a single attribute, we always need a delimiter character for representing multiple attribute values. Now when loading a configuration file and delimiter parsing is disabled, deciding whether a delimiter character is used is not trivial. What we could do is using an untypical delimiter character, e.g. the pipe. Then the example element would look like test attr=1,2,3|4,5,6/ If an attribute value contained this delimiter character, it would have to be escaped. But we still cannot be 100% sure whether the user in deed wants to define an attribute with the single value 1,2,3\|4,5,6. XMLConfiguration does not fully support disabled delimiter parsing -- Key: CONFIGURATION-268 URL: https://issues.apache.org/jira/browse/CONFIGURATION-268 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Oliver Heger Assigned To: Oliver Heger Fix For: 1.5 A call to setDelimiterParsingDisabled(true) should completely turn off the mechanism for searching for list delimiters and splitting property values. However XMLConfiguration.save() escapes list delimiters even in this mode. When later such a configuration file is loaded and delimiter parsing is turned off, the values of affected properties will contain the escape character. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-253) FileConfiguration getFile(), getFileName(), getBasePath() are not always consistent
[ https://issues.apache.org/jira/browse/CONFIGURATION-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491750 ] Oliver Heger commented on CONFIGURATION-253: The behavior since (I think) the 1.2 release is that a load() call sets the sourceURL if none has been set so far. This is required for supporting features like auto save and reloading strategies for configurations created this way (there is no hint in the docs that a source must be set explicitly for using these features, so I assume this is alright). What my fix does is to always keep the getFile() method in sync with the sourceURL; so if a sourceURL exists, getFile() will now return a corresponding File object. Note that the URL is only modified on an initial load() call, i.e. if already a source was set, it won't be changed by a following load() call. This is intended. It allows for instance the easy creation of combined configurations: you can call load() as often as you like on a file-based configuration; the properties of the single sources will be accumulated. Then you can save the accumulated properties to the original source. FileConfiguration getFile(), getFileName(), getBasePath() are not always consistent --- Key: CONFIGURATION-253 URL: https://issues.apache.org/jira/browse/CONFIGURATION-253 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Reporter: Thomas Wabner Fix For: 1.5 Taken from the maillinglist: I have a properties configuration which is loaded without a problem. Later in my application I will access the file which is aligned to this configuration. final IFileConfiguration _productConf = _conf.getProductConfigurations().get(_productId); log.debug(product conf file + _productConf.getFile()); log.debug(product conf filename + _productConf.getFileName()); log.debug(product conf base path + _productConf.getBasePath()); The methods _productConf.getFile() and _productConf.getFileName() returning null but the getBasePath() returns a path which is correct (like file:/C:/Projects/workspace/myProject/project.properties). Seems for me like a bug because the PropertiesConfiguration is loaded correct and works. By side: I have also set a file reloading strategy for this configuration. Any ideas what's happen in this case or where I can find the problem? It would be nicer to get the File() instead the BasePath which has to be converted into a URL before I can access the whole properties file. Thanks in advance, - Thomas Wabner Thomas, you are right, the conversions between a base path, a file name, and a File are not always consistent. How did you load the configuration (this determines, which internal fields are set)? I would recommend to work with URLs, i.e. the method getURL(). A file-based configuration's URL is always defined. If you like, you can open a Jira ticket for this problem. Thanks. Oliver The file is loaded in this way: _productConf = new ProductConfiguration(); _productConf.load(FileTools.getPathForList(_propductPathList).getPath()); means the load method gets an String and not an File. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-253) FileConfiguration getFile(), getFileName(), getBasePath() are not always consistent
[ https://issues.apache.org/jira/browse/CONFIGURATION-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491759 ] Oliver Heger commented on CONFIGURATION-253: I applied the fix as described in my last comment. Thomas, can you please check if this works for you? Thanks. FileConfiguration getFile(), getFileName(), getBasePath() are not always consistent --- Key: CONFIGURATION-253 URL: https://issues.apache.org/jira/browse/CONFIGURATION-253 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Reporter: Thomas Wabner Assigned To: Oliver Heger Fix For: 1.5 Taken from the maillinglist: I have a properties configuration which is loaded without a problem. Later in my application I will access the file which is aligned to this configuration. final IFileConfiguration _productConf = _conf.getProductConfigurations().get(_productId); log.debug(product conf file + _productConf.getFile()); log.debug(product conf filename + _productConf.getFileName()); log.debug(product conf base path + _productConf.getBasePath()); The methods _productConf.getFile() and _productConf.getFileName() returning null but the getBasePath() returns a path which is correct (like file:/C:/Projects/workspace/myProject/project.properties). Seems for me like a bug because the PropertiesConfiguration is loaded correct and works. By side: I have also set a file reloading strategy for this configuration. Any ideas what's happen in this case or where I can find the problem? It would be nicer to get the File() instead the BasePath which has to be converted into a URL before I can access the whole properties file. Thanks in advance, - Thomas Wabner Thomas, you are right, the conversions between a base path, a file name, and a File are not always consistent. How did you load the configuration (this determines, which internal fields are set)? I would recommend to work with URLs, i.e. the method getURL(). A file-based configuration's URL is always defined. If you like, you can open a Jira ticket for this problem. Thanks. Oliver The file is loaded in this way: _productConf = new ProductConfiguration(); _productConf.load(FileTools.getPathForList(_propductPathList).getPath()); means the load method gets an String and not an File. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-253) FileConfiguration getFile(), getFileName(), getBasePath() are not always consistent
[ https://issues.apache.org/jira/browse/CONFIGURATION-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491438 ] Oliver Heger commented on CONFIGURATION-253: After having a deeper look into this issue I am no longer sure that this is a bug. You loaded the configuration with the load(String) method, and the Javadocs for this method state This does not change the source of the configuration (i.e. the internally maintained file name). Use one of the setter methods for this purpose. However I tend to agree that the current behavior is confusing. Why can you obtain a URL and a path name from a configuration loaded this way, but no File? I have written a test case and implemented a (simple) fix, which would cause getFile() to return a valid file name in this case. What do others think? Should we change the current behavior? FileConfiguration getFile(), getFileName(), getBasePath() are not always consistent --- Key: CONFIGURATION-253 URL: https://issues.apache.org/jira/browse/CONFIGURATION-253 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Reporter: Thomas Wabner Fix For: 1.5 Taken from the maillinglist: I have a properties configuration which is loaded without a problem. Later in my application I will access the file which is aligned to this configuration. final IFileConfiguration _productConf = _conf.getProductConfigurations().get(_productId); log.debug(product conf file + _productConf.getFile()); log.debug(product conf filename + _productConf.getFileName()); log.debug(product conf base path + _productConf.getBasePath()); The methods _productConf.getFile() and _productConf.getFileName() returning null but the getBasePath() returns a path which is correct (like file:/C:/Projects/workspace/myProject/project.properties). Seems for me like a bug because the PropertiesConfiguration is loaded correct and works. By side: I have also set a file reloading strategy for this configuration. Any ideas what's happen in this case or where I can find the problem? It would be nicer to get the File() instead the BasePath which has to be converted into a URL before I can access the whole properties file. Thanks in advance, - Thomas Wabner Thomas, you are right, the conversions between a base path, a file name, and a File are not always consistent. How did you load the configuration (this determines, which internal fields are set)? I would recommend to work with URLs, i.e. the method getURL(). A file-based configuration's URL is always defined. If you like, you can open a Jira ticket for this problem. Thanks. Oliver The file is loaded in this way: _productConf = new ProductConfiguration(); _productConf.load(FileTools.getPathForList(_propductPathList).getPath()); means the load method gets an String and not an File. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-265) XMLConfiguration with setAutoSave(true) doesn't save if SubnodeConfiguration is changed
[ https://issues.apache.org/jira/browse/CONFIGURATION-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-265. Resolution: Fixed A fix was applied for triggering the auto-save mechanism for changes at a subnode configuration. There is now also the new event type EVENT_SUBNODE_CHANGED that is fired in such a case. XMLConfiguration with setAutoSave(true) doesn't save if SubnodeConfiguration is changed --- Key: CONFIGURATION-265 URL: https://issues.apache.org/jira/browse/CONFIGURATION-265 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Irina Fridkina Assigned To: Oliver Heger Fix For: 1.5 config.xml file conf parent-item sub-itemold_value/sub-item /parent-item /conf The problem can be reproduced as follows: 1 XMLConfiguration config = new XMLConfiguration(c:\\conf.xml); 2 config.setAutoSave(true) ; 3 SubnodeConfiguration parentItemConfig = config.configurationAt(parent-item); 4 parentItemConfig.setProperty(sub-item,new_value); 5. System.out.println(config.getString(parent-item.sub-item); // will print new_value // if you look at the config.xml sub-item still has old_value // also if you try to do 5 XMLConfiguration config2 = new XMLConfiguration(c:\\conf.xml); 6. System.out.println(config2.getString(parent-item.sub-item); // will print old_value -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-264) SubnodeConfiguration does not see reloads of its parent configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-264. Resolution: Fixed A fix was applied that implements the changes outlined before. HierarchicalConfiguration's configurationAt() method now supports an additional boolean parameter. If this parameter is set to true, reloads of the parent configuration will be detected. SubnodeConfiguration does not see reloads of its parent configuration - Key: CONFIGURATION-264 URL: https://issues.apache.org/jira/browse/CONFIGURATION-264 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Oliver Heger Assigned To: Oliver Heger Fix For: 1.5 The problem can be reproduced as follows: 1 config = new XMLConfiguration(c:\\conf.xml); 2 config.setReloadingStrategy(new FileChangedReloadingStrategy()); 3 SubnodeConfiguration parentItemConfig = config.configurationAt(parent-item); 4 String ss2 = parentItemConfig.getString(sub-item); 5 //Now, sub-item node value changes to new_value 6 ss2 = parentItemConfig.getString(sub-item); // still returns old_value -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-266) Improving backward compatibility in ConfigurationInterpolator
[ https://issues.apache.org/jira/browse/CONFIGURATION-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-266. Resolution: Fixed The patch was applied. Many thanks! Improving backward compatibility in ConfigurationInterpolator - Key: CONFIGURATION-266 URL: https://issues.apache.org/jira/browse/CONFIGURATION-266 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.4 Reporter: Tobias Noebel Assigned To: Oliver Heger Fix For: 1.5 Attachments: ConfigurationInterpolator.diff, ConfigurationInterpolator.java When using variables with prefixes in previous versions of commons configuration one could use the default lookup to assign the variable values, as prefixes were not recognized and handled differently. Since 1.4 that behaviour is broken as the default lookup is not taken into account for variables containing prefixes. Applications which make use of such variables would have to be changed. My request is to use the default lookup as fallback if a variable with prefix is not found in the local lookups. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-3) Drop 1st class dependency on commons-logging
[ https://issues.apache.org/jira/browse/CONFIGURATION-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490646 ] Oliver Heger commented on CONFIGURATION-3: -- Should a generic library like Commons Configuration really depend on a specific logging library? I think log4j is still in wide use, and if an application that uses this library wanted to include a dependency to Configuration, there would be two logging implementations to be handled. But my knowledge about logging implementations is a bit outdated. This may not be a problem these days any more. Drop 1st class dependency on commons-logging Key: CONFIGURATION-3 URL: https://issues.apache.org/jira/browse/CONFIGURATION-3 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.2 Reporter: Joerg Schaible Priority: Minor Fix For: 2.0 Currently commons-logging is reported as first class dependency in the project reports. This is not true. The only classes that make direct usage of JCL are ConfigurationDynaBean/Class and this only for tracing. It would be nice to eliminate this reference at all and list JCL only as transitive dependency of digester and beanutils. We might support logging with the monitor/listener concept of http://issues.apache.org/bugzilla/show_bug.cgi?id=38929 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-265) XMLConfiguration with setAutoSave(true) doesn't save if SubnodeConfiguration is changed
[ https://issues.apache.org/jira/browse/CONFIGURATION-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490649 ] Oliver Heger commented on CONFIGURATION-265: This is indeed a bug, updates in the subnode configuration do not trigger the parent's auto-save mechanism. To be consequent, these updates should then also generate change events for the parent configuration. However this will be problematic because we cannot simply transform the configuration key used by the subnode configuration into the namespace of the parent (the expression engines do not provide this functionality at the moment). So the only chance I see is to introduce a new event type EVENT_SUBNODE_CHANGED. The properties of this event type can contain all available information about the change. In the next major release we can extend the interface for the expression engines to work around this limitation. XMLConfiguration with setAutoSave(true) doesn't save if SubnodeConfiguration is changed --- Key: CONFIGURATION-265 URL: https://issues.apache.org/jira/browse/CONFIGURATION-265 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Irina Fridkina Fix For: 1.5 config.xml file conf parent-item sub-itemold_value/sub-item /parent-item /conf The problem can be reproduced as follows: 1 XMLConfiguration config = new XMLConfiguration(c:\\conf.xml); 2 config.setAutoSave(true) ; 3 SubnodeConfiguration parentItemConfig = config.configurationAt(parent-item); 4 parentItemConfig.setProperty(sub-item,new_value); 5. System.out.println(config.getString(parent-item.sub-item); // will print new_value // if you look at the config.xml sub-item still has old_value // also if you try to do 5 XMLConfiguration config2 = new XMLConfiguration(c:\\conf.xml); 6. System.out.println(config2.getString(parent-item.sub-item); // will print old_value -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-264) SubnodeConfiguration does not see reloads of its parent configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489707 ] Oliver Heger commented on CONFIGURATION-264: To make a SubnodeConfiguration compatible with reloads of its parent configuration two things need to be changed: - An access of the subnode configuration needs to trigger the parent configuration, so that it can check if a reload is required. - When the parent configuration is reloaded, its set of nodes is completely replaced. So the subnode configuration has to be reconstructed. To achieve this, it is necessary to store in the subnode configuration the expression that was used to construct it. Then, when the subnode configuration's root node is queried (which happens for every property access), the parent can be asked to re-evaluate the expression and return the new root node. This will also trigger a reload of the parent if necessary. This solution has the following drawbacks: - It impacts the performance of SubnodeConfiguration because for each property access an additional query has to be performed on the parent. - If the expression engine is changed on the parent configuration, we are lost. - Some updates of the parent configuration may cause unexpected results. As an example consider that the parent configuration contains a list of properties and the subnode configuration points to a single element of this list. If now a list element before this element is removed, the subnode configuration will point to a different list element when it is reconstructed. This is because the expression the subnode configuration is based on cannot be updated according to changes on the parent's properties. - The parent configuration could be changed in a way that the subnode configuration becomes invalid (e.g. if the root node of the subnode configuration is removed). Because of these drawbacks I would like to make this solution optional: I would add a new configurationAt() method to HierarchicalConfiguration that takes an additional boolean argument. If this flag is set to true, the subnode configuration will do the described checks and thus will be aware of reloads of its parent. Otherwise (which is the default) the subnode configuration will behave as it does now (and miss the reloads). SubnodeConfiguration does not see reloads of its parent configuration - Key: CONFIGURATION-264 URL: https://issues.apache.org/jira/browse/CONFIGURATION-264 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Oliver Heger Assigned To: Oliver Heger Fix For: 1.5 The problem can be reproduced as follows: 1 config = new XMLConfiguration(c:\\conf.xml); 2 config.setReloadingStrategy(new FileChangedReloadingStrategy()); 3 SubnodeConfiguration parentItemConfig = config.configurationAt(parent-item); 4 String ss2 = parentItemConfig.getString(sub-item); 5 //Now, sub-item node value changes to new_value 6 ss2 = parentItemConfig.getString(sub-item); // still returns old_value -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-263) XMLConfiguration drops attributes if a property value is a list
[
https://issues.apache.org/jira/browse/CONFIGURATION-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-263.
Resolution: Fixed
A fix was committed. In the problematic scenarios the attributes are now always
added to the first list node. So if there is a XML file like that:
...
list
a name=xtest1,test2/a
a name=y,z attr=u1,2,3/a
/list
the results are as following:
list
a name=xtest1/a
atest2/a
a name=y,z attr=u1/a
a2/a
a3/a
/list
XMLConfiguration drops attributes if a property value is a list
---
Key: CONFIGURATION-263
URL: https://issues.apache.org/jira/browse/CONFIGURATION-263
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.4
Reporter: Oliver Heger
Assigned To: Oliver Heger
Fix For: 1.5
When the following test is run with the following xml the second assertEquals
statement fails:
XML:
?xml version=1.0 encoding=ISO-8859-1 ?
test
a name=XABC/a
a name=Y1,2,3/a
/test
TEST:
public void testXMLConfig() throws Exception {
File file = new File(/xml/xmlConfigTest.xml);
XMLConfiguration xmlConfig = new XMLConfiguration(file);
xmlConfig.load();
assertEquals(X,xmlConfig.getProperty(a(0)[EMAIL PROTECTED]));
assertEquals(Y,xmlConfig.getProperty(a(1)[EMAIL PROTECTED]));
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONFIGURATION-263) XMLConfiguration drops attributes if a property value is a list
XMLConfiguration drops attributes if a property value is a list
---
Key: CONFIGURATION-263
URL: https://issues.apache.org/jira/browse/CONFIGURATION-263
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.4
Reporter: Oliver Heger
Fix For: 1.5
When the following test is run with the following xml the second assertEquals
statement fails:
XML:
?xml version=1.0 encoding=ISO-8859-1 ?
test
a name=XABC/a
a name=Y1,2,3/a
/test
TEST:
public void testXMLConfig() throws Exception {
File file = new File(/xml/xmlConfigTest.xml);
XMLConfiguration xmlConfig = new XMLConfiguration(file);
xmlConfig.load();
assertEquals(X,xmlConfig.getProperty(a(0)[EMAIL PROTECTED]));
assertEquals(Y,xmlConfig.getProperty(a(1)[EMAIL PROTECTED]));
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONFIGURATION-264) SubnodeConfiguration does not see reloads of its parent configuration
SubnodeConfiguration does not see reloads of its parent configuration - Key: CONFIGURATION-264 URL: https://issues.apache.org/jira/browse/CONFIGURATION-264 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.4 Reporter: Oliver Heger Fix For: 1.5 The problem can be reproduced as follows: 1 config = new XMLConfiguration(c:\\conf.xml); 2 config.setReloadingStrategy(new FileChangedReloadingStrategy()); 3 SubnodeConfiguration parentItemConfig = config.configurationAt(parent-item); 4 String ss2 = parentItemConfig.getString(sub-item); 5 //Now, sub-item node value changes to new_value 6 ss2 = parentItemConfig.getString(sub-item); // still returns old_value -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-259) ConfigurationFactory Merge is broken
[ https://issues.apache.org/jira/browse/CONFIGURATION-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-259. Resolution: Fixed Fix Version/s: 1.4 Some hints were added to the JavaDocs of ConfigurationFactory and the user guide that recommend the usage of DefaultConfigurationBuilder instead. Maybe in the 1.5 release ConfigurationFactory can be deprecated and then removed with the next major release (2.0). ConfigurationFactory Merge is broken Key: CONFIGURATION-259 URL: https://issues.apache.org/jira/browse/CONFIGURATION-259 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Environment: Windows XP running Eclipse, JDK 1.4.2 Reporter: Karl Banke Fix For: 1.4 Attachments: personendetails.xml, personensuche.xml, testconfig.xml, TestConfiguration.java I am trying to merge two Configuration using the ConfigurationFactory and the additional tag. It turns out that subsequent operations on the merged data provide wrong results. In particular, after creating a particular subset from a loaded configuration, the subset is empty. Strangely enough, when using DefaultConfigurationBuilder to load exactly the same configurations this works properly. So when initializing the configuration as follows, I get the following error: URL configURL = getClass().getResource(configFile); ConfigurationFactory factory = new ConfigurationFactory(); factory.setConfigurationURL(configURL); myConfig = factory.getConfiguration(); 60043 java.util.NoSuchElementException: 'HvNr' doesn't map to an existing object at org.apache.commons.configuration.AbstractConfiguration.getLong(AbstractConfiguration.java:743) at de.awd.vertriebsportal.portal.person.TestConfiguration.main(TestConfiguration.java:84) Exception in thread main But when initializing it like this everything works properly DefaultConfigurationBuilder builder = new DefaultConfigurationBuilder(); builder.setURL(configURL); myConfig = builder.getConfiguration(); 60043 54564 I will attach full source code and xml files -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-259) ConfigurationFactory Merge is broken
[ https://issues.apache.org/jira/browse/CONFIGURATION-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484840 ] Oliver Heger commented on CONFIGURATION-259: You are right that the merging facilities provided by ConfigurationFactory are not as sophisticated as the ones supported by the newer DefaultConfigurationBuilder class. Because DefaultConfigurationBuilder is intended as a replacement for ConfigurationFactory my motivation for changing this is somewhat limited. (If somebody provided a patch, I would be happy to apply it of course.) So would it be sufficient to add some notes to the documentation of ConfigurationFactory (in the JavaDocs and in the user guide) that describe these weakness and refer to DefaultConfigurationBuilder? ConfigurationFactory Merge is broken Key: CONFIGURATION-259 URL: https://issues.apache.org/jira/browse/CONFIGURATION-259 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Environment: Windows XP running Eclipse, JDK 1.4.2 Reporter: Karl Banke Attachments: personendetails.xml, personensuche.xml, testconfig.xml, TestConfiguration.java I am trying to merge two Configuration using the ConfigurationFactory and the additional tag. It turns out that subsequent operations on the merged data provide wrong results. In particular, after creating a particular subset from a loaded configuration, the subset is empty. Strangely enough, when using DefaultConfigurationBuilder to load exactly the same configurations this works properly. So when initializing the configuration as follows, I get the following error: URL configURL = getClass().getResource(configFile); ConfigurationFactory factory = new ConfigurationFactory(); factory.setConfigurationURL(configURL); myConfig = factory.getConfiguration(); 60043 java.util.NoSuchElementException: 'HvNr' doesn't map to an existing object at org.apache.commons.configuration.AbstractConfiguration.getLong(AbstractConfiguration.java:743) at de.awd.vertriebsportal.portal.person.TestConfiguration.main(TestConfiguration.java:84) Exception in thread main But when initializing it like this everything works properly DefaultConfigurationBuilder builder = new DefaultConfigurationBuilder(); builder.setURL(configURL); myConfig = builder.getConfiguration(); 60043 54564 I will attach full source code and xml files -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-259) ConfigurationFactory Merge is broken
[ https://issues.apache.org/jira/browse/CONFIGURATION-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484898 ] Oliver Heger commented on CONFIGURATION-259: Is it possible that your data structures contain some ambiguity, so that the merge algorithm cannot decide, which nodes are list nodes? The following section of the user guide discusses this topic: http://jakarta.apache.org/commons/configuration/howto_combinedconfiguration.html#Node_combiners If this is the case, you can explicitly mark the affected nodes as list nodes (this is explained in the section about DefaultConfigurationBuilder). ConfigurationFactory Merge is broken Key: CONFIGURATION-259 URL: https://issues.apache.org/jira/browse/CONFIGURATION-259 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Environment: Windows XP running Eclipse, JDK 1.4.2 Reporter: Karl Banke Attachments: personendetails.xml, personensuche.xml, testconfig.xml, TestConfiguration.java I am trying to merge two Configuration using the ConfigurationFactory and the additional tag. It turns out that subsequent operations on the merged data provide wrong results. In particular, after creating a particular subset from a loaded configuration, the subset is empty. Strangely enough, when using DefaultConfigurationBuilder to load exactly the same configurations this works properly. So when initializing the configuration as follows, I get the following error: URL configURL = getClass().getResource(configFile); ConfigurationFactory factory = new ConfigurationFactory(); factory.setConfigurationURL(configURL); myConfig = factory.getConfiguration(); 60043 java.util.NoSuchElementException: 'HvNr' doesn't map to an existing object at org.apache.commons.configuration.AbstractConfiguration.getLong(AbstractConfiguration.java:743) at de.awd.vertriebsportal.portal.person.TestConfiguration.main(TestConfiguration.java:84) Exception in thread main But when initializing it like this everything works properly DefaultConfigurationBuilder builder = new DefaultConfigurationBuilder(); builder.setURL(configURL); myConfig = builder.getConfiguration(); 60043 54564 I will attach full source code and xml files -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-211) [configuration] CommandLineConfiguration
[ https://issues.apache.org/jira/browse/CONFIGURATION-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-211: --- Attachment: CLI-CommandLineConfiguration.java CommandLineConfiguration from the CLI project (commons-configuration integration branch). [configuration] CommandLineConfiguration Key: CONFIGURATION-211 URL: https://issues.apache.org/jira/browse/CONFIGURATION-211 Project: Commons Configuration Issue Type: Improvement Affects Versions: Nightly Builds Environment: Operating System: All Platform: All Reporter: Emmanuel Bourg Priority: Minor Fix For: 1.5 Attachments: CLI-CommandLineConfiguration.java, CommandLineConfiguration.java, TestCommandLineConfiguration.java I implemented a simple configuration taking the properties from the command line. I don't know if it is worth adding in the main code base, but I'm submitting it here if ever someone find it useful. Comments are welcome :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-115) FileUtilsCleanDirectoryTestCase fails on Windoes if command chmod is available
[ https://issues.apache.org/jira/browse/IO-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481869 ] Oliver Heger commented on IO-115: - The problem seems to be fixed in revision 518770 (http://svn.apache.org/viewvc?view=revrevision=518770). Here the os.name system property is checked to avoid that the affected tests get executed under windows. Don't know if this is the most elegant solution, but it works! FileUtilsCleanDirectoryTestCase fails on Windoes if command chmod is available -- Key: IO-115 URL: https://issues.apache.org/jira/browse/IO-115 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.3.1 Reporter: Joerg Schaible Fix For: 1.4 Some tests in FileUtilsCleanDirectoryTestCase try to delete files that have been set to read-only. This is expected to throw an exception. To set the read-only flag the method chmod() tries to execute the unix chmod command. If this fails (which should normally be the case on windows), the test is ignored. If Posix tools are available e.g. from Cygwin, MKS Toolkit, Microsoft's Posix Tools or similar ones the test fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-258) JSON configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger updated CONFIGURATION-258:
---
Priority: Minor (was: Major)
Affects Version/s: 1.3
Patches are welcome.
JSON configuration
--
Key: CONFIGURATION-258
URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
Project: Commons Configuration
Issue Type: Improvement
Affects Versions: 1.3
Environment:
« Hide
Operating System: All
Platform: All
Reporter: Antonio López-Cerón Vivo
Priority: Minor
Fix For: 1.5
JSON is a lightweight data-interchange format
{menu: {
id: file,
value: File,
popup: {
menuitem: [
{value: New, onclick: CreateNewDoc()},
{value: Open, onclick: OpenDoc()},
{value: Close, onclick: CloseDoc()}
]
}
}}
All references can be located at
http://www.json.org/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-257) XMLConfiguration with Schema
[ https://issues.apache.org/jira/browse/CONFIGURATION-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-257: --- Fix Version/s: 1.5 Affects Version/s: 1.3 Extended support for schema validation seems to be available in Java since the 1.5 release. However ATM our minimum required JDK is still 1.3. Do you know whether it is possible to perform schema validation in this version in a portable way? Otherwise this feature will have to wait until we drop the JDK 1.3 compatibility and move on to 1.5. XMLConfiguration with Schema Key: CONFIGURATION-257 URL: https://issues.apache.org/jira/browse/CONFIGURATION-257 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.3 Environment: no special issues Reporter: Andre Pietsch Priority: Minor Fix For: 1.5 It would be nice if you can set a self defined schema or better a schema file to validate a XML-file that has no schema defined in its source. I would be happy with something like XMLConfiguratiom.setSchema(java.io.File schemaFile) or XMLConfiguration.setSchema(javax.xml.validation.Schema schema) that is forwarded to the XML-parser used by XMLConfiguration. Thanks alot... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-256) MapConfiguration does not decode escaped Delimiters
[
https://issues.apache.org/jira/browse/CONFIGURATION-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-256.
Resolution: Fixed
Fix Version/s: 1.4
MapConfiguration and all the web-based configurations were updated to correctly
remove the escaping character for the list delimiter. Additional tests were
added to verify this behavior.
Please double-check. Thanks.
MapConfiguration does not decode escaped Delimiters
---
Key: CONFIGURATION-256
URL: https://issues.apache.org/jira/browse/CONFIGURATION-256
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.3
Environment: I think it does not matter because of pure java
Reporter: Michal Polak
Assigned To: Oliver Heger
Fix For: 1.4
Hello, I don't know how to reopen resolved bug. See:
https://issues.apache.org/jira/browse/CONFIGURATION-30
There is BAD implementation in MapConfiguration.getProperty(String key)
method:
As return value should be list.get(0) instead of value.
PropertyConverter.split removes escape chars
Suggested correction:
public Object getProperty(String key)
{
Object value = map.get(key);
if ((value instanceof String) (!isDelimiterParsingDisabled()))
{
List list = PropertyConverter.split((String) value,
getListDelimiter());
//MP: return list.size() 1 ? list : value;
return list.size() 1 ? list : list.get(0); //MP: split removes
escape chars
}
else
{
return value;
}
}
Test code:
Map m = new HashMap();
m.put(foo, bar\\,baz);
m.put(bar, bar, baz);
MapConfiguration mc = new MapConfiguration(m);
mc.setDelimiterParsingDisabled(false);
mc.setListDelimiter(',');
Configuration c = mc;
String bad = c.getString(foo); //-- returns bar\\, baz expected bar,
baz
String ok = c.getString(bar); // -- returns bar
System.err.println(Bad: + bad);
System.err.println(OK: + ok);
Current result is:
Bad: bar\,baz
OK: bar
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-255) DatabaseConfiguration doesn't support List properties (again)
[ https://issues.apache.org/jira/browse/CONFIGURATION-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-255. Resolution: Fixed The problem should be fixed now. I made two changes: - getProperty() now checks for list delimiters in the values obtained from the database. - addProperty() temporarily disables delimiter parsing, so that only a single INSERT is performed for a string property whose value contains the delimiter character. Tests for this behavior have also been added. Please double-check. Thanks. DatabaseConfiguration doesn't support List properties (again) - Key: CONFIGURATION-255 URL: https://issues.apache.org/jira/browse/CONFIGURATION-255 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Environment: Sun Java(TM) System Application Server Platform Edition 9.0, Oracle 9i Reporter: Thibaut Martin Assigned To: Oliver Heger Priority: Minor Fix For: 1.4 The getList() and getStringArray() methods always return a one element list/array, when used with DatabaseConfiguration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-255) DatabaseConfiguration doesn't support list delimiters in property values
[ https://issues.apache.org/jira/browse/CONFIGURATION-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-255: --- Description: The getList() and getStringArray() methods always return a one element list/array, when used with DatabaseConfiguration, even if the value of the queried property contains the list delimiter character. (was: The getList() and getStringArray() methods always return a one element list/array, when used with DatabaseConfiguration.) Summary: DatabaseConfiguration doesn't support list delimiters in property values (was: DatabaseConfiguration doesn't support List properties (again)) Updated summary and description to better explain the problem. DatabaseConfiguration doesn't support list delimiters in property values Key: CONFIGURATION-255 URL: https://issues.apache.org/jira/browse/CONFIGURATION-255 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Environment: Sun Java(TM) System Application Server Platform Edition 9.0, Oracle 9i Reporter: Thibaut Martin Assigned To: Oliver Heger Priority: Minor Fix For: 1.4 The getList() and getStringArray() methods always return a one element list/array, when used with DatabaseConfiguration, even if the value of the queried property contains the list delimiter character. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-255) DatabaseConfiguration doesn't support List properties (again)
[ https://issues.apache.org/jira/browse/CONFIGURATION-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-255: --- Fix Version/s: 1.4 Assignee: Oliver Heger Okay, I see the problem now. Will have a look. DatabaseConfiguration doesn't support List properties (again) - Key: CONFIGURATION-255 URL: https://issues.apache.org/jira/browse/CONFIGURATION-255 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Environment: Sun Java(TM) System Application Server Platform Edition 9.0, Oracle 9i Reporter: Thibaut Martin Assigned To: Oliver Heger Priority: Minor Fix For: 1.4 The getList() and getStringArray() methods always return a one element list/array, when used with DatabaseConfiguration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-254) Wrong creation of XMLFileConfigurationDelegate in XMLConfiguration.clone()
[
https://issues.apache.org/jira/browse/CONFIGURATION-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger updated CONFIGURATION-254:
---
Fix Version/s: 1.4
Wrong creation of XMLFileConfigurationDelegate in XMLConfiguration.clone()
--
Key: CONFIGURATION-254
URL: https://issues.apache.org/jira/browse/CONFIGURATION-254
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.3
Environment: Java 1.4.2, Windows XP, Shale
Reporter: Carsten Kaiser
Assigned To: Oliver Heger
Fix For: 1.4
The clone() operation on a XMLConfiguration does not work correctly due to
the following problem:
private class XMLFileConfigurationDelegate extends FileConfigurationDelegate
{
public void load(InputStream in) throws ConfigurationException
{
XMLConfiguration.this.load(in);
}
}
Obviously the delegate references the XMLConfiguration instance it is created
in. Thus when calling
public Object clone()
{
XMLConfiguration copy = (XMLConfiguration) super.clone();
// clear document related properties
copy.document = null;
copy.setDelegate(createDelegate());
// clear all references in the nodes, too
copy.getRoot().visit(new NodeVisitor()
{
public void visitBeforeChildren(Node node, ConfigurationKey key)
{
node.setReference(null);
}
}, null);
return copy;
}
the delegate still references the original XMLConfiguration, thus will save
the content of the original one
to file instead of the clone as expected! Changing the code like this
copy.setDelegate(copy.createDelegate());
solves the problem! Now the cloned XMLConfiguration with all its applied
changes can be saved!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-255) DatabaseConfiguration doesn't support List properties (again)
[ https://issues.apache.org/jira/browse/CONFIGURATION-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477088 ] Oliver Heger commented on CONFIGURATION-255: Do you have a concrete example where the getList() method is failing? There is a unit test case that fetches a list, and this test is obviously working. DatabaseConfiguration doesn't support List properties (again) - Key: CONFIGURATION-255 URL: https://issues.apache.org/jira/browse/CONFIGURATION-255 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Environment: Sun Java(TM) System Application Server Platform Edition 9.0, Oracle 9i Reporter: Thibaut Martin Priority: Minor The getList() and getStringArray() methods always return a one element list/array, when used with DatabaseConfiguration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-254) Wrong creation of XMLFileConfigurationDelegate in XMLConfiguration.clone()
[
https://issues.apache.org/jira/browse/CONFIGURATION-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-254.
Resolution: Fixed
The suggested fix was committed. Many thanks.
Wrong creation of XMLFileConfigurationDelegate in XMLConfiguration.clone()
--
Key: CONFIGURATION-254
URL: https://issues.apache.org/jira/browse/CONFIGURATION-254
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.3
Environment: Java 1.4.2, Windows XP, Shale
Reporter: Carsten Kaiser
Assigned To: Oliver Heger
Fix For: 1.4
The clone() operation on a XMLConfiguration does not work correctly due to
the following problem:
private class XMLFileConfigurationDelegate extends FileConfigurationDelegate
{
public void load(InputStream in) throws ConfigurationException
{
XMLConfiguration.this.load(in);
}
}
Obviously the delegate references the XMLConfiguration instance it is created
in. Thus when calling
public Object clone()
{
XMLConfiguration copy = (XMLConfiguration) super.clone();
// clear document related properties
copy.document = null;
copy.setDelegate(createDelegate());
// clear all references in the nodes, too
copy.getRoot().visit(new NodeVisitor()
{
public void visitBeforeChildren(Node node, ConfigurationKey key)
{
node.setReference(null);
}
}, null);
return copy;
}
the delegate still references the original XMLConfiguration, thus will save
the content of the original one
to file instead of the clone as expected! Changing the code like this
copy.setDelegate(copy.createDelegate());
solves the problem! Now the cloned XMLConfiguration with all its applied
changes can be saved!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-253) FileConfiguration getFile(), getFileName(), getBasePath() are not always consistent
[ https://issues.apache.org/jira/browse/CONFIGURATION-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-253: --- Affects Version/s: 1.5 We are just in the process of getting out the 1.4 release. I am reluctant to change the behavior of the getFile() and getFileName() methods now because this may cause a surprise for existing code. So this issue will be addressed in the following release. FileConfiguration getFile(), getFileName(), getBasePath() are not always consistent --- Key: CONFIGURATION-253 URL: https://issues.apache.org/jira/browse/CONFIGURATION-253 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.5 Reporter: Thomas Wabner Taken from the maillinglist: I have a properties configuration which is loaded without a problem. Later in my application I will access the file which is aligned to this configuration. final IFileConfiguration _productConf = _conf.getProductConfigurations().get(_productId); log.debug(product conf file + _productConf.getFile()); log.debug(product conf filename + _productConf.getFileName()); log.debug(product conf base path + _productConf.getBasePath()); The methods _productConf.getFile() and _productConf.getFileName() returning null but the getBasePath() returns a path which is correct (like file:/C:/Projects/workspace/myProject/project.properties). Seems for me like a bug because the PropertiesConfiguration is loaded correct and works. By side: I have also set a file reloading strategy for this configuration. Any ideas what's happen in this case or where I can find the problem? It would be nicer to get the File() instead the BasePath which has to be converted into a URL before I can access the whole properties file. Thanks in advance, - Thomas Wabner Thomas, you are right, the conversions between a base path, a file name, and a File are not always consistent. How did you load the configuration (this determines, which internal fields are set)? I would recommend to work with URLs, i.e. the method getURL(). A file-based configuration's URL is always defined. If you like, you can open a Jira ticket for this problem. Thanks. Oliver The file is loaded in this way: _productConf = new ProductConfiguration(); _productConf.load(FileTools.getPathForList(_propductPathList).getPath()); means the load method gets an String and not an File. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-238) XMLConfiguration.save() - illegal new line char in xml comment
[ https://issues.apache.org/jira/browse/CONFIGURATION-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-238. Resolution: Won't Fix Fix Version/s: 1.4 Got no more feedback on this issue, so closing it. IMO there is nothing we can do about this because the underlying XML parser or the XSLT engine are handling this. XMLConfiguration.save() - illegal new line char in xml comment -- Key: CONFIGURATION-238 URL: https://issues.apache.org/jira/browse/CONFIGURATION-238 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Environment: Windows XP x64 Reporter: Janusz Studzizba Fix For: 1.4 I have the following conf.xml. ?xml version=1.0 encoding=UTF-8? report-server-config !-- comment new line in comment -- paramvalue/param /report-server-config Edited with Vim looks nice. I use XMLConfiguration to process it. I perform the following operations: XMLConfiguration config = new XMLConfiguration(c:\\conf.xml); config.save(); BUG: After config.save(); my conf.xml file, when edited in Vim, contains additional ^M char at the end of each line. This is very disturbing. REASON: There must be a bug in XMLConfiguration when operating on !-- -- xml comments which contain new line characters - as in my example. !-- comment new line in comment -- My original conf.xml contained 0D 0A chars as a new line in comment, after calling config.save(); there is ONLY 0A char there! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-237) Contrib : managed reloading strategy
[ https://issues.apache.org/jira/browse/CONFIGURATION-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-237. Resolution: Fixed Fix Version/s: (was: 1.5) 1.4 Patch applied with minor modifications. Thanks very much. Contrib : managed reloading strategy Key: CONFIGURATION-237 URL: https://issues.apache.org/jira/browse/CONFIGURATION-237 Project: Commons Configuration Issue Type: New Feature Affects Versions: Nightly Builds Reporter: nicolas de loof Priority: Minor Fix For: 1.4 Attachments: CONFIGURATION-237.patch, howto-filebased.patch, ManagedReloadingStrategyTest.java This patch adds a reloading strategy based on management request, typically from a JMX console. The Strategy implements a MBean interface so can be exported as a JMX Managed bean with no code change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-249) save to URLs with a protocol other than file:
[ https://issues.apache.org/jira/browse/CONFIGURATION-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-249: --- Fix Version/s: (was: 1.4) 1.5 save to URLs with a protocol other than file: --- Key: CONFIGURATION-249 URL: https://issues.apache.org/jira/browse/CONFIGURATION-249 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.4 Reporter: Anselm Kruis Priority: Minor Fix For: 1.5 Currently, the save(URL) method from AbstractFileConfiguration only supports file: URLs. Why not support writing to URLs too? It is as simple like this java.net.URLConnection connection = url.openConnection(); connection.setDoOutput(true); connection.setDoInput(false); save(connection.getOutputStream()); I could prepare a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-252) Detection of absolute fileNames when configuration sources are defined in a JAR file
[ https://issues.apache.org/jira/browse/CONFIGURATION-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-252. Resolution: Fixed Fix Version/s: 1.4 The getFile() method now checks first whether an absolute file name is passed in. A note about the behavior of File.isAbsolute() on Windows and Unix was also added to the Javadocs. Detection of absolute fileNames when configuration sources are defined in a JAR file Key: CONFIGURATION-252 URL: https://issues.apache.org/jira/browse/CONFIGURATION-252 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Environment: Linux Reporter: Heiko Seebach Assigned To: Oliver Heger Fix For: 1.4 Attachments: support-for-jar-protocol.patch.txt When using several configuration sources, the sources are defined in a an xml attribute like fileName=usergui.properties The method org.apache.commons.configuration.ConfigurationUtils.getFile(String basePath, String fileName) converts the basePath and fileName into a File. The JavaDoc says: The parameter strings can be relative files, absolute files and URLs as well. The file containing the definition of the configuration sources will become the basePath of this method. After a log of debugging I found, that if the basePath start with jar: the method assumes that the fileName is relative, evene if it's absolute. This happens, because there's a ProtocolHandler for Jar files and jar: is a valid protocol. So the statement new URL(new URL(basePath), fileName) doesn't throw a MalformedUrlException. Since the URL is valid, it's never checked, if the fileName may be absolute. Attention: this is only the case on Unix/Linux, since this is a valid URL jar:file:/C:/myjar.jar!/my-config.xml/someprops.properties while under Windows, a MalformedUrlException will be thrown, when the fileName is absolute: jar:file:/C:/myjar.jar!/my-config.xml/c:/someprops.properties I attached a patch that checks, whether the URL protocol is jar and the fileName is absolute. If so, the absolute file will be used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-252) Detection of absolute fileNames when configuration sources are defined in a JAR file
[ https://issues.apache.org/jira/browse/CONFIGURATION-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469731 ] Oliver Heger commented on CONFIGURATION-252: Wouldn't it make sense if getFile() always checked whether the passed in fileName is an absolute file, no matter of the protocol? If this is the case, this file must be returned. Detection of absolute fileNames when configuration sources are defined in a JAR file Key: CONFIGURATION-252 URL: https://issues.apache.org/jira/browse/CONFIGURATION-252 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Environment: Linux Reporter: Heiko Seebach Attachments: support-for-jar-protocol.patch.txt When using several configuration sources, the sources are defined in a an xml attribute like fileName=usergui.properties The method org.apache.commons.configuration.ConfigurationUtils.getFile(String basePath, String fileName) converts the basePath and fileName into a File. The JavaDoc says: The parameter strings can be relative files, absolute files and URLs as well. The file containing the definition of the configuration sources will become the basePath of this method. After a log of debugging I found, that if the basePath start with jar: the method assumes that the fileName is relative, evene if it's absolute. This happens, because there's a ProtocolHandler for Jar files and jar: is a valid protocol. So the statement new URL(new URL(basePath), fileName) doesn't throw a MalformedUrlException. Since the URL is valid, it's never checked, if the fileName may be absolute. Attention: this is only the case on Unix/Linux, since this is a valid URL jar:file:/C:/myjar.jar!/my-config.xml/someprops.properties while under Windows, a MalformedUrlException will be thrown, when the fileName is absolute: jar:file:/C:/myjar.jar!/my-config.xml/c:/someprops.properties I attached a patch that checks, whether the URL protocol is jar and the fileName is absolute. If so, the absolute file will be used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-252) Detection of absolute fileNames when configuration sources are defined in a JAR file
[ https://issues.apache.org/jira/browse/CONFIGURATION-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469842 ] Oliver Heger commented on CONFIGURATION-252: So, would it be okay to always check for an absolute file name first (by using File.isAbsolute()) and pointing this out in the Javadoc of getFile()? Detection of absolute fileNames when configuration sources are defined in a JAR file Key: CONFIGURATION-252 URL: https://issues.apache.org/jira/browse/CONFIGURATION-252 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Environment: Linux Reporter: Heiko Seebach Attachments: support-for-jar-protocol.patch.txt When using several configuration sources, the sources are defined in a an xml attribute like fileName=usergui.properties The method org.apache.commons.configuration.ConfigurationUtils.getFile(String basePath, String fileName) converts the basePath and fileName into a File. The JavaDoc says: The parameter strings can be relative files, absolute files and URLs as well. The file containing the definition of the configuration sources will become the basePath of this method. After a log of debugging I found, that if the basePath start with jar: the method assumes that the fileName is relative, evene if it's absolute. This happens, because there's a ProtocolHandler for Jar files and jar: is a valid protocol. So the statement new URL(new URL(basePath), fileName) doesn't throw a MalformedUrlException. Since the URL is valid, it's never checked, if the fileName may be absolute. Attention: this is only the case on Unix/Linux, since this is a valid URL jar:file:/C:/myjar.jar!/my-config.xml/someprops.properties while under Windows, a MalformedUrlException will be thrown, when the fileName is absolute: jar:file:/C:/myjar.jar!/my-config.xml/c:/someprops.properties I attached a patch that checks, whether the URL protocol is jar and the fileName is absolute. If so, the absolute file will be used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-181) [configuration] Conditional directives in property files
[ https://issues.apache.org/jira/browse/CONFIGURATION-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-181. Resolution: Won't Fix Fix Version/s: 1.4 This issue has been hanging around for a long time now. Committers seem to agree that the proposed addition should not be added to Commons Configuration, so I am closing this ticket as wont' fix. [configuration] Conditional directives in property files Key: CONFIGURATION-181 URL: https://issues.apache.org/jira/browse/CONFIGURATION-181 Project: Commons Configuration Issue Type: Improvement Environment: Operating System: other Platform: Other Reporter: Bogdan Calmac Priority: Minor Fix For: 1.4 Attachments: conditional_properties.patch This patch adds conditional directives to property files similar to C macros: %if, %elseif, %else, %end. To illustrate the necessity and the syntax I will take as example a section of my hibernate configuration file. Switching between databases normally requires to comment/uncomment a lot of properties, and more importantly, cannot be done automatically at runtime. ## JNDI Datasource #hibernate.connection.datasource = jdbc/test #hibernate.connection.username = db2 #hibernate.connection.password = db2 ## HypersonicSQL hibernate.dialect = net.sf.hibernate.dialect.HSQLDialect hibernate.connection.driver_class = org.hsqldb.jdbcDriver hibernate.connection.username = sa hibernate.connection.url = jdbc:hsqldb:hsql://localhost ## PostgreSQL #hibernate.dialect = net.sf.hibernate.dialect.PostgreSQLDialect #hibernate.connection.driver_class = org.postgresql.Driver #hibernate.connection.url = jdbc:postgresql:template1 #hibernate.connection.username = pg #hibernate.connection.password ## JTA transactions #hibernate.transaction.factory_class = net.sf.hibernate.transaction.JTATransactionFactory #jta.UserTransaction = jta/usertransaction #jta.UserTransaction = javax.transaction.UserTransaction #jta.UserTransaction = UserTransaction ## JDBC transactions hibernate.transaction.factory_class = net.sf.hibernate.transaction.JDBCTransactionFactory Here is now how it would look like with conditional directives. The only thing to change now is the property at the top of the file (which could be defined as a system property if you don't want to touch the file at all). Note that it uses nested directives. db = jndi %if db = jndi ## JNDI Datasource hibernate.connection.datasource = jdbc/test hibernate.connection.username = db2 hibernate.connection.password = db2 ## JTA transactions hibernate.transaction.factory_class = net.sf.hibernate.transaction.JTATransactionFactory jta.UserTransaction = jta/usertransaction jta.UserTransaction = javax.transaction.UserTransaction jta.UserTransaction = UserTransaction %else ## JDBC transactions hibernate.transaction.factory_class = net.sf.hibernate.transaction.JDBCTransactionFactory %if db = hypersonic ## HypersonicSQL hibernate.dialect = net.sf.hibernate.dialect.HSQLDialect hibernate.connection.driver_class = org.hsqldb.jdbcDriver hibernate.connection.username = sa hibernate.connection.url = jdbc:hsqldb:hsql://localhost %elseif db = postgres ## PostgreSQL hibernate.dialect = net.sf.hibernate.dialect.PostgreSQLDialect hibernate.connection.driver_class = org.postgresql.Driver hibernate.connection.url = jdbc:postgresql:template1 hibernate.connection.username = pg hibernate.connection.password %end %end The directives used are: %if condition %elseif condition %else %end The condition can be: property (true if the property is defined) property = value (values are interpolated) property != value For the implementation, I've replaced in PropertiesConfiguration.java the call to read a line from the file with a new getNextLine() method which processes the conditional directives and returns the next property line. The method is noop unless the line starts with '%', so it should work just fine with files that do not use the directives. I've also added the TestPropertiesConfiguration.testConditionalDirectives() unit test which uses properties added at the end of test.properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-196) [configuration] Tools for code generation of configuration properties
[ https://issues.apache.org/jira/browse/CONFIGURATION-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-196. Resolution: Won't Fix Fix Version/s: 1.4 I am still on the opinion that this suggestion is out of scope for Commons Configuration. No other committer chimed in, so I am closing this ticket as won't fix. If you are still interested in this topic, maybe you can start a project elsewhere (e.g. sourceforge) that builds upon Commons Configuration. In any case thanks for your interest. [configuration] Tools for code generation of configuration properties - Key: CONFIGURATION-196 URL: https://issues.apache.org/jira/browse/CONFIGURATION-196 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.1 Environment: Operating System: other Platform: Other Reporter: David Leal Priority: Minor Fix For: 1.4 I would like to just suggest a kind of code generation from a defined properties/xml file, so the user can avoid the use of string representing the properties on whole source code. For example if I have the following property: ftpServer.login = anonymous in order to get the value of such property, instead of: getProperty(ftpServer.login); to have an equivalente class representation, like this: getFtpServer().getLogin(); or just: ftpServer().getLogin(); with this solution, you avoid miss-spelling of the property name (for example: instead of ftpServer.loging, ftpserver.login), because you will get a compiler error. in order to get this target we need a kind of code generation of the corresponding classes. Like any other generation tools it should be a mapping file for configuring the way the properties/subproperties/nodes could be mapped, for example tomorrows I would like to map: ftpServer.login to getServe ().getLogin(). With the default configuration the mapping will be the same. It could be just and ant-taks for doing this, probably with velocity would be easy to implement. Thanks in advance, David Leal [EMAIL PROTECTED] (If you want I could colaborate) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-251) project.xml file references deprecated xml-apis-2.0.2
[ https://issues.apache.org/jira/browse/CONFIGURATION-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-251. Resolution: Fixed Fix Version/s: 1.4 Oh, understood. Fixed now in subversion. Thank you for spotting this. project.xml file references deprecated xml-apis-2.0.2 - Key: CONFIGURATION-251 URL: https://issues.apache.org/jira/browse/CONFIGURATION-251 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Reporter: Petteri Räty Assigned To: Oliver Heger Fix For: 1.4 See http://www.ibiblio.org/maven/xml-apis/jars/ In project.xml: dependency groupIdxml-apis/groupId artifactIdxml-apis/artifactId version2.0.2/version urlhttp://xml.apache.org/commons//url properties scopeprovided/scope war.bundletrue/war.bundle /properties /dependency I found this was used in both 1.3 release and svn trunk Last Changed Rev: 498155 Last Changed Date: 2007-01-20 21:23:52 +0200 (Sat, 20 Jan 2007) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-251) project.xml file references deprecated xml-apis-2.0.2
[ https://issues.apache.org/jira/browse/CONFIGURATION-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468041 ] Oliver Heger commented on CONFIGURATION-251: Why do you think that this is a bug? This dependency was introduced because the minimum supported JDK is still 1.3, which does not contain the XML classes. Therefore on the dependencies page you can see entries like Java 1.4 or (xml-apis + xerces + xalan). project.xml file references deprecated xml-apis-2.0.2 - Key: CONFIGURATION-251 URL: https://issues.apache.org/jira/browse/CONFIGURATION-251 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Final Reporter: Petteri Räty See http://www.ibiblio.org/maven/xml-apis/jars/ In project.xml: dependency groupIdxml-apis/groupId artifactIdxml-apis/artifactId version2.0.2/version urlhttp://xml.apache.org/commons//url properties scopeprovided/scope war.bundletrue/war.bundle /properties /dependency I found this was used in both 1.3 release and svn trunk Last Changed Rev: 498155 Last Changed Date: 2007-01-20 21:23:52 +0200 (Sat, 20 Jan 2007) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-177) [configuration] Add FilterConfiguration decorator
[ https://issues.apache.org/jira/browse/CONFIGURATION-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-177: --- Fix Version/s: 1.5 Let's target this to a version where we drop the JDK 1.3 compatibility requirement. (But I don't know when this will be.) [configuration] Add FilterConfiguration decorator - Key: CONFIGURATION-177 URL: https://issues.apache.org/jira/browse/CONFIGURATION-177 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.0 Alpha Environment: Operating System: other Platform: Other Reporter: David Eric Pugh Priority: Minor Fix For: 1.5 Hi all, I've got a FilterConfiguration that I ripped out that decoreates any other Configuration. You supply a java.util.regex pattern, and then the keys are filtered on this value.. It's somewhat similar to the subset Configuraiton, but a bit more flexible. You can filter on any part of the key.. I have the unit test as well. Is there any reason not to commit this since we have quite a few changes for the next Release Candidate? Eric -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-140) [configuration] Header parsing for PropertiesConfiguration
[ https://issues.apache.org/jira/browse/CONFIGURATION-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-140: --- Fix Version/s: (was: Nightly Builds) 1.3 [configuration] Header parsing for PropertiesConfiguration -- Key: CONFIGURATION-140 URL: https://issues.apache.org/jira/browse/CONFIGURATION-140 Project: Commons Configuration Issue Type: Improvement Affects Versions: Nightly Builds Environment: Operating System: All Platform: All Reporter: Emmanuel Bourg Priority: Minor Fix For: 1.3 The load method of PropertiesConfiguration should be able to set the header from the first comments at the beginning of the file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-145) [configuration] clone() implementation for all configurations
[ https://issues.apache.org/jira/browse/CONFIGURATION-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-145: --- Fix Version/s: (was: Nightly Builds) 1.3 [configuration] clone() implementation for all configurations - Key: CONFIGURATION-145 URL: https://issues.apache.org/jira/browse/CONFIGURATION-145 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.2 Environment: Operating System: All Platform: All Reporter: Mike Ferraro Assigned To: Oliver Heger Priority: Minor Fix For: 1.3 Original email text: --- The HierarchicalConfiguration class contains a clone() method, to allow decoupling of a configuration from the underlying file to prevent ill effects during configuration updates. So, for example, I can clone an XMLConfiguration for a user's session in a web app and update the configuration file underneath so that the updates will be active for the next user and the current user will not experience some undesirable effect due to the change. My question is why this concept does not exist at a higher level? It would seem that any class that implements the FileConfiguration interface (and therefore the ReloadingStategy concept), should implement a method that allows the configuration to be temporarily decoupled from the source. Are there any plans for cloning to be enforced at a FileConfiguration level? From a completely selfish standpoint, I have a CompositeConfiguration object that contains several PropertiesConfigurations and XMLConfigurations with different reloading strategies. I'd like to clone this for each user session for the above mentioned reason. Ideally, the CompositeConfiguration would be clonable (cloning each of the encapsulated configurations), but barring that, it would be nice to be able to loop through the contained configurations and perform a FileConfiguration.clone() on each object. Or maybe there's another way to do this that I'm not seeing? TIA, Mike Mike, a consistent implementation of clone() methods would IMO make sense for most of the Configuration implementations. Would you be so kind to open an enhancement ticket for this in bugzilla, so this idea won't get lost (see http://jakarta.apache.org/commons/configuration/issue-tracking.html)? Thanks. What may help you ATM are some utility methods in ConfigurationUtils for copying configurations. You might have a look at this class and maybe you can use some of the stuff to solve your problem. Oliver -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-170) [configuration] Add an option to save multiple values in one line
[ https://issues.apache.org/jira/browse/CONFIGURATION-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-170: --- Fix Version/s: (was: Nightly Builds) 1.3 [configuration] Add an option to save multiple values in one line - Key: CONFIGURATION-170 URL: https://issues.apache.org/jira/browse/CONFIGURATION-170 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.2 Environment: Operating System: All Platform: All Reporter: Kenji Nakamura Priority: Minor Fix For: 1.3 I'd like to save a property to a file with List type value in one line. By default, the output looks like this. key = value1 key = value2 I want to make the output like this. key = value1, value2 Changing delimiter to '0' before calling save achieves the format, but retrieval of the value, say by calling getList(), results in returning a value value1, value2 instead of values value1 and value2, even if the original delimiter ',' is set back. In addition to that, the delimiter is defined as static and changing the value affects all threads, which is not typically desirable. It would be nice to have an option to save multiple values in a single line, with thread safe manner. Thanks, -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-214) Adding an integer and getting it as a long causes an exception
[ https://issues.apache.org/jira/browse/CONFIGURATION-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-214: --- Fix Version/s: (was: Nightly Builds) 1.3 Adding an integer and getting it as a long causes an exception -- Key: CONFIGURATION-214 URL: https://issues.apache.org/jira/browse/CONFIGURATION-214 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Environment: Linux, java 1.5 Reporter: Sebastiano Vigna Assigned To: Oliver Heger Priority: Minor Fix For: 1.3 Try this in a BeanShell: bsh % p = new org.apache.commons.configuration.PropertiesConfiguration(); bsh % p.setProperty(foo, 6); bsh % p.getLong(foo); // Error: // Uncaught Exception: Method Invocation p.getLong : at Line: 3 : in file: unknown file : p .getLong ( foo ) Target exception: org.apache.commons.configuration.ConversionException: 'foo' doesn't map to a Long object org.apache.commons.configuration.ConversionException: 'foo' doesn't map to a Long object at org.apache.commons.configuration.AbstractConfiguration.getLong(AbstractConfiguration.java:667) The problem is that when an object in a property is not a Long, the only attempt of PropertyConverter.toLong() is that of treating it as a string. It could try to convert it to a Number first and then try to convert it to a long. It is a very confusing behaviour, because if you save and reload the properties everything works fine (as now the integer is a string). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-216) Inconsistent way to locate filename when creating configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-216: --- Fix Version/s: (was: Nightly Builds) 1.3 Inconsistent way to locate filename when creating configuration --- Key: CONFIGURATION-216 URL: https://issues.apache.org/jira/browse/CONFIGURATION-216 Project: Commons Configuration Issue Type: Bug Environment: commons-configuration-1.3-dev Reporter: Gabriele Garuglieri Assigned To: Oliver Heger Priority: Minor Fix For: 1.3 Attachments: 216-1.patch, resources.jar There is a different behaviour locating the configuration file in classpath depending on the way it is set in the configuration class. For example assuming conf/conf1.properties exists in classpath: PropertiesConfiguration pc = new PropertiesConfiguration(conf/conf1.properties); gives org.apache.commons.configuration.ConfigurationException: Cannot locate configuration source conf1.properties while PropertiesConfiguration pc = new PropertiesConfiguration(); pc.setFileName(conf/conf1.properties); pc.load(); properly locate file in classpath and loads it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-217) Possible Maven2 POM dependency clash for Servlet-API
[ https://issues.apache.org/jira/browse/CONFIGURATION-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-217: --- Fix Version/s: (was: Nightly Builds) 1.3 Possible Maven2 POM dependency clash for Servlet-API Key: CONFIGURATION-217 URL: https://issues.apache.org/jira/browse/CONFIGURATION-217 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Environment: Maven 2.0.4 Windows XP Reporter: Christoph Cenowa Priority: Minor Fix For: 1.3 As described by ASF bug #33476 Commons Configurations shall depend on Servlet-API 2.4. The current Maven2 POM of Commons Configuration 1.2 shows a dependency on Servlet-API 2.3. This is not only a mismatch between Commons Configurations' build configuration and its Maven2 POM but also prevents Maven2 projects from using the Servlet-API 2.4 if also using Commons Configuration 1.2. Could it be possible to fix Commons Configuration 1.2's Maven2 POM to include a dependency on Servlet-API 2.4, please? With best regards, Christoph P.S.: My thanks for the quick fix of the Commons Collection dependency problem within Commons Configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-219) PropertiesConfiguration.clone() does not properly handle the layout object
[ https://issues.apache.org/jira/browse/CONFIGURATION-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-219: --- Fix Version/s: (was: Nightly Builds) 1.3 PropertiesConfiguration.clone() does not properly handle the layout object -- Key: CONFIGURATION-219 URL: https://issues.apache.org/jira/browse/CONFIGURATION-219 Project: Commons Configuration Issue Type: Bug Affects Versions: Nightly Builds Reporter: Oliver Heger Assigned To: Oliver Heger Fix For: 1.3 If a PropertiesConfiguration object is cloned, the clone will have the same PropertiesConfigurationLayout object. Of course this will cause trouble when later both objects are modified and then written to a file. PropertiesConfiguration needs a specific clone() implementation, which also clones the layout object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-220) getDateArray(String key, Date[] defaultValue, String format) ignores format argument
[ https://issues.apache.org/jira/browse/CONFIGURATION-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-220: --- Fix Version/s: (was: Nightly Builds) 1.3 getDateArray(String key, Date[] defaultValue, String format) ignores format argument Key: CONFIGURATION-220 URL: https://issues.apache.org/jira/browse/CONFIGURATION-220 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Reporter: carl green Priority: Minor Fix For: 1.3 getDateArray(String key, Date[] defaultValue, String format) in DataConfiguration takes a format argument, but it is not used in the call to getDateList(key). This call should probably be getDateList(key, format). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-221) Allow system properties in config.xml
[ https://issues.apache.org/jira/browse/CONFIGURATION-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-221: --- Fix Version/s: (was: Nightly Builds) 1.3 Allow system properties in config.xml - Key: CONFIGURATION-221 URL: https://issues.apache.org/jira/browse/CONFIGURATION-221 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.2 Environment: All Reporter: Rainer Jung Assigned To: Oliver Heger Fix For: 1.3 Attachments: commons-configuration_1_2_patch.txt The attached patch allows system properties in the filename attributes of a config.xml file used in the factory. The patch is very simple, since commons-digester parses the file and has a built in capability to do the property substitution. The dependency of commons-configuration to commons-digester goes up from version 1.5 to 1.6. The most recent version 1.7 of commons-digester is not necessary. The patch can easily be ported to 1.3 and trunk. Use case: often the config.xml files are contained in a distribution unit like a war file, that should not be manipulated after packaging. The path names in config.xml need some way of making them externally variable so that the packaging unit can be adoped to a special environment without repackaging. By allowing system properties in the file names, this can be done easily. The implementation is simple, short and low risk. It would be nice, if you considered the patch for inclusion in the next release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-222) Saving PropertiesConfiguration created with PropertiesConfiguration() constructor creates empty files
[ https://issues.apache.org/jira/browse/CONFIGURATION-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-222: --- Fix Version/s: (was: Nightly Builds) 1.3 Saving PropertiesConfiguration created with PropertiesConfiguration() constructor creates empty files - Key: CONFIGURATION-222 URL: https://issues.apache.org/jira/browse/CONFIGURATION-222 Project: Commons Configuration Issue Type: Bug Environment: 1.3RC1 Reporter: Gabriele Garuglieri Fix For: 1.3 Attachments: layout.patch The introduction of PropertiesConfigurationLayout broke the saving of in memory created PropertesConfiguration. This piece of code will yield empt saved file: PropertiesConfiguration pc = new PropertiesConfiguration(); pc.addProperty(string, value1); pc.save(testsave.properties); The problem is that no PropertiesConfigurationLayout is created and EVENT_ADD_PROPERTY is lost. Then when saving, an empty PropertiesConfigurationLayout is created and nothing is saved in output file. Added creation of PropertiesConfigurationLayout to PropertiesConfiguration() contructor, changed setLayout() to enforce that only one layout per PropertiesConfiguration must exist and added a testcase for this condition. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-223) PropertiesConfigurationLayout broke the autoSave behaviour of PropertiesConfiguration
[ https://issues.apache.org/jira/browse/CONFIGURATION-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-223: --- Fix Version/s: (was: Nightly Builds) 1.3 PropertiesConfigurationLayout broke the autoSave behaviour of PropertiesConfiguration - Key: CONFIGURATION-223 URL: https://issues.apache.org/jira/browse/CONFIGURATION-223 Project: Commons Configuration Issue Type: Bug Environment: 1.3RC1 Reporter: Gabriele Garuglieri Assigned To: Oliver Heger Priority: Critical Fix For: 1.3 Attachments: 223-test.patch When using PropertiesConfiguration with autoSave true the PropertiesConfigurationLayout causes invalid properties files to be saved. When using addProperty(key, value); where key does not exist yet in the configuration the EVENT_ADD_PROPERTY event that updates the PropertiesConfigurationLayout with the new key is issued only after the possiblySave() method is invoked so the new property will not be saved. When using setProperty(key, value); where key does not exist yet in the configuration the EVENT_SET_PROPERTY event that updates the PropertiesConfigurationLayout with the new key is issued only after the possiblySave() method is invoked so the new property will not be saved. The way it is implemented now makes content of the saved file depending on PropertiesConfigurationLayout content that depends on an event that will be issued only after the file was properly updated. This creates a circular dependency that cannot work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-224) BaseConfiguration.getProperty() returns reference to intenal store collection object instead of a clone
[ https://issues.apache.org/jira/browse/CONFIGURATION-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-224: --- Fix Version/s: (was: Nightly Builds) 1.3 BaseConfiguration.getProperty() returns reference to intenal store collection object instead of a clone --- Key: CONFIGURATION-224 URL: https://issues.apache.org/jira/browse/CONFIGURATION-224 Project: Commons Configuration Issue Type: Bug Environment: 1.3RC2 Reporter: Gabriele Garuglieri Priority: Minor Fix For: 1.3 Attachments: list.patch When the property object is a List or an Array, BaseConfiguration.getProperty() returns a reference to the object contained in the store. This means that changing that object, changes the content of the properties store without an explicit setProperty() or addProperty(). Also any change to the object in the store will change the object that the code has reference to, but the user is not aware that the property has changed unless he has added a ConfigurationListener. Attached a patch to make the object returned by BaseConfiguration.getProperty() a clone of store content, to avoid side effects when changing Collection properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-225) Document exactly what's returned by ConfigurationEvent.getPropertyValue() after EVENT_ADD_PROPERTY.
[ https://issues.apache.org/jira/browse/CONFIGURATION-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-225: --- Fix Version/s: (was: Nightly Builds) 1.3 Document exactly what's returned by ConfigurationEvent.getPropertyValue() after EVENT_ADD_PROPERTY. --- Key: CONFIGURATION-225 URL: https://issues.apache.org/jira/browse/CONFIGURATION-225 Project: Commons Configuration Issue Type: Improvement Environment: 1.3RC2 Reporter: Gabriele Garuglieri Assigned To: Oliver Heger Priority: Minor Fix For: 1.3 It should be documented that when the property content is a Collection, after EVENT_ADD_PROPERTY, ConfigurationEvent.getPropertyValue() returns only the value of what is being added to the property and not the whole property content as after EVENT_SET_PROPERTY. It took me a while to understand why in certain circumstances my testcases were failing :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-226) Describe more accurate about the getBoolean() method
[ https://issues.apache.org/jira/browse/CONFIGURATION-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-226: --- Fix Version/s: (was: Nightly Builds) 1.3 Describe more accurate about the getBoolean() method Key: CONFIGURATION-226 URL: https://issues.apache.org/jira/browse/CONFIGURATION-226 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.2 Reporter: Thomas Wabner Priority: Minor Fix For: 1.3 In the javadoc there is only described, that a boolean value is try to load in the Configuration#getBoolean() methods. But do you mean the Java Boolean values which are only working for strings like true and false or do you have a more lazy implementation like for string in the combination true, false, t, f, y, n and so on? The javadoc should speak more about this. Is it possible to add the mory lazy boolean loading stuff? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-227) ConfigurationDynaBean does not work well with all types of configurations
[ https://issues.apache.org/jira/browse/CONFIGURATION-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-227: --- Fix Version/s: (was: Nightly Builds) 1.3 ConfigurationDynaBean does not work well with all types of configurations - Key: CONFIGURATION-227 URL: https://issues.apache.org/jira/browse/CONFIGURATION-227 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.2 Reporter: Oliver Heger Assigned To: Oliver Heger Priority: Minor Fix For: 1.3 The current implementation of ConfigurationDynaBean makes some assumptions about the underlying Configuration object that are not met by all configuration implementations. Especially setting values for indexed properties by calling getList() and manipulating mapped properties through a subset configuration do not work for configurations derived from HierarchicalConfiguration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-245) DatabaseConfiguration and JNDIConfiguration are eating exceptions
[ https://issues.apache.org/jira/browse/CONFIGURATION-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-245. Resolution: Fixed Fix Version/s: 1.4 The concept of error listeners was implemented. It is now possible for an interested client to register itself as an error listener at a configuration. It is then notified about internal errors. DatabaseConfiguration, JNDIConfiguration, and AbstractFileConfiguration use this new concept for reporting internal errors. DatabaseConfiguration and JNDIConfiguration are eating exceptions - Key: CONFIGURATION-245 URL: https://issues.apache.org/jira/browse/CONFIGURATION-245 Project: Commons Configuration Issue Type: Bug Affects Versions: Nightly Builds, 1.3 Final Reporter: Hal Deadman Assigned To: Oliver Heger Fix For: 1.4 DatabaseConfiguration and JNDIConfiguration and possibly others, really need to throw some sort of runtime exception to let the caller know the properties couldn't be read. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-249) save to URLs with a protocol other than file:
[ https://issues.apache.org/jira/browse/CONFIGURATION-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466267 ] Oliver Heger commented on CONFIGURATION-249: A patch would be highly appreciated. If you could provide a unit test for the new feature, too, this would be even better. Thank you very much. save to URLs with a protocol other than file: --- Key: CONFIGURATION-249 URL: https://issues.apache.org/jira/browse/CONFIGURATION-249 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.4 Reporter: Anselm Kruis Priority: Minor Fix For: 1.4 Currently, the save(URL) method from AbstractFileConfiguration only supports file: URLs. Why not support writing to URLs too? It is as simple like this java.net.URLConnection connection = url.openConnection(); connection.setDoOutput(true); connection.setDoInput(false); save(connection.getOutputStream()); I could prepare a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (CONFIGURATION-250) build.xml file fetches the wrong version of commons-lang
[ https://issues.apache.org/jira/browse/CONFIGURATION-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-250. Resolution: Fixed Fix Version/s: 1.4 Fixed in subversion. Thank you for the spot. build.xml file fetches the wrong version of commons-lang Key: CONFIGURATION-250 URL: https://issues.apache.org/jira/browse/CONFIGURATION-250 Project: Commons Configuration Issue Type: Bug Affects Versions: Nightly Builds Reporter: Anselm Kruis Assigned To: Oliver Heger Priority: Trivial Fix For: 1.4 The build.xml fetches commons-lang-2.1.jar instead of commons-lang-2.2.jar. Seems to be related to the change 2006-12-23 17:36 oheger * [r489906] project.properties, project.xml: Updated dependency to lang 2.2, minor site improvements Fix is trivial. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-215) Using relative URLs
[
https://issues.apache.org/jira/browse/CONFIGURATION-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger updated CONFIGURATION-215:
---
Fix Version/s: 1.5
Affects Version/s: 1.3 Final
Setting fix version to release 1.5, assuming that 1.4 can come out soon. A
solution of this problem would also be helpful for the requested feature of
saving back changes made at a composite configuration.
Using relative URLs
---
Key: CONFIGURATION-215
URL: https://issues.apache.org/jira/browse/CONFIGURATION-215
Project: Commons Configuration
Issue Type: Improvement
Affects Versions: 1.3 Final
Reporter: Michiel Kalkman
Priority: Minor
Fix For: 1.5
It would be useful to be able to specify URLs in configuration item values
that are relative to the configuration.
A sample. I have the following files.
A/config.xml which refers to
B/specificConfigForB.xml which refers to
B/somefile
Now specifying the location of somefile in specificConfigForB.xml should be
possible using a relative URL, such that it is possible to retrieve the
absolute URL of somefile through:
a) the absolute URL of A/config.xml (e.g.: file:/c:/A/config.xml or
http://A/config.xml)
b) the relative URL of somefile specified in B/specificConfigForB.xml (like
somefilesomefile/somefile)
(1) One solution is to make it possible to find the location of the
configuration file that specifies the relative URL. Or more general, commons
config should know where a given configuration item is stored.
In this case it might be an idea to implement a getURL() on the Configuration
interface which uses:
1. the absolute URL of the composite configuration file, (A/config.xml)
2. the relative URL to the specfying configuration file,
(B/specificConfigForB.xml)
3. the relative URL specified (in B/specificConfigForB.xml)
(2) Another solution is to specify a special meta variable (like ${url}) that
can be used to specify the location of the specifying configuration file wrt
the composite configuration file. E.g. somefile${url}/somefile/somefile
would result in ../B/somefile.
(3) Another solution would be to specify a special attribute to indicate that
the value specified is an URL. Like somefile type=URLsomefile/somefile.
The advantage of solution (1) is that no extra semantics are introduced to
the configuration files. Furthermore, it might possibly be useful in
debugging situations. The advantages of solution (2) is that in this manner
other meta variables might be introduced. The disadvantage of solution (3) is
that this one cannot be applied to property files.
See also
http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200606.mbox/[EMAIL
PROTECTED]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-248) Safeguard config source abstraction by using HierarchicalConfiguration as supertype for all configs
[ https://issues.apache.org/jira/browse/CONFIGURATION-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-248: --- Fix Version/s: 2.0 Affects Version/s: (was: 2.0) 1.3 Final Safeguard config source abstraction by using HierarchicalConfiguration as supertype for all configs --- Key: CONFIGURATION-248 URL: https://issues.apache.org/jira/browse/CONFIGURATION-248 Project: Commons Configuration Issue Type: Wish Affects Versions: 1.3 Final Environment: - Reporter: Dennis Kuehn Fix For: 2.0 I hope I get this right: When I have a CompositeConfiguration, the nice thing about it is that I don't have to care in which file or file type a config entry has been defined. Now when part of my CompositeConfiguration has a hierarchical structure and I need the API provided by HierarchicalConfiguration, I lose the aforementioned abstraction: I need to cast a specific part of my CompositeConfiguration to HierarchicalConfiguration. This is a major design problem! It would be better to leverage the Composite Pattern here: derive all configuration classes from HierarchicalConfiguration. Put differently, move the HierarchicalConfiguration API to Configuration. Even if a config is not hierarchically structured, methods for hierarchical access will be present, but that's a minor drawback which is intrinsic to the Composite Pattern. This also happens when you are modelling a tree structure and you have a common supertype Node which has a method getSubNodes() which will also be present in leaf node instances (in this case, getSubNodes() would return null etc.). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONFIGURATION-248) Safeguard config source abstraction by using HierarchicalConfiguration as supertype for all configs
[ https://issues.apache.org/jira/browse/CONFIGURATION-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-248: --- Affects Version/s: (was: 1.3 Final) 2.0 I agree that a future version of the Configuration interface should support the special operations for hierarchical configurations. Non hierarchical configurations can be seen as a flat special case for hierarchical configurations. However because this is a major change that would break binary compatibility, such a change can only be done in a major release, i.e. for Commons Configuration 2.0. In the meantime: Did you see the CombinedConfiguration class? This is a hierarchical version of CompositeConfiguration. Safeguard config source abstraction by using HierarchicalConfiguration as supertype for all configs --- Key: CONFIGURATION-248 URL: https://issues.apache.org/jira/browse/CONFIGURATION-248 Project: Commons Configuration Issue Type: Wish Affects Versions: 1.3 Final Environment: - Reporter: Dennis Kuehn Fix For: 2.0 I hope I get this right: When I have a CompositeConfiguration, the nice thing about it is that I don't have to care in which file or file type a config entry has been defined. Now when part of my CompositeConfiguration has a hierarchical structure and I need the API provided by HierarchicalConfiguration, I lose the aforementioned abstraction: I need to cast a specific part of my CompositeConfiguration to HierarchicalConfiguration. This is a major design problem! It would be better to leverage the Composite Pattern here: derive all configuration classes from HierarchicalConfiguration. Put differently, move the HierarchicalConfiguration API to Configuration. Even if a config is not hierarchically structured, methods for hierarchical access will be present, but that's a minor drawback which is intrinsic to the Composite Pattern. This also happens when you are modelling a tree structure and you have a common supertype Node which has a method getSubNodes() which will also be present in leaf node instances (in this case, getSubNodes() would return null etc.). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
