[jira] [Commented] (CONFIGURATION-812) Support for TOML configuration files
[ https://issues.apache.org/jira/browse/CONFIGURATION-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17478954#comment-17478954 ] Oliver Heger commented on CONFIGURATION-812: YAML is supported, there is a _YAMLConfiguration_ class, although this format is not explicitly listed on the site. > Support for TOML configuration files > > > Key: CONFIGURATION-812 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-812 > Project: Commons Configuration > Issue Type: New Feature > Components: Format >Reporter: Thomas Reiter >Priority: Minor > > I would like to add a parser and implementation for the TOML format (v1.0.0). > Let me know, if you have any thoughts on this. > See [TOML 1.0.0|https://toml.io/en/v1.0.0] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CONFIGURATION-807) Method addProperty don't work if the property not exist in the file
[
https://issues.apache.org/jira/browse/CONFIGURATION-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17340900#comment-17340900
]
Oliver Heger commented on CONFIGURATION-807:
Sorry, my bad. I sent you a link to the old version of the user guide. [This
page|https://commons.apache.org/proper/commons-configuration/userguide/howto_filebased.html#File_Operations_on_Configurations]
describes how to save a configuration object. But the fundamental problem
remains that you need to save the configuration and not the layout object.
> Method addProperty don't work if the property not exist in the file
> ---
>
> Key: CONFIGURATION-807
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-807
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Marco Di Falco
>Priority: Major
> Attachments: image-2021-05-07-12-06-03-339.png,
> image-2021-05-07-12-09-33-450.png
>
>
> The method addProperty not append a NEW property in the file when the
> property not exist.
> I work with java 7.
> I see that the new property don't compare in keys list, and when the
> property is new.
> Example:
> {code:java}
> PropertiesConfiguration config = new PropertiesConfiguration();
> PropertiesConfigurationLayout layout = new PropertiesConfigurationLayout();
> layout.load(config, new InputStreamReader(new FileInputStream(zookeeper)));
> String port = instance.getPort();
> config.setProperty("clientPort", port);
> config.addProperty("prova","prova");
> layout.save(config, new FileWriter(zookeeper));
> {code}
> The property 'prova' don't appear in the file property after the save.
> I see in PropertiesConfigurationLayout.save, line 565, that the method
> 'getKeys' don't contain the property 'prova', and the save lost this property.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CONFIGURATION-807) Method addProperty don't work if the property not exist in the file
[
https://issues.apache.org/jira/browse/CONFIGURATION-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17340693#comment-17340693
]
Oliver Heger commented on CONFIGURATION-807:
The problem is that you use the wrong method to save the modified
configuration. Do not call _save()_ on the layout, but on the configuration
object. See
https://commons.apache.org/proper/commons-configuration/userguide_v1.10/howto_properties.html#Saving.
> Method addProperty don't work if the property not exist in the file
> ---
>
> Key: CONFIGURATION-807
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-807
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Marco Di Falco
>Priority: Major
>
> The method addProperty not append a NEW property in the file when the
> property not exist.
> I work with java 7.
> I see that the new property don't compare in keys list, and when the
> property is new.
> Example:
> {code:java}
> PropertiesConfiguration config = new PropertiesConfiguration();
> PropertiesConfigurationLayout layout = new PropertiesConfigurationLayout();
> layout.load(config, new InputStreamReader(new FileInputStream(zookeeper)));
> String port = instance.getPort();
> config.setProperty("clientPort", port);
> config.addProperty("prova","prova");
> layout.save(config, new FileWriter(zookeeper));
> {code}
> The property 'prova' don't appear in the file property after the save.
> I see in PropertiesConfigurationLayout.save, line 565, that the method
> 'getKeys' don't contain the property 'prova', and the save lost this property.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1339) Some classes depend on the java.desktop profile
[ https://issues.apache.org/jira/browse/LANG-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17086514#comment-17086514 ] Oliver Heger commented on LANG-1339: [~kinow], sounds like a good plan. > Some classes depend on the java.desktop profile > --- > > Key: LANG-1339 > URL: https://issues.apache.org/jira/browse/LANG-1339 > Project: Commons Lang > Issue Type: Task >Reporter: Benedikt Ritter >Priority: Major > Labels: Java9 > Fix For: 4.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Commons Lang currently depends on java.desktop. This seems like an > unnecessary heavy dependency for a library like Commons Lang. We need to find > a way to fix this, without breaking bc. For more information see > https://lists.apache.org/thread.html/8db8ec4aa1bdeae3d471ca4f46a21dc7da1a4c6933e1810238b72283@%3Cdev.commons.apache.org%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LANG-1339) Some classes depend on the java.desktop profile
[ https://issues.apache.org/jira/browse/LANG-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17086020#comment-17086020 ] Oliver Heger commented on LANG-1339: [~kinow], I am fine with these changes, using a Consumer for state notifications is a good idea. If you want to support multiple state listeners, an option could be to have a thread-safe list with Consumer objects, e.g. a CopyOnWriteArrayList, and have corresponding addListener() and removeListener() methods. But I am not sure whether this is worth the effort. > Some classes depend on the java.desktop profile > --- > > Key: LANG-1339 > URL: https://issues.apache.org/jira/browse/LANG-1339 > Project: Commons Lang > Issue Type: Task >Reporter: Benedikt Ritter >Priority: Major > Labels: Java9 > Fix For: 4.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Commons Lang currently depends on java.desktop. This seems like an > unnecessary heavy dependency for a library like Commons Lang. We need to find > a way to fix this, without breaking bc. For more information see > https://lists.apache.org/thread.html/8db8ec4aa1bdeae3d471ca4f46a21dc7da1a4c6933e1810238b72283@%3Cdev.commons.apache.org%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CONFIGURATION-784) Update org.yaml:snakeyaml from 1.25 to 1.26 and tweak parser configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-784. Resolution: Fixed > Update org.yaml:snakeyaml from 1.25 to 1.26 and tweak parser configuration > -- > > Key: CONFIGURATION-784 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-784 > Project: Commons Configuration > Issue Type: Improvement >Reporter: Gary D. Gregory >Assignee: Oliver Heger >Priority: Major > Fix For: 2.7 > > > Update org.yaml:snakeyaml from 1.25 to 1.26. > The configuration of the Yaml object when loading files can also be improved, > e.g. by specifying concrete parameters for LoaderOptions, Constructor, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (CONFIGURATION-784) Update org.yaml:snakeyaml from 1.25 to 1.26
[ https://issues.apache.org/jira/browse/CONFIGURATION-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger reopened CONFIGURATION-784: Assignee: Oliver Heger > Update org.yaml:snakeyaml from 1.25 to 1.26 > --- > > Key: CONFIGURATION-784 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-784 > Project: Commons Configuration > Issue Type: Improvement >Reporter: Gary D. Gregory >Assignee: Oliver Heger >Priority: Major > Fix For: 2.7 > > > Update org.yaml:snakeyaml from 1.25 to 1.26. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CONFIGURATION-784) Update org.yaml:snakeyaml from 1.25 to 1.26 and tweak parser configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-784: --- Description: Update org.yaml:snakeyaml from 1.25 to 1.26. The configuration of the Yaml object when loading files can also be improved, e.g. by specifying concrete parameters for LoaderOptions, Constructor, etc. was:Update org.yaml:snakeyaml from 1.25 to 1.26. > Update org.yaml:snakeyaml from 1.25 to 1.26 and tweak parser configuration > -- > > Key: CONFIGURATION-784 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-784 > Project: Commons Configuration > Issue Type: Improvement >Reporter: Gary D. Gregory >Assignee: Oliver Heger >Priority: Major > Fix For: 2.7 > > > Update org.yaml:snakeyaml from 1.25 to 1.26. > The configuration of the Yaml object when loading files can also be improved, > e.g. by specifying concrete parameters for LoaderOptions, Constructor, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CONFIGURATION-784) Update org.yaml:snakeyaml from 1.25 to 1.26 and tweak parser configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-784: --- Summary: Update org.yaml:snakeyaml from 1.25 to 1.26 and tweak parser configuration (was: Update org.yaml:snakeyaml from 1.25 to 1.26) > Update org.yaml:snakeyaml from 1.25 to 1.26 and tweak parser configuration > -- > > Key: CONFIGURATION-784 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-784 > Project: Commons Configuration > Issue Type: Improvement >Reporter: Gary D. Gregory >Assignee: Oliver Heger >Priority: Major > Fix For: 2.7 > > > Update org.yaml:snakeyaml from 1.25 to 1.26. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JELLY-294) Update Jelly from Jenkins Fork
[ https://issues.apache.org/jira/browse/JELLY-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16799337#comment-16799337 ] Oliver Heger commented on JELLY-294: Good idea, sounds interesting. There is also a Maven Jellydoc plugin ([https://github.com/kohsuke/maven-jellydoc-plugin)] for which I once created a pull request, but the project does not seem to be actively maintained any more. Would we also want to take ownership of this project, too? > Update Jelly from Jenkins Fork > -- > > Key: JELLY-294 > URL: https://issues.apache.org/jira/browse/JELLY-294 > Project: Commons Jelly > Issue Type: New Feature >Reporter: Rob Tompkins >Assignee: Rob Tompkins >Priority: Major > Labels: GSoC2019 > > I think that the jenkins fork is: https://github.com/jenkinsci/jelly > We want to pull their latest code in and do a 2.X jelly release so that we're > maintaining the code as opposed to jenkins having to maintain it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-731) Allow user to specify the comments & separator chars
[ https://issues.apache.org/jira/browse/CONFIGURATION-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16693788#comment-16693788 ] Oliver Heger commented on CONFIGURATION-731: In order to fully integrate the new properties with the builder framework, the parameter interfaces and classes for INIConfiguration should be extended as well. Have a look at the _INIBuilderProperties_ interface and the _INIBuilderParametersImpl_ class in the _builder_ package. > Allow user to specify the comments & separator chars > > > Key: CONFIGURATION-731 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-731 > Project: Commons Configuration > Issue Type: Improvement > Components: Format >Affects Versions: 2.4 >Reporter: Shuai Zhang >Priority: Major > Attachments: CONFIGURATION-731.001.patch, CONFIGURATION-731.002.patch > > > Currently the INIConfiguration defined comments & separator chars as final > static fields, which made it impossible for the user control the behavior of > INIConfiguration parsing. I suggest making them as default value, open setter > & getter methods for the comment & separator chars. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CONFIGURATION-716) PropertiesConfiguration: Escape sequence handling different from Properties
[ https://issues.apache.org/jira/browse/CONFIGURATION-716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-716. Resolution: Fixed Fix Version/s: 2.4 Fixed together with CONFIGURATION-715. > PropertiesConfiguration: Escape sequence handling different from Properties > --- > > Key: CONFIGURATION-716 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-716 > Project: Commons Configuration > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Patrick Schmidt >Priority: Major > Fix For: 2.4 > > > The escape sequence handling in PropertiesConfiguration is different from > java.util.Properties. > The Javadoc (of java.util.Properties) basically states that if an escape > sequence (backslash + character) is not understood, the backslash is simply > removed. PropertiesConfiguration keeps the backslash. E.g. "\ " (backslash + > space) should result in just a space. This sequence is used by Properties to > escape the first leading space in a property value when writing to a > properties-file. PropertiesConfiguration does not understand this syntax. > Also (which is technically a different issue but pretty close to this one) > does not preserve leading spaces in property values when saving. One could > use \u0020 to encode the first leading space, but it would be nicer if it > could just use the simpler "\ ". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CONFIGURATION-715) PropertiesConfiguration should not trim whitespace from the property value
[
https://issues.apache.org/jira/browse/CONFIGURATION-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-715.
Resolution: Fixed
Fix Version/s: 2.4
Patch was applied, and you have been added to the contributors section.
Many thanks again!
> PropertiesConfiguration should not trim whitespace from the property value
> --
>
> Key: CONFIGURATION-715
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-715
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Patrick Schmidt
>Priority: Major
> Fix For: 2.4
>
>
> Currently, PropertiesConfiguration will trim all trailing whitespace from
> property values. This is different from how java.util.Properties behaves. The
> Javadoc explicitly states
> {code:java}
> All remaining characters on the line become part of the associated element
> string{code}
> The responsible code is in the method _readProperty()_ of _PropertiesReader_.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-716) PropertiesConfiguration: Escape sequence handling different from Properties
[ https://issues.apache.org/jira/browse/CONFIGURATION-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636035#comment-16636035 ] Oliver Heger commented on CONFIGURATION-716: The patch for CONFIGURATION-715 covers this issue as well. > PropertiesConfiguration: Escape sequence handling different from Properties > --- > > Key: CONFIGURATION-716 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-716 > Project: Commons Configuration > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Patrick Schmidt >Priority: Major > > The escape sequence handling in PropertiesConfiguration is different from > java.util.Properties. > The Javadoc (of java.util.Properties) basically states that if an escape > sequence (backslash + character) is not understood, the backslash is simply > removed. PropertiesConfiguration keeps the backslash. E.g. "\ " (backslash + > space) should result in just a space. This sequence is used by Properties to > escape the first leading space in a property value when writing to a > properties-file. PropertiesConfiguration does not understand this syntax. > Also (which is technically a different issue but pretty close to this one) > does not preserve leading spaces in property values when saving. One could > use \u0020 to encode the first leading space, but it would be nicer if it > could just use the simpler "\ ". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-715) PropertiesConfiguration should not trim whitespace from the property value
[
https://issues.apache.org/jira/browse/CONFIGURATION-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636032#comment-16636032
]
Oliver Heger commented on CONFIGURATION-715:
Impressive patch! I have applied it (with minor changes, just added some @since
tags) in revision 1842650.
Ideally, we could add a sentence to the user's guide mentioning the new
IOFactory class as an alternative when stricter compatibility to
java.util.Properties is required. Do you want to create a corresponding patch,
too?
Also, if you want to be added to the contributors section in pom.xml, just send
us the data you want to get in.
Many thanks again!
> PropertiesConfiguration should not trim whitespace from the property value
> --
>
> Key: CONFIGURATION-715
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-715
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Patrick Schmidt
>Priority: Major
>
> Currently, PropertiesConfiguration will trim all trailing whitespace from
> property values. This is different from how java.util.Properties behaves. The
> Javadoc explicitly states
> {code:java}
> All remaining characters on the line become part of the associated element
> string{code}
> The responsible code is in the method _readProperty()_ of _PropertiesReader_.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Deleted] (CONFIGURATION-717) Account bugzilla
[ https://issues.apache.org/jira/browse/CONFIGURATION-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger deleted CONFIGURATION-717: --- > Account bugzilla > > > Key: CONFIGURATION-717 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-717 > Project: Commons Configuration > Issue Type: Improvement >Reporter: Moh.riza >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CONFIGURATION-717) Account bugzilla
[ https://issues.apache.org/jira/browse/CONFIGURATION-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger closed CONFIGURATION-717. -- > Account bugzilla > > > Key: CONFIGURATION-717 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-717 > Project: Commons Configuration > Issue Type: Improvement >Reporter: Moh.riza >Priority: Major > Fix For: 2.x > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-715) PropertiesConfiguration should not trim whitespace from the property value
[
https://issues.apache.org/jira/browse/CONFIGURATION-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633490#comment-16633490
]
Oliver Heger commented on CONFIGURATION-715:
Many thanks! I will have a look (probably in a few days).
> PropertiesConfiguration should not trim whitespace from the property value
> --
>
> Key: CONFIGURATION-715
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-715
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Patrick Schmidt
>Priority: Major
>
> Currently, PropertiesConfiguration will trim all trailing whitespace from
> property values. This is different from how java.util.Properties behaves. The
> Javadoc explicitly states
> {code:java}
> All remaining characters on the line become part of the associated element
> string{code}
> The responsible code is in the method _readProperty()_ of _PropertiesReader_.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-715) PropertiesConfiguration should not trim whitespace from the property value
[
https://issues.apache.org/jira/browse/CONFIGURATION-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16626056#comment-16626056
]
Oliver Heger commented on CONFIGURATION-715:
This is great!
Regarding Eclipse formatter: There is none that I am aware of. Unfortunately,
(probably for historical reasons) Commons Components do not use a uniform code
format. But if you build the site with _mvn site,_ the Checkstyle report can
tell you if some style guides have been violated.
> PropertiesConfiguration should not trim whitespace from the property value
> --
>
> Key: CONFIGURATION-715
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-715
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Patrick Schmidt
>Priority: Major
>
> Currently, PropertiesConfiguration will trim all trailing whitespace from
> property values. This is different from how java.util.Properties behaves. The
> Javadoc explicitly states
> {code:java}
> All remaining characters on the line become part of the associated element
> string{code}
> The responsible code is in the method _readProperty()_ of _PropertiesReader_.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-715) PropertiesConfiguration should not trim whitespace from the property value
[
https://issues.apache.org/jira/browse/CONFIGURATION-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16624681#comment-16624681
]
Oliver Heger commented on CONFIGURATION-715:
An alternative IOFactory that tries to mimic the behavior of
java.util.Properties would really be a good enhancement. Are you willing to
work on this? We are happy to review and accept patches.
> PropertiesConfiguration should not trim whitespace from the property value
> --
>
> Key: CONFIGURATION-715
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-715
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Patrick Schmidt
>Priority: Major
>
> Currently, PropertiesConfiguration will trim all trailing whitespace from
> property values. This is different from how java.util.Properties behaves. The
> Javadoc explicitly states
> {code:java}
> All remaining characters on the line become part of the associated element
> string{code}
> The responsible code is in the method _readProperty()_ of _PropertiesReader_.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CONFIGURATION-718) Akun bugzilla erorr
[ https://issues.apache.org/jira/browse/CONFIGURATION-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger closed CONFIGURATION-718. -- > Akun bugzilla erorr > --- > > Key: CONFIGURATION-718 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-718 > Project: Commons Configuration > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Moh.riza >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CONFIGURATION-717) Account bugzilla
[ https://issues.apache.org/jira/browse/CONFIGURATION-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-717. Resolution: Invalid Fix Version/s: (was: 2.3) > Account bugzilla > > > Key: CONFIGURATION-717 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-717 > Project: Commons Configuration > Issue Type: Improvement > Components: Build >Affects Versions: 2.3 >Reporter: Moh.riza >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CONFIGURATION-717) Account bugzilla
[ https://issues.apache.org/jira/browse/CONFIGURATION-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger closed CONFIGURATION-717. -- > Account bugzilla > > > Key: CONFIGURATION-717 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-717 > Project: Commons Configuration > Issue Type: Improvement > Components: Build >Affects Versions: 2.3 >Reporter: Moh.riza >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CONFIGURATION-718) Akun bugzilla erorr
[ https://issues.apache.org/jira/browse/CONFIGURATION-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-718. Resolution: Invalid Fix Version/s: (was: 2.3) > Akun bugzilla erorr > --- > > Key: CONFIGURATION-718 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-718 > Project: Commons Configuration > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Moh.riza >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-715) PropertiesConfiguration should not trim whitespace from the property value
[
https://issues.apache.org/jira/browse/CONFIGURATION-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16622643#comment-16622643
]
Oliver Heger commented on CONFIGURATION-715:
It is not necessarily the goal of _PropertiesConfiguration_ to behave exactly
like java.util.Properties.
The line trimming has been done from the very first release on. So changing
this has a high potential to break client code; it would only be possible to
have an option to turn this on if required.
Can you work around the issue by implementing your own _PropertiesReader_? (The
reader can be customized.) But there is an additional (and probably superflous)
_trim()_ call in _readProperty()_ which would have to be removed.
> PropertiesConfiguration should not trim whitespace from the property value
> --
>
> Key: CONFIGURATION-715
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-715
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Patrick Schmidt
>Priority: Major
>
> Currently, PropertiesConfiguration will trim all trailing whitespace from
> property values. This is different from how java.util.Properties behaves. The
> Javadoc explicitly states
> {code:java}
> All remaining characters on the line become part of the associated element
> string{code}
> The responsible code is in the method _readProperty()_ of _PropertiesReader_.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-714) PropertiesConfiguration builder.getConfiguration fails
[
https://issues.apache.org/jira/browse/CONFIGURATION-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16619652#comment-16619652
]
Oliver Heger commented on CONFIGURATION-714:
According to the exception the file cannot be located. Does it exist in one of
the folders that are searched for by default?
Please note that Jira is not a support forum. If you have questions about using
the library, write a mail to the user mailing list:
[http://commons.apache.org/proper/commons-configuration/mailing-lists.html]
> PropertiesConfiguration builder.getConfiguration fails
> --
>
> Key: CONFIGURATION-714
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-714
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: Tested on Windows 10 with Java 10.
>Reporter: Jarek Sacha
>Priority: Major
>
> Call to FileBasedConfigurationBuilder.getConfiguration fails with an
> exception:
> {noformat}
> Could not locate:
> org.apache.commons.configuration2.io.FileLocator@57fd91c9[fileName=usergui.properties,basePath=,sourceURL=,encoding=ISO-8859-1,fileSystem=,locationStrategy=]
> org.apache.commons.configuration2.ex.ConfigurationException: Could not
> locate:
> org.apache.commons.configuration2.io.FileLocator@57fd91c9[fileName=usergui.properties,basePath=,sourceURL=,encoding=ISO-8859-1,fileSystem=,locationStrategy=]
> at
> org.apache.commons.configuration2.io.FileLocatorUtils.locateOrThrow(FileLocatorUtils.java:346)
> at
> org.apache.commons.configuration2.io.FileHandler.load(FileHandler.java:972)
> at
> org.apache.commons.configuration2.io.FileHandler.load(FileHandler.java:702)
> at
> org.apache.commons.configuration2.builder.FileBasedConfigurationBuilder.initFileHandler(FileBasedConfigurationBuilder.java:312)
> at
> org.apache.commons.configuration2.builder.FileBasedConfigurationBuilder.initResultInstance(FileBasedConfigurationBuilder.java:291)
> at
> org.apache.commons.configuration2.builder.FileBasedConfigurationBuilder.initResultInstance(FileBasedConfigurationBuilder.java:60)
> at
> org.apache.commons.configuration2.builder.BasicConfigurationBuilder.createResult(BasicConfigurationBuilder.java:421)
> at
> org.apache.commons.configuration2.builder.BasicConfigurationBuilder.getConfiguration(BasicConfigurationBuilder.java:285)
> {noformat}
> This can be reproduced with the example code from the User Guide
> [https://commons.apache.org/proper/commons-configuration/userguide/howto_properties.html#Using_PropertiesConfiguration]
> {code:java}
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder =
> new FileBasedConfigurationBuilder PropertiesConfiguration.class)
> .configure(params.properties()
> .setFileName("usergui.properties")
> .setListDelimiterHandler(new DefaultListDelimiterHandler(',')));
> Configuration config = builder.getConfiguration();
> config.setProperty("colors.background", "#00");
> builder.save();
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CONFIGURATION-712) FileHandlerReloadingDetector Does Not Correctly Initialize File Last Modified
[
https://issues.apache.org/jira/browse/CONFIGURATION-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-712.
Resolution: Fixed
Fix Version/s: 2.4
Patch applied in SVN revision 1841034. Many thanks again!
If you want to be added to the contributor's section in pom.xml, please post
the data you want to get in.
> FileHandlerReloadingDetector Does Not Correctly Initialize File Last Modified
> -
>
> Key: CONFIGURATION-712
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-712
> Project: Commons Configuration
> Issue Type: Bug
> Components: File reloading
>Affects Versions: 2.3
>Reporter: Rolland Hobbie
>Priority: Major
> Fix For: 2.4
>
> Attachments: CONFIGURATION-712-InitializeLastModified.patch,
> ReloadingFileBasedConfigurationBuilderExampleTest.java,
> ReloadingFileBasedConfigurationBuilderTest.java
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> [FileHandlerReloadingDetector|https://commons.apache.org/proper/commons-configuration/apidocs/src-html/org/apache/commons/configuration2/reloading/FileHandlerReloadingDetector.html]
> declares the following method:
>
> {code:java}
> 150@Override
> 151public boolean isReloadingRequired()
> 152{
> 153long now = System.currentTimeMillis();
> 154if (now >= lastChecked + getRefreshDelay())
> 155{
> 156lastChecked = now;
> 157
> 158long modified = getLastModificationDate();
> 159if (modified > 0)
> 160{
> 161if (lastModified == 0)
> 162{
> 163// initialization
> 164updateLastModified(modified);
> 165}
> 166else
> 167{
> 168if (modified != lastModified)
> 169{
> 170return true;
> 171}
> 172}
> 173}
> 174}
> 175
> 176return false;
> 177}
> {code}
>
> During initialization of FileHandlerReloadingDetector, lastModified is never
> instantiated, so the first time isReloadingRequired() is invoked lastModified
> will be 0.
>
> This results in two issues:
>
> Test #1
> * Scenario Steps
> ## Initialize ReloadingFileBasedConfigurationBuilder without invoking
> builder.getConfiguration()
> ## Wait longer than refreshDelay
> ## Invoke builder.getReloadingController().checkForReloading(null) to notify
> the FileHandlerReloadingDetector to check for reload
> ## Invoke bulider.getConfiguration()
> ## Update the properties file
> ## Wait longer than refreshDelay
> ## Invoke builder.getReloadingController().checkForReloading(null) to notify
> the FileHandlerReloadingDetector to check for reload
> ## Invoke bulider.getConfiguration()
> * Result - the Configuration does not have the updated value.
>
> Test #2
> * Scenario Steps
> ## Initialize ReloadingFileBasedConfigurationBuilder without invoking
> builder.getConfiguration()
> ## Invoke bulider.getConfiguration()
> ## Update the properties file
> ## Wait longer than refreshDelay
> ## Invoke builder.getReloadingController().checkForReloading(null) to notify
> the FileHandlerReloadingDetector to check for reload
> ## Invoke bulider.getConfiguration()
> ## Update the properties file
> ## Wait longer than refreshDelay
> ## Invoke builder.getReloadingController().checkForReloading(null) to notify
> the FileHandlerReloadingDetector to check for reload
> ## Invoke bulider.getConfiguration()
> * Result - For the first two invocations, the Configuration is not updated.
> One the third invocation of builder.getConfiguration() the property is
> updated to the new value.
>
> As potential solution, the constructor of FileHandlerReloadingDetector should
> either call isReloadingRequired() or
> updateLastModified(getLastModificationDate()) to initialize the lastModified
> instance variable to the file current lastModified value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-712) FileHandlerReloadingDetector Does Not Correctly Initialize File Last Modified
[
https://issues.apache.org/jira/browse/CONFIGURATION-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16616366#comment-16616366
]
Oliver Heger commented on CONFIGURATION-712:
Yes, this would be great. Many thanks in advance!
> FileHandlerReloadingDetector Does Not Correctly Initialize File Last Modified
> -
>
> Key: CONFIGURATION-712
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-712
> Project: Commons Configuration
> Issue Type: Bug
> Components: File reloading
>Affects Versions: 2.3
>Reporter: Rolland Hobbie
>Priority: Major
> Attachments: CONFIGURATION-712-InitializeLastModified.patch,
> ReloadingFileBasedConfigurationBuilderExampleTest.java,
> ReloadingFileBasedConfigurationBuilderTest.java
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> [FileHandlerReloadingDetector|https://commons.apache.org/proper/commons-configuration/apidocs/src-html/org/apache/commons/configuration2/reloading/FileHandlerReloadingDetector.html]
> declares the following method:
>
> {code:java}
> 150@Override
> 151public boolean isReloadingRequired()
> 152{
> 153long now = System.currentTimeMillis();
> 154if (now >= lastChecked + getRefreshDelay())
> 155{
> 156lastChecked = now;
> 157
> 158long modified = getLastModificationDate();
> 159if (modified > 0)
> 160{
> 161if (lastModified == 0)
> 162{
> 163// initialization
> 164updateLastModified(modified);
> 165}
> 166else
> 167{
> 168if (modified != lastModified)
> 169{
> 170return true;
> 171}
> 172}
> 173}
> 174}
> 175
> 176return false;
> 177}
> {code}
>
> During initialization of FileHandlerReloadingDetector, lastModified is never
> instantiated, so the first time isReloadingRequired() is invoked lastModified
> will be 0.
>
> This results in two issues:
>
> Test #1
> * Scenario Steps
> ## Initialize ReloadingFileBasedConfigurationBuilder without invoking
> builder.getConfiguration()
> ## Wait longer than refreshDelay
> ## Invoke builder.getReloadingController().checkForReloading(null) to notify
> the FileHandlerReloadingDetector to check for reload
> ## Invoke bulider.getConfiguration()
> ## Update the properties file
> ## Wait longer than refreshDelay
> ## Invoke builder.getReloadingController().checkForReloading(null) to notify
> the FileHandlerReloadingDetector to check for reload
> ## Invoke bulider.getConfiguration()
> * Result - the Configuration does not have the updated value.
>
> Test #2
> * Scenario Steps
> ## Initialize ReloadingFileBasedConfigurationBuilder without invoking
> builder.getConfiguration()
> ## Invoke bulider.getConfiguration()
> ## Update the properties file
> ## Wait longer than refreshDelay
> ## Invoke builder.getReloadingController().checkForReloading(null) to notify
> the FileHandlerReloadingDetector to check for reload
> ## Invoke bulider.getConfiguration()
> ## Update the properties file
> ## Wait longer than refreshDelay
> ## Invoke builder.getReloadingController().checkForReloading(null) to notify
> the FileHandlerReloadingDetector to check for reload
> ## Invoke bulider.getConfiguration()
> * Result - For the first two invocations, the Configuration is not updated.
> One the third invocation of builder.getConfiguration() the property is
> updated to the new value.
>
> As potential solution, the constructor of FileHandlerReloadingDetector should
> either call isReloadingRequired() or
> updateLastModified(getLastModificationDate()) to initialize the lastModified
> instance variable to the file current lastModified value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-712) FileHandlerReloadingDetector Does Not Correctly Initialize File Last Modified
[
https://issues.apache.org/jira/browse/CONFIGURATION-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16615222#comment-16615222
]
Oliver Heger commented on CONFIGURATION-712:
Thanks for the patch!
It looks good, and I also like the idea with the new refresh() method. The only
thing I am not sure about is the change on the isReloadingRequired() method. Is
this really necessary?
If I understand correctly, the changed method now expects that refresh() has
been called before. This would change the behavior for users that create an
instance of FileHandlerReloadingDetector directly without the factory. If the
method was not changed, it would now still work correctly with the updated
factory, wouldn't it?
> FileHandlerReloadingDetector Does Not Correctly Initialize File Last Modified
> -
>
> Key: CONFIGURATION-712
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-712
> Project: Commons Configuration
> Issue Type: Bug
> Components: File reloading
>Affects Versions: 2.3
>Reporter: Rolland Hobbie
>Priority: Major
> Attachments: CONFIGURATION-712-InitializeLastModified.patch,
> ReloadingFileBasedConfigurationBuilderExampleTest.java,
> ReloadingFileBasedConfigurationBuilderTest.java
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> [FileHandlerReloadingDetector|https://commons.apache.org/proper/commons-configuration/apidocs/src-html/org/apache/commons/configuration2/reloading/FileHandlerReloadingDetector.html]
> declares the following method:
>
> {code:java}
> 150@Override
> 151public boolean isReloadingRequired()
> 152{
> 153long now = System.currentTimeMillis();
> 154if (now >= lastChecked + getRefreshDelay())
> 155{
> 156lastChecked = now;
> 157
> 158long modified = getLastModificationDate();
> 159if (modified > 0)
> 160{
> 161if (lastModified == 0)
> 162{
> 163// initialization
> 164updateLastModified(modified);
> 165}
> 166else
> 167{
> 168if (modified != lastModified)
> 169{
> 170return true;
> 171}
> 172}
> 173}
> 174}
> 175
> 176return false;
> 177}
> {code}
>
> During initialization of FileHandlerReloadingDetector, lastModified is never
> instantiated, so the first time isReloadingRequired() is invoked lastModified
> will be 0.
>
> This results in two issues:
>
> Test #1
> * Scenario Steps
> ## Initialize ReloadingFileBasedConfigurationBuilder without invoking
> builder.getConfiguration()
> ## Wait longer than refreshDelay
> ## Invoke builder.getReloadingController().checkForReloading(null) to notify
> the FileHandlerReloadingDetector to check for reload
> ## Invoke bulider.getConfiguration()
> ## Update the properties file
> ## Wait longer than refreshDelay
> ## Invoke builder.getReloadingController().checkForReloading(null) to notify
> the FileHandlerReloadingDetector to check for reload
> ## Invoke bulider.getConfiguration()
> * Result - the Configuration does not have the updated value.
>
> Test #2
> * Scenario Steps
> ## Initialize ReloadingFileBasedConfigurationBuilder without invoking
> builder.getConfiguration()
> ## Invoke bulider.getConfiguration()
> ## Update the properties file
> ## Wait longer than refreshDelay
> ## Invoke builder.getReloadingController().checkForReloading(null) to notify
> the FileHandlerReloadingDetector to check for reload
> ## Invoke bulider.getConfiguration()
> ## Update the properties file
> ## Wait longer than refreshDelay
> ## Invoke builder.getReloadingController().checkForReloading(null) to notify
> the FileHandlerReloadingDetector to check for reload
> ## Invoke bulider.getConfiguration()
> * Result - For the first two invocations, the Configuration is not updated.
> One the third invocation of builder.getConfiguration() the property is
> updated to the new value.
>
> As potential solution, the constructor of FileHandlerReloadingDetector should
> either call isReloadingRequired() or
> updateLastModified(getLastModificationDate()) to initialize the lastModified
> instance variable to the file current lastModified value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CONFIGURATION-713) Add conversion to Regex patterns
[ https://issues.apache.org/jira/browse/CONFIGURATION-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-713. Resolution: Fixed Fix Version/s: 2.4 Patch applied in SVN revision 1840138. Many thanks! > Add conversion to Regex patterns > > > Key: CONFIGURATION-713 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-713 > Project: Commons Configuration > Issue Type: Improvement > Components: Type conversion >Reporter: Lars W >Priority: Major > Fix For: 2.4 > > Attachments: pattern.patch > > > Attached patch adds conversion to regex pattern from string to > PropertyConverter.java. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-712) FileHandlerReloadingDetector Does Not Correctly Initialize File Last Modified
[
https://issues.apache.org/jira/browse/CONFIGURATION-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16599653#comment-16599653
]
Oliver Heger commented on CONFIGURATION-712:
Letting {{DefaultReloadingDetectorFactory}} take care for the initialization of
the reloading detector is a good idea. We can change this. Do you want to
create a patch for this?
Also, if you have concrete suggestions how to improve documentation, please let
us know; this is highly appreciated.
> FileHandlerReloadingDetector Does Not Correctly Initialize File Last Modified
> -
>
> Key: CONFIGURATION-712
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-712
> Project: Commons Configuration
> Issue Type: Bug
> Components: File reloading
>Affects Versions: 2.3
>Reporter: Rolland Hobbie
>Priority: Major
> Attachments: ReloadingFileBasedConfigurationBuilderExampleTest.java,
> ReloadingFileBasedConfigurationBuilderTest.java
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> [FileHandlerReloadingDetector|https://commons.apache.org/proper/commons-configuration/apidocs/src-html/org/apache/commons/configuration2/reloading/FileHandlerReloadingDetector.html]
> declares the following method:
>
> {code:java}
> 150@Override
> 151public boolean isReloadingRequired()
> 152{
> 153long now = System.currentTimeMillis();
> 154if (now >= lastChecked + getRefreshDelay())
> 155{
> 156lastChecked = now;
> 157
> 158long modified = getLastModificationDate();
> 159if (modified > 0)
> 160{
> 161if (lastModified == 0)
> 162{
> 163// initialization
> 164updateLastModified(modified);
> 165}
> 166else
> 167{
> 168if (modified != lastModified)
> 169{
> 170return true;
> 171}
> 172}
> 173}
> 174}
> 175
> 176return false;
> 177}
> {code}
>
> During initialization of FileHandlerReloadingDetector, lastModified is never
> instantiated, so the first time isReloadingRequired() is invoked lastModified
> will be 0.
>
> This results in two issues:
>
> Test #1
> * Scenario Steps
> ## Initialize ReloadingFileBasedConfigurationBuilder without invoking
> builder.getConfiguration()
> ## Wait longer than refreshDelay
> ## Invoke builder.getReloadingController().checkForReloading(null) to notify
> the FileHandlerReloadingDetector to check for reload
> ## Invoke bulider.getConfiguration()
> ## Update the properties file
> ## Wait longer than refreshDelay
> ## Invoke builder.getReloadingController().checkForReloading(null) to notify
> the FileHandlerReloadingDetector to check for reload
> ## Invoke bulider.getConfiguration()
> * Result - the Configuration does not have the updated value.
>
> Test #2
> * Scenario Steps
> ## Initialize ReloadingFileBasedConfigurationBuilder without invoking
> builder.getConfiguration()
> ## Invoke bulider.getConfiguration()
> ## Update the properties file
> ## Wait longer than refreshDelay
> ## Invoke builder.getReloadingController().checkForReloading(null) to notify
> the FileHandlerReloadingDetector to check for reload
> ## Invoke bulider.getConfiguration()
> ## Update the properties file
> ## Wait longer than refreshDelay
> ## Invoke builder.getReloadingController().checkForReloading(null) to notify
> the FileHandlerReloadingDetector to check for reload
> ## Invoke bulider.getConfiguration()
> * Result - For the first two invocations, the Configuration is not updated.
> One the third invocation of builder.getConfiguration() the property is
> updated to the new value.
>
> As potential solution, the constructor of FileHandlerReloadingDetector should
> either call isReloadingRequired() or
> updateLastModified(getLastModificationDate()) to initialize the lastModified
> instance variable to the file current lastModified value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-712) FileHandlerReloadingDetector Does Not Correctly Initialize File Last Modified
[
https://issues.apache.org/jira/browse/CONFIGURATION-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16592692#comment-16592692
]
Oliver Heger commented on CONFIGURATION-712:
Thanks for this report.
I am not sure whether this is a bug, however, as the behavior is documented in
the class comment:
{color:#808080}* To initialize an instance either {{color}{color:#808080}@code
{color}{color:#808080}isReloadingRequired()} or
{color}{color:#808080}* {{color}{color:#808080}@code
{color}{color:#808080}reloadingPerformed()} can be called. The first call of
{color}{color:#808080}* {{color}{color:#808080}@code
{color}{color:#808080}isReloadingRequired} does not perform a check, but
obtains the initial
{color}{color:#808080}* modification date of the monitored file.
{{color}{color:#808080}@code {color}{color:#808080}reloadingPerformed()} always
{color}{color:#808080}* obtains the file's modification date and stores it
internally.
{color}
The correct initialization of the reloading detector is indeed tricky. The
solutions you describe are a bit problematic because they would require the
constructor to call non-final methods on this instance.
The assumption was that the behavior as implemented will probably not be an
issue in practice. Do you encounter a real problem in production or is this
only a theoretical observation?
> FileHandlerReloadingDetector Does Not Correctly Initialize File Last Modified
> -
>
> Key: CONFIGURATION-712
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-712
> Project: Commons Configuration
> Issue Type: Bug
> Components: File reloading
>Affects Versions: 2.3
>Reporter: Rolland Hobbie
>Priority: Major
> Attachments: ReloadingFileBasedConfigurationBuilderTest.java
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> [FileHandlerReloadingDetector|https://commons.apache.org/proper/commons-configuration/apidocs/src-html/org/apache/commons/configuration2/reloading/FileHandlerReloadingDetector.html]
> declares the following method:
>
> {code:java}
> 150@Override
> 151public boolean isReloadingRequired()
> 152{
> 153long now = System.currentTimeMillis();
> 154if (now >= lastChecked + getRefreshDelay())
> 155{
> 156lastChecked = now;
> 157
> 158long modified = getLastModificationDate();
> 159if (modified > 0)
> 160{
> 161if (lastModified == 0)
> 162{
> 163// initialization
> 164updateLastModified(modified);
> 165}
> 166else
> 167{
> 168if (modified != lastModified)
> 169{
> 170return true;
> 171}
> 172}
> 173}
> 174}
> 175
> 176return false;
> 177}
> {code}
>
> During initialization of FileHandlerReloadingDetector, lastModified is never
> instantiated, so the first time isReloadingRequired() is invoked lastModified
> will be 0.
>
> This results in two issues:
>
> Test #1
> * Scenario Steps
> ## Initialize ReloadingFileBasedConfigurationBuilder without invoking
> builder.getConfiguration()
> ## Wait longer than refreshDelay
> ## Invoke builder.getReloadingController().checkForReloading(null) to notify
> the FileHandlerReloadingDetector to check for reload
> ## Invoke bulider.getConfiguration()
> ## Update the properties file
> ## Wait longer than refreshDelay
> ## Invoke builder.getReloadingController().checkForReloading(null) to notify
> the FileHandlerReloadingDetector to check for reload
> ## Invoke bulider.getConfiguration()
> * Result - the Configuration does not have the updated value.
>
> Test #2
> * Scenario Steps
> ## Initialize ReloadingFileBasedConfigurationBuilder without invoking
> builder.getConfiguration()
> ## Invoke bulider.getConfiguration()
> ## Update the properties file
> ## Wait longer than refreshDelay
> ## Invoke builder.getReloadingController().checkForReloading(null) to notify
> the FileHandlerReloadingDetector to check for reload
> ## Invoke bulider.getConfiguration()
> ## Update the properties file
> ## Wait longer than refreshDelay
> ## Invoke builder.getReloadingController().checkForReloading(null) to notify
> the FileHandlerReloadingDetector to check for reload
> ## Invoke bulider.getConfiguration()
> * Result - For the first two invocations, the Configuration is not updated.
> One the third invocation of builder.getConfiguration() the property is
> updated to the new value.
>
> As potential solution, the constructor of FileHandlerReloadingDetector should
> either call isReloadingRequired()
[jira] [Commented] (TEXT-137) Add a URL string lookup
[ https://issues.apache.org/jira/browse/TEXT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16590725#comment-16590725 ] Oliver Heger commented on TEXT-137: --- I also feel a bit uneasy with the newly introduced lookup implementations. For instance, the script lookup - could this open up a number of security problems? > Add a URL string lookup > --- > > Key: TEXT-137 > URL: https://issues.apache.org/jira/browse/TEXT-137 > Project: Commons Text > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > > Add a simple URL string lookup to read the contents of a URL. This is _not_ a > full fledged HTTP client. > For example, using the HTTP scheme: > "UTF-8:[http://www.google.com|http://www.google.com/]"; > For example, using the file scheme: > "UTF-8:file:///C:/somehome/commons/commons-text/src/test/resources/document.properties" > The URL lookup key is "url" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LANG-1339) Some classes depend on the java.desktop profile
[
https://issues.apache.org/jira/browse/LANG-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16580328#comment-16580328
]
Oliver Heger commented on LANG-1339:
+1 to the suggestion of Gilles. Instantiate the {{observers}} list as a
{{CopyOnWriteArrayList}}, then we are thread-safe from the start.
> Some classes depend on the java.desktop profile
> ---
>
> Key: LANG-1339
> URL: https://issues.apache.org/jira/browse/LANG-1339
> Project: Commons Lang
> Issue Type: Task
>Reporter: Benedikt Ritter
>Priority: Major
> Labels: Java9
> Fix For: 3.8
>
>
> Commons Lang currently depends on java.desktop. This seems like an
> unnecessary heavy dependency for a library like Commons Lang. We need to find
> a way to fix this, without breaking bc. For more information see
> https://lists.apache.org/thread.html/8db8ec4aa1bdeae3d471ca4f46a21dc7da1a4c6933e1810238b72283@%3Cdev.commons.apache.org%3E
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CONFIGURATION-710) (doc) Fix typos in the user guides
[ https://issues.apache.org/jira/browse/CONFIGURATION-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-710. Resolution: Fixed Fix Version/s: 2.4 Pull request applied in SVN revision 1837979. Many thanks! > (doc) Fix typos in the user guides > -- > > Key: CONFIGURATION-710 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-710 > Project: Commons Configuration > Issue Type: Improvement > Components: Documentation >Affects Versions: 2.3 >Reporter: Oliver Heger >Priority: Major > Fix For: 2.4 > > > Wrapper ticket for PR on GitHub: > https://github.com/apache/commons-configuration/pull/12 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CONFIGURATION-710) (doc) Fix typos in the user guides
Oliver Heger created CONFIGURATION-710: -- Summary: (doc) Fix typos in the user guides Key: CONFIGURATION-710 URL: https://issues.apache.org/jira/browse/CONFIGURATION-710 Project: Commons Configuration Issue Type: Improvement Components: Documentation Affects Versions: 2.3 Reporter: Oliver Heger Wrapper ticket for PR on GitHub: https://github.com/apache/commons-configuration/pull/12 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COMPRESS-456) Missing OSGI Import-Package
[
https://issues.apache.org/jira/browse/COMPRESS-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517203#comment-16517203
]
Oliver Heger commented on COMPRESS-456:
---
Making all imports optional is not very OSGi-like, as some of them are for sure
required.
It is possible to define a number of package imports as optional and use the
'*' als fallback to automatically import all other referenced packages.
[Configuration] does this, which also has a number of optional dependencies. In
the __ section of the pom, there is the following declaration:
{code:xml}
org.apache.commons.beanutils.*;resolution:=optional,
org.apache.commons.codec.*;resolution:=optional,
org.apache.commons.jxpath.*;resolution:=optional,
org.apache.xml.resolver.*;resolution:=optional,
javax.servlet.*;resolution:=optional,
org.apache.commons.jexl2.*;resolution:=optional,
org.apache.commons.vfs2.*;resolution:=optional,
org.springframework.*;resolution:=optional,
com.fasterxml.jackson.*;resolution:=optional,
org.yaml.snakeyaml.*;resolution:=optional,
*
{code}
> Missing OSGI Import-Package
> ---
>
> Key: COMPRESS-456
> URL: https://issues.apache.org/jira/browse/COMPRESS-456
> Project: Commons Compress
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.17
>Reporter: Jérémie Brébec
>Priority: Major
> Fix For: 1.18
>
>
> The configuration of the maven-bundle-plugin overrides the
> directive : "*" is not present anymore, and severals packages do not resolve
> correctly.
> For example, "javax.crypto", which is used by 7z encryption, is not resolved
> and using this feature fails with a ClassNotFoundException on
> javax.crypto.SecretKey.
> ahma I think that the correct Import-Package directive should be :
> {code:java}
> *;resolution:=optional{code}
> this directive will import everything commons-compress depends on, but with
> an optional resolution (and so every dependencies will be optionals)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-703) xml:space="preserve" does not handle blank strings properly
[
https://issues.apache.org/jira/browse/CONFIGURATION-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16507495#comment-16507495
]
Oliver Heger commented on CONFIGURATION-703:
Added.
> xml:space="preserve" does not handle blank strings properly
> ---
>
> Key: CONFIGURATION-703
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-703
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Pascal Essiembre
>Priority: Major
> Fix For: 2.3
>
>
> When using XMLConfiguration 2, tags containing only white spaces are not
> handled properly when xml:space="preserve" is set. 'null' is returned
> instead of the actual spaces. To reproduce:
>
> {code:java}
> XMLConfiguration xml = new BasicConfigurationBuilder<>(
> XMLConfiguration.class).configure(
> new Parameters().xml()).getConfiguration();
> FileHandler fh = new FileHandler(xml);
> fh.load(new StringReader(""));
> System.out.println("TEST: '" + xml.getString("") + "'");
> // Outputs -> TEST: 'null'
> // Should be -> TEST: ''
> {code}
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CONFIGURATION-703) xml:space="preserve" does not handle blank strings properly
[
https://issues.apache.org/jira/browse/CONFIGURATION-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-703.
Resolution: Fixed
Fix Version/s: 2.3
The patch was applied (with minor tweaks) in SVN revision 1833251. Many thanks
again.
If you want to be listed in the contributors section of pom.xml, please send us
the data you want to have added.
> xml:space="preserve" does not handle blank strings properly
> ---
>
> Key: CONFIGURATION-703
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-703
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Pascal Essiembre
>Priority: Major
> Fix For: 2.3
>
>
> When using XMLConfiguration 2, tags containing only white spaces are not
> handled properly when xml:space="preserve" is set. 'null' is returned
> instead of the actual spaces. To reproduce:
>
> {code:java}
> XMLConfiguration xml = new BasicConfigurationBuilder<>(
> XMLConfiguration.class).configure(
> new Parameters().xml()).getConfiguration();
> FileHandler fh = new FileHandler(xml);
> fh.load(new StringReader(""));
> System.out.println("TEST: '" + xml.getString("") + "'");
> // Outputs -> TEST: 'null'
> // Should be -> TEST: ''
> {code}
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-703) xml:space="preserve" does not handle blank strings properly
[
https://issues.apache.org/jira/browse/CONFIGURATION-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16505172#comment-16505172
]
Oliver Heger commented on CONFIGURATION-703:
Many thanks! I will have a look in a few days.
> xml:space="preserve" does not handle blank strings properly
> ---
>
> Key: CONFIGURATION-703
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-703
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Pascal Essiembre
>Priority: Major
>
> When using XMLConfiguration 2, tags containing only white spaces are not
> handled properly when xml:space="preserve" is set. 'null' is returned
> instead of the actual spaces. To reproduce:
>
> {code:java}
> XMLConfiguration xml = new BasicConfigurationBuilder<>(
> XMLConfiguration.class).configure(
> new Parameters().xml()).getConfiguration();
> FileHandler fh = new FileHandler(xml);
> fh.load(new StringReader(""));
> System.out.println("TEST: '" + xml.getString("") + "'");
> // Outputs -> TEST: 'null'
> // Should be -> TEST: ''
> {code}
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-703) xml:space="preserve" does not handle blank strings properly
[
https://issues.apache.org/jira/browse/CONFIGURATION-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16503784#comment-16503784
]
Oliver Heger commented on CONFIGURATION-703:
Yes, I agree - and I think this is mostly in-line with the current
implementation in {{XMLConfiguration}} except for the issues with whitespace
preserving. So if you could create a patch that goes in this direction, this
will be highly appreciated.
> xml:space="preserve" does not handle blank strings properly
> ---
>
> Key: CONFIGURATION-703
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-703
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Pascal Essiembre
>Priority: Major
>
> When using XMLConfiguration 2, tags containing only white spaces are not
> handled properly when xml:space="preserve" is set. 'null' is returned
> instead of the actual spaces. To reproduce:
>
> {code:java}
> XMLConfiguration xml = new BasicConfigurationBuilder<>(
> XMLConfiguration.class).configure(
> new Parameters().xml()).getConfiguration();
> FileHandler fh = new FileHandler(xml);
> fh.load(new StringReader(""));
> System.out.println("TEST: '" + xml.getString("") + "'");
> // Outputs -> TEST: 'null'
> // Should be -> TEST: ''
> {code}
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-704) an option to override property key instead of creation of lists
[
https://issues.apache.org/jira/browse/CONFIGURATION-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16502410#comment-16502410
]
Oliver Heger commented on CONFIGURATION-704:
I see. Well, I am not too excited about the include mechanism for properties
files because it is a special implementation for {{PropertiesConfiguration}}
and is normally less powerful than combined configurations. Therefore, I am a
bit reluctant to adding new features in this area.
You make a valid point that it is easier to use the include mechanism in a
dynamic way. In theory you can achieve the same with combined configurations by
constructing the XML definition the combined configuration is based on
manually. But this is admittedly cumbersome. I would like to simplify this by
adding a kind of builder that allows creating such definitions using a
convenient API. This could also support use cases like _add all configuration
sources located in the /conf director_y. Would this be an option?
That said, if you want to provide a patch for the include mechanism and the
required changes are not too complex, I am happy to review it.
> an option to override property key instead of creation of lists
> ---
>
> Key: CONFIGURATION-704
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-704
> Project: Commons Configuration
> Issue Type: New Feature
>Affects Versions: 2.2
>Reporter: Dan Alon
>Priority: Major
>
> Hi,
>
> I want an option when loading a properties file from the include
> functionality (or in the same file) to disable the list feature that when
> entering the same key it creates a list instead of override the old value.
> for example when entering these properties:
> colors.pie = #FF
> colors.pie = #00FF00
> colors.pie = #FF
> instead of creating a string with seperator like this colors.pie
> =#FF,#00FF00,#FF
>
> i want only the last value colors.pie = #FF
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-703) xml:space="preserve" does not handle blank strings properly
[
https://issues.apache.org/jira/browse/CONFIGURATION-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16502381#comment-16502381
]
Oliver Heger commented on CONFIGURATION-703:
Thanks for looking this up.
However, I am still not sure how to interpret this in the context of Commons
Configuration where the focus lies in providing access to configuration data
and not necessarily exact XML processing. I don't think that it is a frequent
use case to define configuration properties with whitespace in all possible
variations. So if we can comply to the specs with reasonable effort (and do not
break existing code), this is great. But IMHO it is more important to be
consistent in our own API, and we do not have to support every corner case
mentioned in the specs.
> xml:space="preserve" does not handle blank strings properly
> ---
>
> Key: CONFIGURATION-703
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-703
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Pascal Essiembre
>Priority: Major
>
> When using XMLConfiguration 2, tags containing only white spaces are not
> handled properly when xml:space="preserve" is set. 'null' is returned
> instead of the actual spaces. To reproduce:
>
> {code:java}
> XMLConfiguration xml = new BasicConfigurationBuilder<>(
> XMLConfiguration.class).configure(
> new Parameters().xml()).getConfiguration();
> FileHandler fh = new FileHandler(xml);
> fh.load(new StringReader(""));
> System.out.println("TEST: '" + xml.getString("") + "'");
> // Outputs -> TEST: 'null'
> // Should be -> TEST: ''
> {code}
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-703) xml:space="preserve" does not handle blank strings properly
[
https://issues.apache.org/jira/browse/CONFIGURATION-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16500824#comment-16500824
]
Oliver Heger commented on CONFIGURATION-703:
Yes, it would be better if this was handled in a consistent way, and I am a bit
worried that this does not seem to be the case. I remember that already for
Configuration 1.0 there was a change so that one can find out whether there is
an empty element or no element at all, such as . I think if such an
element is present, a query for its value will not return *null*, but an empty
string.
> xml:space="preserve" does not handle blank strings properly
> ---
>
> Key: CONFIGURATION-703
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-703
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Pascal Essiembre
>Priority: Major
>
> When using XMLConfiguration 2, tags containing only white spaces are not
> handled properly when xml:space="preserve" is set. 'null' is returned
> instead of the actual spaces. To reproduce:
>
> {code:java}
> XMLConfiguration xml = new BasicConfigurationBuilder<>(
> XMLConfiguration.class).configure(
> new Parameters().xml()).getConfiguration();
> FileHandler fh = new FileHandler(xml);
> fh.load(new StringReader(""));
> System.out.println("TEST: '" + xml.getString("") + "'");
> // Outputs -> TEST: 'null'
> // Should be -> TEST: ''
> {code}
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-704) an option to override property key instead of creation of lists
[ https://issues.apache.org/jira/browse/CONFIGURATION-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16499538#comment-16499538 ] Oliver Heger commented on CONFIGURATION-704: I think your use case is already supported by [CombinedConfiguration|[http://commons.apache.org/proper/commons-configuration/userguide/howto_combinedconfiguration.html#Combined_Configuration].] Rather than using includes in properties files, you define a configuration definition file that lists a number of configuration sources. You can define union or override semantics for the sources to be included. Please have a look and tell us whether this fits your needs. > an option to override property key instead of creation of lists > --- > > Key: CONFIGURATION-704 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-704 > Project: Commons Configuration > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Dan Alon >Priority: Major > > Hi, > > I want an option when loading a properties file from the include > functionality (or in the same file) to disable the list feature that when > entering the same key it creates a list instead of override the old value. > for example when entering these properties: > colors.pie = #FF > colors.pie = #00FF00 > colors.pie = #FF > instead of creating a string with seperator like this colors.pie > =#FF,#00FF00,#FF > > i want only the last value colors.pie = #FF -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-703) xml:space="preserve" does not handle blank strings properly
[
https://issues.apache.org/jira/browse/CONFIGURATION-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16498390#comment-16498390
]
Oliver Heger commented on CONFIGURATION-703:
To be honest, I do not remember why it has been implemented this way. What you
say sounds logic, and I also do not see a reason why an element with attributes
should not be able to preserve its spaces. How do the tests react when this is
changed?
> xml:space="preserve" does not handle blank strings properly
> ---
>
> Key: CONFIGURATION-703
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-703
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Pascal Essiembre
>Priority: Major
>
> When using XMLConfiguration 2, tags containing only white spaces are not
> handled properly when xml:space="preserve" is set. 'null' is returned
> instead of the actual spaces. To reproduce:
>
> {code:java}
> XMLConfiguration xml = new BasicConfigurationBuilder<>(
> XMLConfiguration.class).configure(
> new Parameters().xml()).getConfiguration();
> FileHandler fh = new FileHandler(xml);
> fh.load(new StringReader(""));
> System.out.println("TEST: '" + xml.getString("") + "'");
> // Outputs -> TEST: 'null'
> // Should be -> TEST: ''
> {code}
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-704) an option to override property key instead of creation of lists
[ https://issues.apache.org/jira/browse/CONFIGURATION-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16496695#comment-16496695 ] Oliver Heger commented on CONFIGURATION-704: Not sure whether I fully understand this request. When should this new feature be used: when writing a configuration file or when querying a property? Can you give some example (pseudo) code how you would like to use it? > an option to override property key instead of creation of lists > --- > > Key: CONFIGURATION-704 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-704 > Project: Commons Configuration > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Dan Alon >Priority: Major > > Hi, > > I want an option when loading a properties file from the include > functionality (or in the same file) to disable the list feature that when > entering the same key it creates a list instead of override the old value. > for example when entering these properties: > colors.pie = #FF > colors.pie = #00FF00 > colors.pie = #FF > instead of creating a string with seperator like this colors.pie > =#FF,#00FF00,#FF > > i want only the last value colors.pie = #FF -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-703) xml:space="preserve" does not handle blank strings properly
[
https://issues.apache.org/jira/browse/CONFIGURATION-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16496692#comment-16496692
]
Oliver Heger commented on CONFIGURATION-703:
Yes, this looks good. So the actual bug was that an element was considered to
have children if it had at least one 'real' attribute, but in this case the
attributes related to whitespace management were counted.
> xml:space="preserve" does not handle blank strings properly
> ---
>
> Key: CONFIGURATION-703
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-703
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Pascal Essiembre
>Priority: Major
>
> When using XMLConfiguration 2, tags containing only white spaces are not
> handled properly when xml:space="preserve" is set. 'null' is returned
> instead of the actual spaces. To reproduce:
>
> {code:java}
> XMLConfiguration xml = new BasicConfigurationBuilder<>(
> XMLConfiguration.class).configure(
> new Parameters().xml()).getConfiguration();
> FileHandler fh = new FileHandler(xml);
> fh.load(new StringReader(""));
> System.out.println("TEST: '" + xml.getString("") + "'");
> // Outputs -> TEST: 'null'
> // Should be -> TEST: ''
> {code}
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-703) xml:space="preserve" does not handle blank strings properly
[
https://issues.apache.org/jira/browse/CONFIGURATION-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16492082#comment-16492082
]
Oliver Heger commented on CONFIGURATION-703:
Oh, found the reason: The _determineValue()_ method in {{XMLConfiguration}}
handles elements that have only whitespace as content in a special way. Space
is only preserved if the element has some other text content rather than
exclusively whitespace. This was obviously implemented this way to not change
behavior and break existing code. This is of course still a problem.
> xml:space="preserve" does not handle blank strings properly
> ---
>
> Key: CONFIGURATION-703
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-703
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Pascal Essiembre
>Priority: Major
>
> When using XMLConfiguration 2, tags containing only white spaces are not
> handled properly when xml:space="preserve" is set. 'null' is returned
> instead of the actual spaces. To reproduce:
>
> {code:java}
> XMLConfiguration xml = new BasicConfigurationBuilder<>(
> XMLConfiguration.class).configure(
> new Parameters().xml()).getConfiguration();
> FileHandler fh = new FileHandler(xml);
> fh.load(new StringReader(""));
> System.out.println("TEST: '" + xml.getString("") + "'");
> // Outputs -> TEST: 'null'
> // Should be -> TEST: ''
> {code}
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-703) xml:space="preserve" does not handle blank strings properly
[
https://issues.apache.org/jira/browse/CONFIGURATION-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16492075#comment-16492075
]
Oliver Heger commented on CONFIGURATION-703:
Yes, it should. What confuses me is that we have a test exactly for this use
case: _TestXMLConfiguration.testPreserveSpaceOnElement()_. This test has been
introduced for a similar report:
[CONFIGURATION-555|https://issues.apache.org/jira/browse/CONFIGURATION-555].
Not sure why this now pops up again. Maybe the solution implemented then was
not complete.
> xml:space="preserve" does not handle blank strings properly
> ---
>
> Key: CONFIGURATION-703
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-703
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Pascal Essiembre
>Priority: Major
>
> When using XMLConfiguration 2, tags containing only white spaces are not
> handled properly when xml:space="preserve" is set. 'null' is returned
> instead of the actual spaces. To reproduce:
>
> {code:java}
> XMLConfiguration xml = new BasicConfigurationBuilder<>(
> XMLConfiguration.class).configure(
> new Parameters().xml()).getConfiguration();
> FileHandler fh = new FileHandler(xml);
> fh.load(new StringReader(""));
> System.out.println("TEST: '" + xml.getString("") + "'");
> // Outputs -> TEST: 'null'
> // Should be -> TEST: ''
> {code}
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-703) xml:space="preserve" does not handle blank strings properly
[
https://issues.apache.org/jira/browse/CONFIGURATION-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16491674#comment-16491674
]
Oliver Heger commented on CONFIGURATION-703:
Thanks for this report.
>From the unit tests of {{XMLConfiguration}} I expect that the handling of the
>of the _xml:space_ attribute should work in principle. Your case is somewhat
>special as it applies this attribute to the rool element and does not have any
>other elements in the XML document. So the problem could be specific to this
>constellation.
Did you test with other documents containing multiple elements? (Just to rule
out that there is a general problem.)
After applying your fix, do the unit tests still pass?
> xml:space="preserve" does not handle blank strings properly
> ---
>
> Key: CONFIGURATION-703
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-703
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Pascal Essiembre
>Priority: Major
>
> When using XMLConfiguration 2, tags containing only white spaces are not
> handled properly when xml:space="preserve" is set. 'null' is returned
> instead of the actual spaces. To reproduce:
>
> {code:java}
> XMLConfiguration xml = new BasicConfigurationBuilder<>(
> XMLConfiguration.class).configure(
> new Parameters().xml()).getConfiguration();
> FileHandler fh = new FileHandler(xml);
> fh.load(new StringReader(""));
> System.out.println("TEST: '" + xml.getString("") + "'");
> // Outputs -> TEST: 'null'
> // Should be -> TEST: ''
> {code}
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CONFIGURATION-701) Add support to CompositeConfiguration to allow Configurations to be prepend to the LinkedList
[ https://issues.apache.org/jira/browse/CONFIGURATION-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-701. Resolution: Fixed Fix Version/s: 2.3 Patch applied in SVN revision 1831807. Many thanks again. If you want to be added to the contributors section in pom.xml, please send us the data you want to have included. > Add support to CompositeConfiguration to allow Configurations to be prepend > to the LinkedList > - > > Key: CONFIGURATION-701 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-701 > Project: Commons Configuration > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Nicholas Verbeck >Priority: Minor > Fix For: 2.3 > > Attachments: CONFIGURATION-701.patch, CONFIGURATION-701.patch > > > Create methods like addFirstConfiguration with similar signatures as > addConfiguration but instead of appending them to the LinkedList add them to > the start of the list. This would allow for support of inserting new override > configs post initial construction without needing to rebuild a new > CompositeConfiguration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-701) Add support to CompositeConfiguration to allow Configurations to be prepend to the LinkedList
[
https://issues.apache.org/jira/browse/CONFIGURATION-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479601#comment-16479601
]
Oliver Heger commented on CONFIGURATION-701:
Patch looks good to me. I have the following minor nits:
* The @since tag on the new method should be for version 2.3.
* It is probably not necessary to change the type of the _configList_ field
from _List_ to _LinkedList_. To add an element at the beginning, just use
{{[add|https://docs.oracle.com/javase/8/docs/api/java/util/List.html#add-int-E-](int
index, [E|https://docs.oracle.com/javase/8/docs/api/java/util/List.html]
element). }}I think that _LinkedList_ will handle this efficiently.
When this is done, I am happy to apply the patch.
> Add support to CompositeConfiguration to allow Configurations to be prepend
> to the LinkedList
> -
>
> Key: CONFIGURATION-701
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-701
> Project: Commons Configuration
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Nicholas Verbeck
>Priority: Minor
> Attachments: CONFIGURATION-701.patch
>
>
> Create methods like addFirstConfiguration with similar signatures as
> addConfiguration but instead of appending them to the LinkedList add them to
> the start of the list. This would allow for support of inserting new override
> configs post initial construction without needing to rebuild a new
> CompositeConfiguration.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-701) Add support to CompositeConfiguration to allow Configurations to be prepend to the LinkedList
[ https://issues.apache.org/jira/browse/CONFIGURATION-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16474744#comment-16474744 ] Oliver Heger commented on CONFIGURATION-701: Many thanks for the patch. I will have a look (probably in a few days). > Add support to CompositeConfiguration to allow Configurations to be prepend > to the LinkedList > - > > Key: CONFIGURATION-701 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-701 > Project: Commons Configuration > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Nicholas Verbeck >Priority: Minor > Attachments: CONFIGURATION-701.patch > > > Create methods like addFirstConfiguration with similar signatures as > addConfiguration but instead of appending them to the LinkedList add them to > the start of the list. This would allow for support of inserting new override > configs post initial construction without needing to rebuild a new > CompositeConfiguration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-701) Add support to CompositeConfiguration to allow Configurations to be prepend to the LinkedList
[ https://issues.apache.org/jira/browse/CONFIGURATION-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16473513#comment-16473513 ] Oliver Heger commented on CONFIGURATION-701: Yes, this could be useful for some use cases. Patches welcome (ideally with unit tests). > Add support to CompositeConfiguration to allow Configurations to be prepend > to the LinkedList > - > > Key: CONFIGURATION-701 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-701 > Project: Commons Configuration > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Nicholas Verbeck >Priority: Minor > > Create methods like addFirstConfiguration with similar signatures as > addConfiguration but instead of appending them to the LinkedList add them to > the start of the list. This would allow for support of inserting new override > configs post initial construction without needing to rebuild a new > CompositeConfiguration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CONFIGURATION-687) Memory leak and related issues with CombinedConfigurationBuilder
[ https://issues.apache.org/jira/browse/CONFIGURATION-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-687. Resolution: Fixed Fix Version/s: 2.3 This was indeed a major problem. Many thanks for spotting it. A fix was committed in SVN revision 1831360. The builders for child configurations are now created only once. The trouble with unnecessary reloading operations should be solved by this fix as well. Could you please double-check? > Memory leak and related issues with CombinedConfigurationBuilder > > > Key: CONFIGURATION-687 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-687 > Project: Commons Configuration > Issue Type: Bug > Components: File reloading >Affects Versions: 2.2 >Reporter: Luke Hamaty >Priority: Major > Fix For: 2.3 > > Attachments: ReloadCombinedBug.zip > > > In CombinedConfigurationBuilder, each call to resetResult() adds new builders > to the list of child builders. Likewise, and likely for the same reason, for > ReloadingCombinedConfigurationBuilder, the resetResult() call adds to the > list of subcontrollers. > When resetResult() is called because of an reload update, the next _n_ calls > to getReloadingController().checkForReloading() will also initiate reloading, > causing a reset and increasing the number of subcontrollers. So the first > change causes 1 reload, the second change causes 2 reloads, and it doubles > each time, so the 7th touch leads to 128 reloads! > Functionally, there are no apparent symptoms until memory exhaustion and/or > thrashing occur. > This seems to be happen because > CombinedConfigurationBuilder.initResultInstance rebuilds from the parameters > without clearing all of the existing state, particularly _sourceData_, so > SourceData ends up adding the reconstructed builders on top of the existing > ones. Correcting this could be as simple as cleaning up and clearing > sourceData to force creation of new SourceData. > Code in attached zip (maven project) demonstrates the issue. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-700) Issue With backslash(\) and Forwardslash(/)
[ https://issues.apache.org/jira/browse/CONFIGURATION-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16469021#comment-16469021 ] Oliver Heger commented on CONFIGURATION-700: I am not sure whether anything can be done about the backslash. When the properties file is written with Commons Configuration it of course produces a syntactically correct output; and according to the specification (see the Javadoc link I posted before), a backslash has to be escaped. The library is fault tolerant to read the actually invalid input file, but it cannot be forced to generate invalid output. > Issue With backslash(\) and Forwardslash(/) > --- > > Key: CONFIGURATION-700 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-700 > Project: Commons Configuration > Issue Type: Bug > Components: Build >Affects Versions: 1.10 >Reporter: Amitabh Pandey >Priority: Major > Fix For: 1.10 > > Attachments: 1.jpg > > > Dear Team, > I am using commons-configuration-1.10.jar for updating property file in java. > I have achieve all my requirement(Preserve comment, White space) with this > API.But stuck at one point.It is not working as per my expectations with > slash.Below is one example. > I have below url in my properties file. > *C\:ABC.net/wsdl* > Now it is getting change to below after modification > *C:ABC.net\/wsdl* > Means it is removing the backslash and changing forwardslash to \/.I know it > is escaping character. But is there any way to prevent this. I cant not > change any thing in property file. I have to handle through code only. > Because of only this issue I again moved to Java util API. > Please check fix of this. Rest is excellent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-700) Issue With backslash(\) and Forwardslash(/)
[ https://issues.apache.org/jira/browse/CONFIGURATION-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16467910#comment-16467910 ] Oliver Heger commented on CONFIGURATION-700: Regarding the backslash: This is a limitation of Java properties files. Commons Configuration behaves here in the same way as [Properties.load()|[https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.Reader-|https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.Reader-.]]. Please have a look at the Javadocs of this method. Basically, you have to duplicate the backslash in order to correctly escape it. Regarding the slash: I remeber that older versions of Commons Configuration had issues with the handling of slashes and escapes. You did not show the code how the properties file was manipulated. As it is unlikely that there will be another release of the Configuration 1.x series, I can only recommend to upgrade to the most recent 2.x version. However, this version is not API-compatible with Configuration 1.10; so you will have to adapt your code. Refer to [this guide|http://commons.apache.org/proper/commons-configuration/userguide/upgradeto2_0.html]. > Issue With backslash(\) and Forwardslash(/) > --- > > Key: CONFIGURATION-700 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-700 > Project: Commons Configuration > Issue Type: Bug > Components: Build >Affects Versions: 1.10 >Reporter: Amitabh Pandey >Priority: Major > Fix For: 1.10 > > > Dear Team, > I am using commons-configuration-1.10.jar for updating property file in java. > I have achieve all my requirement(Preserve comment, White space) with this > API.But stuck at one point.It is not working as per my expectations with > slash.Below is one example. > I have below url in my properties file. > *C\:ABC.net/wsdl* > Now it is getting change to below after modification > *C:ABC.net\/wsdl* > Means it is removing the backslash and changing forwardslash to \/.I know it > is escaping character. But is there any way to prevent this. I cant not > change any thing in property file. I have to handle through code only. > Because of only this issue I again moved to Java util API. > Please check fix of this. Rest is excellent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CONFIGURATION-699) HierarchicalConfiguration childConfigurationsAt(String key) method not throws exception if key is not found in XML file
[
https://issues.apache.org/jira/browse/CONFIGURATION-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger closed CONFIGURATION-699.
--
> HierarchicalConfiguration childConfigurationsAt(String key) method not throws
> exception if key is not found in XML file
> ---
>
> Key: CONFIGURATION-699
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-699
> Project: Commons Configuration
> Issue Type: Bug
>Reporter: Pavel Gavrilov
>Priority: Major
>
> {code:java}
> List> hierarchicalConfigurations =
> configuration.childConfigurationsAt("key");
> {code}
> will return empty list if "key" is not in xml file, but
> {code:java}
> HierarchicalConfiguration nodeHierarchicalConfiguration =
> configuration.configurationAt("key");
> {code}
> will throw ConfigurationRuntimeException.
> So if you don't get an exception, you may think that there is not nodes under
> "key" (, but actually xml file not contains "key" (is not valid). To avoid it
> you have to call in try/catch
> {code:java}
> configuration.configurationAt("key"){code}
> first, that may produce an exception and then use
> {code:java}
> configuration.childConfigurationsAt("key");{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CONFIGURATION-699) HierarchicalConfiguration childConfigurationsAt(String key) method not throws exception if key is not found in XML file
[
https://issues.apache.org/jira/browse/CONFIGURATION-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-699.
Resolution: Won't Fix
Closing as requested by the reporter.
> HierarchicalConfiguration childConfigurationsAt(String key) method not throws
> exception if key is not found in XML file
> ---
>
> Key: CONFIGURATION-699
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-699
> Project: Commons Configuration
> Issue Type: Bug
>Reporter: Pavel Gavrilov
>Priority: Major
>
> {code:java}
> List> hierarchicalConfigurations =
> configuration.childConfigurationsAt("key");
> {code}
> will return empty list if "key" is not in xml file, but
> {code:java}
> HierarchicalConfiguration nodeHierarchicalConfiguration =
> configuration.configurationAt("key");
> {code}
> will throw ConfigurationRuntimeException.
> So if you don't get an exception, you may think that there is not nodes under
> "key" (, but actually xml file not contains "key" (is not valid). To avoid it
> you have to call in try/catch
> {code:java}
> configuration.configurationAt("key"){code}
> first, that may produce an exception and then use
> {code:java}
> configuration.childConfigurationsAt("key");{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-699) HierarchicalConfiguration childConfigurationsAt(String key) method not throws exception if key is not found in XML file
[
https://issues.apache.org/jira/browse/CONFIGURATION-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452944#comment-16452944
]
Oliver Heger commented on CONFIGURATION-699:
I am not sure I fully understand your point. Both methods work as they are
designed and are documented in their Javadocs; so this is not a bug.
The reason why _configurationAt()_ throws an exception and _configurationsAt()_
does not is that for the former you have to select exactly one configuration
node; otherwise, no sub configuration can be created. So there are not many
other options than failing. For _configurationsAt()_, which returns a List, the
number of elements in the result list corresponds to the number of selected
nodes. So you can easily find out if nodes have been retrieved. I do not get
what you mean by XML file not valid.
I would not want to change this. For some use cases it may be desirable to
receive an empty list, e.g. if configuration properties are optional. Also, a
change of the behavior of this method would break existing code.
> HierarchicalConfiguration childConfigurationsAt(String key) method not throws
> exception if key is not found in XML file
> ---
>
> Key: CONFIGURATION-699
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-699
> Project: Commons Configuration
> Issue Type: Bug
>Reporter: Pavel Gavrilov
>Priority: Major
>
> {code:java}
> List> hierarchicalConfigurations =
> configuration.childConfigurationsAt("key");
> {code}
> will return empty list if "key" is not in xml file, but
> {code:java}
> HierarchicalConfiguration nodeHierarchicalConfiguration =
> configuration.configurationAt("key");
> {code}
> will throw ConfigurationRuntimeException.
> So if you don't get an exception, you may think that there is not nodes under
> "key" (, but actually xml file not contains "key" (is not valid). To avoid it
> you have to call in try/catch
> {code:java}
> configuration.configurationAt("key"){code}
> first, that may produce an exception and then use
> {code:java}
> configuration.childConfigurationsAt("key");{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-652) FileHandler does not produce root node attributes for XMLConfiguration
[ https://issues.apache.org/jira/browse/CONFIGURATION-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16435821#comment-16435821 ] Oliver Heger commented on CONFIGURATION-652: Done. Thanks again. > FileHandler does not produce root node attributes for XMLConfiguration > > > Key: CONFIGURATION-652 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-652 > Project: Commons Configuration > Issue Type: Bug > Components: Interpolation >Affects Versions: 2.1.1, 2.2 > Environment: Java 8 on Linux >Reporter: Claude Warren >Priority: Major > Labels: namespace, xml > Fix For: 2.3 > > Attachments: Test.java, configuration-652.patch, > testChildNamespace.xml, testRootNamespace.xml > > > I have a case where I need to take a Configuration file and write it as an > XML document. The document should have one or more xmlns properties on the > root node but the xmlns attributes are not output. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CONFIGURATION-652) FileHandler does not produce root node attributes for XMLConfiguration
[ https://issues.apache.org/jira/browse/CONFIGURATION-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-652. Resolution: Fixed Fix Version/s: 2.3 Patch applied in SVN in revision 1828908. Many thanks again. If you want to be added to the contributors section in the pom, please send your personal data that should be included. > FileHandler does not produce root node attributes for XMLConfiguration > > > Key: CONFIGURATION-652 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-652 > Project: Commons Configuration > Issue Type: Bug > Components: Interpolation >Affects Versions: 2.1.1, 2.2 > Environment: Java 8 on Linux >Reporter: Claude Warren >Priority: Major > Labels: namespace, xml > Fix For: 2.3 > > Attachments: Test.java, configuration-652.patch, > testChildNamespace.xml, testRootNamespace.xml > > > I have a case where I need to take a Configuration file and write it as an > XML document. The document should have one or more xmlns properties on the > root node but the xmlns attributes are not output. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-652) FileHandler does not produce root node attributes for XMLConfiguration
[ https://issues.apache.org/jira/browse/CONFIGURATION-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432761#comment-16432761 ] Oliver Heger commented on CONFIGURATION-652: Many thanks for the patch! I applied it, but still get two failing test cases: _testLoadWithRootNamespace_, and _testLoadChildNamespace_. Could it be that the test configuration files _testRootNamespace.xml_ and _testChildNamespace.xml_ are missing from the patch? > FileHandler does not produce root node attributes for XMLConfiguration > > > Key: CONFIGURATION-652 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-652 > Project: Commons Configuration > Issue Type: Bug > Components: Interpolation >Affects Versions: 2.1.1, 2.2 > Environment: Java 8 on Linux >Reporter: Claude Warren >Priority: Major > Labels: namespace, xml > Attachments: Test.java, configuration-652.patch > > > I have a case where I need to take a Configuration file and write it as an > XML document. The document should have one or more xmlns properties on the > root node but the xmlns attributes are not output. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CONFIGURATION-693) Conversion to File is missing
[ https://issues.apache.org/jira/browse/CONFIGURATION-693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-693. Resolution: Fixed Fix Version/s: 2.3 Patch applied in SVN revision 1827942. Many thanks again. If you want to be added to the contributors section in the pom, please post the data you want to have included. > Conversion to File is missing > - > > Key: CONFIGURATION-693 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-693 > Project: Commons Configuration > Issue Type: Improvement > Components: Type conversion >Affects Versions: 2.2 >Reporter: Lars W >Priority: Major > Fix For: 2.3 > > Attachments: Converter.patch.txt, Converter.patch.txt > > > PropertyConverter.java misses type conversion to File although a string could > be easily converted to a File. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-693) Conversion to File is missing
[
https://issues.apache.org/jira/browse/CONFIGURATION-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16413971#comment-16413971
]
Oliver Heger commented on CONFIGURATION-693:
Great, many thanks!
Just one thing: Do you think it makes sense to implement one of the methods
_toFile()_ or _toPath()_ in terms of the other one? So for instance, _toFile()_
could be implemented as
{code:java}
public static File toFile(Object value) throws ConversionException
{
return toPath(value).toFile();
}{code}
(Maybe with some tweaking of the exception message in case a
ConversionException occurs.) This would reduce the amount of code and some
redundancy. Or are there reasons against this?
> Conversion to File is missing
> -
>
> Key: CONFIGURATION-693
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-693
> Project: Commons Configuration
> Issue Type: Improvement
> Components: Type conversion
>Affects Versions: 2.2
>Reporter: Lars W
>Priority: Major
> Attachments: Converter.patch.txt, Converter.patch.txt
>
>
> PropertyConverter.java misses type conversion to File although a string could
> be easily converted to a File.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CONFIGURATION-692) Preserve ConversionException cause
[ https://issues.apache.org/jira/browse/CONFIGURATION-692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-692. Resolution: Fixed Fix Version/s: 2.3 Fixed in SVN in revision 1827668. Many thanks for the report! > Preserve ConversionException cause > -- > > Key: CONFIGURATION-692 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-692 > Project: Commons Configuration > Issue Type: Improvement > Components: Type conversion >Affects Versions: 2.2 >Reporter: Lars W >Priority: Minor > Fix For: 2.3 > > > When improving the error message of the ConversionException thrown by the > ConversionHandler in AbstractConfiguration.java:1768 the cause is lost. > If for example a string is converted into a URL the MalformedURLException, > that contains the actual reason for the failed conversion, is gone. > A possible fix for that could be to attach the cause to the new > ConversionException: > AbstractConfiguration.java:1768: > throw new ConversionException( > String.format( > "Key '%s' cannot be converted to class %s. Value is: '%s'.", > key, cls.getName(), String.valueOf(value)), cex.getCause()); > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-693) Conversion to File is missing
[ https://issues.apache.org/jira/browse/CONFIGURATION-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16412761#comment-16412761 ] Oliver Heger commented on CONFIGURATION-693: Many thanks, this looks useful. In addition to File, we may also want to support conversions to Path objects, which is probably the preferred option on Java 1.7+. Also, is there any chance you could provide a unit test? New features to be added require corresponding unit tests. > Conversion to File is missing > - > > Key: CONFIGURATION-693 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-693 > Project: Commons Configuration > Issue Type: Improvement > Components: Type conversion >Affects Versions: 2.2 >Reporter: Lars W >Priority: Major > Attachments: Converter.patch.txt > > > PropertyConverter.java misses type conversion to File although a string could > be easily converted to a File. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CONFIGURATION-689) NullPointerException in ExprLookup when not using variables
[ https://issues.apache.org/jira/browse/CONFIGURATION-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-689. Resolution: Not A Problem Closing as it was confirmed that the current implementation does not cause any concrete problem. > NullPointerException in ExprLookup when not using variables > --- > > Key: CONFIGURATION-689 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-689 > Project: Commons Configuration > Issue Type: Bug > Components: Interpolation >Affects Versions: 2.2 >Reporter: Steven Paligo >Priority: Major > > When an ExprLookup instance is created with the default constructor, the > "variables" object is null. During a lookup, initializeContext(JexlContext) > iterates over "variables" which triggers a NullPointerException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CONFIGURATION-691) ExprLookup only works for expressions that evaluate to strings
[ https://issues.apache.org/jira/browse/CONFIGURATION-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-691. Resolution: Fixed Fix Version/s: 2.3 A fix was applied in SVN revision 1827145. Non-string expression results no longer cause a ClassCastException, but are converted to strings. The Lookup interface is indeed bound to string results. It has been designed to work with _StrSubstitutor_ from [lang], which is also string-based. Function-wise, this is not really a limitation because Commons Configuration can do many conversions to desired target data types; there may be unnecessary conversions though (from a type to string and back to the original type). Due to backwards compatibility, the Lookup interface can only be changed in a major release. > ExprLookup only works for expressions that evaluate to strings > -- > > Key: CONFIGURATION-691 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-691 > Project: Commons Configuration > Issue Type: Improvement > Components: Interpolation >Affects Versions: 2.2 >Reporter: Steven Paligo >Priority: Major > Fix For: 2.3 > > > ExprLookup only works when the expression evaluates to a string. The > doLookup(...) method casts the result to a string, which triggers a > ClassCastException when it isn't. > This is unnecessary. The Lookup interface allows for any object to be > returned. Also, non-string expressions are entirely useful. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CONFIGURATION-690) ExprLookup will never return variables using getVariables()
[ https://issues.apache.org/jira/browse/CONFIGURATION-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-690. Resolution: Fixed Fix Version/s: 2.3 This is indeed strange. A fix has been applied in SVN revision 1827107, so that the method now returns a copy of the variables of this lookup object. > ExprLookup will never return variables using getVariables() > --- > > Key: CONFIGURATION-690 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-690 > Project: Commons Configuration > Issue Type: Bug > Components: Interpolation >Affects Versions: 2.2 >Reporter: Steven Paligo >Priority: Major > Fix For: 2.3 > > > ExprLookup's getVariables() method always returns null -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-689) NullPointerException in ExprLookup when not using variables
[ https://issues.apache.org/jira/browse/CONFIGURATION-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16403723#comment-16403723 ] Oliver Heger commented on CONFIGURATION-689: This is true; however, the NPE is not propagated to the outside, but caught and logged. The lookup operation returns the same variable that has been passed in. The default constructor could be modified to set an empty Variables object, but without further modifications this would change the behavior of the class: A lookup on an undefined variable would then return *null* rather than the variable name. Do you have a concrete use case in which this internal NPE causes a problem? > NullPointerException in ExprLookup when not using variables > --- > > Key: CONFIGURATION-689 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-689 > Project: Commons Configuration > Issue Type: Bug > Components: Interpolation >Affects Versions: 2.2 >Reporter: Steven Paligo >Priority: Major > > When an ExprLookup instance is created with the default constructor, the > "variables" object is null. During a lookup, initializeContext(JexlContext) > iterates over "variables" which triggers a NullPointerException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CONFIGURATION-688) Including a property file moves locator to that file
[
https://issues.apache.org/jira/browse/CONFIGURATION-688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-688.
Resolution: Fixed
Fix Version/s: 2.3
Fixed in SVN in revision 1826462. Many thanks for the report.
> Including a property file moves locator to that file
>
>
> Key: CONFIGURATION-688
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-688
> Project: Commons Configuration
> Issue Type: Bug
> Components: File reloading
>Affects Versions: 2.2
>Reporter: achelon
>Priority: Major
> Fix For: 2.3
>
>
> 1. Create files:
> {code:java}
> # toBeIncluded.properties
> some_prop=someValue{code}
> {code:java}
> # toBeIncluded2.properties
> some_prop_2=someValue2
> {code}
> {code:java}
> # someDirectory/prop.properties
> include=../toBeIncluded.properties
> include=../toBeIncluded2.properties
> {code}
> 2. Load someDirectory/prop.properties file
> Expected:
> * Both files are loaded
> Actual:
> * toBeIncluded2 cannot be loaded with
> org.apache.commons.configuration2.ex.ConfigurationException: Cannot resolve
> include file exception
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-688) Including a property file moves locator to that file
[
https://issues.apache.org/jira/browse/CONFIGURATION-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16394213#comment-16394213
]
Oliver Heger commented on CONFIGURATION-688:
Yes, this is a bug and should be fixed. I am going to have a look, or if
somebody wants to contribute a fix, even better.
> Including a property file moves locator to that file
>
>
> Key: CONFIGURATION-688
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-688
> Project: Commons Configuration
> Issue Type: Bug
> Components: File reloading
>Affects Versions: 2.2
>Reporter: achelon
>Priority: Major
>
> 1. Create files:
> {code:java}
> # toBeIncluded.properties
> some_prop=someValue{code}
> {code:java}
> # toBeIncluded2.properties
> some_prop_2=someValue2
> {code}
> {code:java}
> # someDirectory/prop.properties
> include=../toBeIncluded.properties
> include=../toBeIncluded2.properties
> {code}
> 2. Load someDirectory/prop.properties file
> Expected:
> * Both files are loaded
> Actual:
> * toBeIncluded2 cannot be loaded with
> org.apache.commons.configuration2.ex.ConfigurationException: Cannot resolve
> include file exception
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-686) JSONConfiguration doesn't support array of objects
[
https://issues.apache.org/jira/browse/CONFIGURATION-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16312013#comment-16312013
]
Oliver Heger commented on CONFIGURATION-686:
Thanks for the confirmation.
> JSONConfiguration doesn't support array of objects
> --
>
> Key: CONFIGURATION-686
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-686
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Vincent Maurin
> Fix For: 2.3
>
>
> Hello,
> I have noticed that the array type is not properly handled by the
> JSONConfiguration (or AbstractYAMLBasedConfiguration)
> If we take the example from json.org
> {noformat}
> {
> "menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {
> "value": "New",
> "onclick": "CreateNewDoc()"
> },
> {
> "value": "Open",
> "onclick": "OpenDoc()"
> },
> {
> "value": "Close",
> "onclick": "CloseDoc()"
> }
> ]
> }
> }
> }
> {noformat}
> I would have expect the following call to return "New"
> {code:java}
> configuration.getString("menu.popup.menuitem(0).value")
> {code}
> The issue, I guess, is that only the Map type is handled by
> AbstractYAMLBasedConfiguration in a recursive way and not the list type.
> I had a custom JSONConfiguration implementation before supporting this use
> case, sorry for the code, it could be a bit messy and old, but it is maybe
> clearer to understand my issue
> {code:java}
> @Override
> @SuppressWarnings("unchecked")
> public void read(Reader in) throws ConfigurationException {
> try {
> Object jsonRoot = MAPPER.readValue(in, Object.class);
> List roots = createHierarchy(jsonRoot);
> if (roots.size() != 1) {
> throw new ConfigurationException("The configuration only
> support a single root");
> }
> getSubConfigurationParentModel().mergeRoot(roots.get(0).create(),
> null, null, null, null);
> } catch (IOException ex) {
> throw new ConfigurationException("Invalid JsonConfiguration", ex);
> }
> }
>
> @SuppressWarnings("unchecked")
> private static List createHierarchy(Object value) {
> if (value instanceof Map) {
> ImmutableNode.Builder result = new ImmutableNode.Builder();
> Map map = (Map) value;
> for (Map.Entry entry : map.entrySet()) {
> List children =
> createHierarchy(entry.getValue());
> for (ImmutableNode.Builder child : children) {
> child.name(entry.getKey());
> result.addChild(child.create());
> }
> }
> return Collections.singletonList(result);
> } else if (value instanceof List) {
> List list = (List) value;
> List result = new ArrayList<>(list.size());
> for (Object item : list) {
> List children = createHierarchy(item);
> for (ImmutableNode.Builder child : children) {
> result.add(child);
> }
> }
> return result;
> }
> ImmutableNode.Builder result = new ImmutableNode.Builder();
> result.value(value);
> return Collections.singletonList(result);
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CONFIGURATION-686) JSONConfiguration doesn't support array of objects
[
https://issues.apache.org/jira/browse/CONFIGURATION-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-686.
Resolution: Fixed
Fix Version/s: 2.3
Fixed in SVN in revision 1819881.
Support for lists with complex elements has been added. I also extended the
test class to verify the new behavior. Can you please double-check if
everything works as expected?
Thanks.
> JSONConfiguration doesn't support array of objects
> --
>
> Key: CONFIGURATION-686
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-686
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Vincent Maurin
> Fix For: 2.3
>
>
> Hello,
> I have noticed that the array type is not properly handled by the
> JSONConfiguration (or AbstractYAMLBasedConfiguration)
> If we take the example from json.org
> {noformat}
> {
> "menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {
> "value": "New",
> "onclick": "CreateNewDoc()"
> },
> {
> "value": "Open",
> "onclick": "OpenDoc()"
> },
> {
> "value": "Close",
> "onclick": "CloseDoc()"
> }
> ]
> }
> }
> }
> {noformat}
> I would have expect the following call to return "New"
> {code:java}
> configuration.getString("menu.popup.menuitem(0).value")
> {code}
> The issue, I guess, is that only the Map type is handled by
> AbstractYAMLBasedConfiguration in a recursive way and not the list type.
> I had a custom JSONConfiguration implementation before supporting this use
> case, sorry for the code, it could be a bit messy and old, but it is maybe
> clearer to understand my issue
> {code:java}
> @Override
> @SuppressWarnings("unchecked")
> public void read(Reader in) throws ConfigurationException {
> try {
> Object jsonRoot = MAPPER.readValue(in, Object.class);
> List roots = createHierarchy(jsonRoot);
> if (roots.size() != 1) {
> throw new ConfigurationException("The configuration only
> support a single root");
> }
> getSubConfigurationParentModel().mergeRoot(roots.get(0).create(),
> null, null, null, null);
> } catch (IOException ex) {
> throw new ConfigurationException("Invalid JsonConfiguration", ex);
> }
> }
>
> @SuppressWarnings("unchecked")
> private static List createHierarchy(Object value) {
> if (value instanceof Map) {
> ImmutableNode.Builder result = new ImmutableNode.Builder();
> Map map = (Map) value;
> for (Map.Entry entry : map.entrySet()) {
> List children =
> createHierarchy(entry.getValue());
> for (ImmutableNode.Builder child : children) {
> child.name(entry.getKey());
> result.addChild(child.create());
> }
> }
> return Collections.singletonList(result);
> } else if (value instanceof List) {
> List list = (List) value;
> List result = new ArrayList<>(list.size());
> for (Object item : list) {
> List children = createHierarchy(item);
> for (ImmutableNode.Builder child : children) {
> result.add(child);
> }
> }
> return result;
> }
> ImmutableNode.Builder result = new ImmutableNode.Builder();
> result.value(value);
> return Collections.singletonList(result);
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-686) JSONConfiguration doesn't support array of objects
[
https://issues.apache.org/jira/browse/CONFIGURATION-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306243#comment-16306243
]
Oliver Heger commented on CONFIGURATION-686:
Thank you for the report and the solution proposal. I will have a look
(probably in a couple of days).
> JSONConfiguration doesn't support array of objects
> --
>
> Key: CONFIGURATION-686
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-686
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Vincent Maurin
>
> Hello,
> I have noticed that the array type is not properly handled by the
> JSONConfiguration (or AbstractYAMLBasedConfiguration)
> If we take the example from json.org
> {noformat}
> {
> "menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {
> "value": "New",
> "onclick": "CreateNewDoc()"
> },
> {
> "value": "Open",
> "onclick": "OpenDoc()"
> },
> {
> "value": "Close",
> "onclick": "CloseDoc()"
> }
> ]
> }
> }
> }
> {noformat}
> I would have expect the following call to return "New"
> {code:java}
> configuration.getString("menu.popup.menuitem(0).value")
> {code}
> The issue, I guess, is that only the Map type is handled by
> AbstractYAMLBasedConfiguration in a recursive way and not the list type.
> I had a custom JSONConfiguration implementation before supporting this use
> case, sorry for the code, it could be a bit messy and old, but it is maybe
> clearer to understand my issue
> {code:java}
> @Override
> @SuppressWarnings("unchecked")
> public void read(Reader in) throws ConfigurationException {
> try {
> Object jsonRoot = MAPPER.readValue(in, Object.class);
> List roots = createHierarchy(jsonRoot);
> if (roots.size() != 1) {
> throw new ConfigurationException("The configuration only
> support a single root");
> }
> getSubConfigurationParentModel().mergeRoot(roots.get(0).create(),
> null, null, null, null);
> } catch (IOException ex) {
> throw new ConfigurationException("Invalid JsonConfiguration", ex);
> }
> }
>
> @SuppressWarnings("unchecked")
> private static List createHierarchy(Object value) {
> if (value instanceof Map) {
> ImmutableNode.Builder result = new ImmutableNode.Builder();
> Map map = (Map) value;
> for (Map.Entry entry : map.entrySet()) {
> List children =
> createHierarchy(entry.getValue());
> for (ImmutableNode.Builder child : children) {
> child.name(entry.getKey());
> result.addChild(child.create());
> }
> }
> return Collections.singletonList(result);
> } else if (value instanceof List) {
> List list = (List) value;
> List result = new ArrayList<>(list.size());
> for (Object item : list) {
> List children = createHierarchy(item);
> for (ImmutableNode.Builder child : children) {
> result.add(child);
> }
> }
> return result;
> }
> ImmutableNode.Builder result = new ImmutableNode.Builder();
> result.value(value);
> return Collections.singletonList(result);
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-684) YAMLConfiguration keys with double dots
[
https://issues.apache.org/jira/browse/CONFIGURATION-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16302945#comment-16302945
]
Oliver Heger commented on CONFIGURATION-684:
[~kinow], there is nothing special in the handling of escapes for YAML
configuration. The logic is implemented in the base classes for hierarchical
configurations. If you modify the test program from [~fabienrenaud] to use a
different configuration type - say {{XMLConfiguration}} -, it should produce
similar results.
It is possible to handle keys with dots in their names; they just have to be
escaped properly as described in the user's guide.
Also note that the dot is critical only for the default expression engine
because here it is the default element delimiter character. You can configure a
different character or switch to {{XPathExpressionEngine}}; then you do not
have to do the escaping any more.
> YAMLConfiguration keys with double dots
> ---
>
> Key: CONFIGURATION-684
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-684
> Project: Commons Configuration
> Issue Type: Bug
>Reporter: Fabien Renaud
> Labels: discussion, help-wanted
>
> h2. Issue
> Loading a YAML configuration with dotted keys causes dots to be duplicated in
> the keys of the YAMLConfiguration object.
> h2. Repro
> 100% repro:
> file.yml:
> {code}some.key.with.dots: 123{code}
> {code}
> package foo;
> import org.apache.commons.configuration2.YAMLConfiguration;
> import
> org.apache.commons.configuration2.builder.FileBasedConfigurationBuilder;
> import org.apache.commons.configuration2.builder.fluent.Parameters;
> import org.apache.commons.configuration2.ex.ConfigurationException;
> public class App {
> public static void main(String[] args) throws ConfigurationException {
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder1 =
> new FileBasedConfigurationBuilder<>(YAMLConfiguration.class)
>
> .configure(params.fileBased().setFileName("file.yml"));
>
> YAMLConfiguration conf = builder1.getConfiguration();
> conf.getKeys().forEachRemaining(System.out::println);
> System.out.println("---");
> YAMLConfiguration yaml = new YAMLConfiguration();
> yaml.read(new
> InputStreamReader(ClassLoader.getSystemResourceAsStream("file.yml")));
> yaml.getKeys().forEachRemaining(System.out::println);
> }
> }
> {code}
> prints
> {code}some..key..with..dots
> ---
> some..key..with..dots
> {code}
> That is a serious bug for a configuration system. The issue may easily go
> untested for some keys and only reveal itself on production.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-684) YAMLConfiguration keys with double dots
[
https://issues.apache.org/jira/browse/CONFIGURATION-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16302520#comment-16302520
]
Oliver Heger commented on CONFIGURATION-684:
The problem is that the dot is the normal property delimiter character. If it
appears in a property name, it must be escaped.
> YAMLConfiguration keys with double dots
> ---
>
> Key: CONFIGURATION-684
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-684
> Project: Commons Configuration
> Issue Type: Bug
>Reporter: Fabien Renaud
>
> h2. Issue
> Loading a YAML configuration with dotted keys causes dots to be duplicated in
> the keys of the YAMLConfiguration object.
> h2. Repro
> 100% repro:
> file.yml:
> {code}some.key.with.dots: 123{code}
> {code}
> package foo;
> import org.apache.commons.configuration2.YAMLConfiguration;
> import
> org.apache.commons.configuration2.builder.FileBasedConfigurationBuilder;
> import org.apache.commons.configuration2.builder.fluent.Parameters;
> import org.apache.commons.configuration2.ex.ConfigurationException;
> public class App {
> public static void main(String[] args) throws ConfigurationException {
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder1 =
> new FileBasedConfigurationBuilder<>(YAMLConfiguration.class)
>
> .configure(params.fileBased().setFileName("file.yml"));
>
> YAMLConfiguration conf = builder1.getConfiguration();
> conf.getKeys().forEachRemaining(System.out::println);
> System.out.println("---");
> YAMLConfiguration yaml = new YAMLConfiguration();
> yaml.read(new
> InputStreamReader(ClassLoader.getSystemResourceAsStream("file.yml")));
> yaml.getKeys().forEachRemaining(System.out::println);
> }
> }
> {code}
> prints
> {code}some..key..with..dots
> ---
> some..key..with..dots
> {code}
> That is a serious bug for a configuration system. The issue may easily go
> untested for some keys and only reveal itself on production.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-684) YAMLConfiguration keys with double dots
[
https://issues.apache.org/jira/browse/CONFIGURATION-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16302507#comment-16302507
]
Oliver Heger commented on CONFIGURATION-684:
[~kinow], maybe I have not fully understood this ticket. I think the report is
only that the getKeys() method returns keys that are different from the
original keys if the configuration contains keys with dots. But this is the
normal behavior for all hierarchical configurations. Or do I miss something?
So my proposed fix would be to add a note to the Javadocs of getKeys().
> YAMLConfiguration keys with double dots
> ---
>
> Key: CONFIGURATION-684
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-684
> Project: Commons Configuration
> Issue Type: Bug
>Reporter: Fabien Renaud
>
> h2. Issue
> Loading a YAML configuration with dotted keys causes dots to be duplicated in
> the keys of the YAMLConfiguration object.
> h2. Repro
> 100% repro:
> file.yml:
> {code}some.key.with.dots: 123{code}
> {code}
> package foo;
> import org.apache.commons.configuration2.YAMLConfiguration;
> import
> org.apache.commons.configuration2.builder.FileBasedConfigurationBuilder;
> import org.apache.commons.configuration2.builder.fluent.Parameters;
> import org.apache.commons.configuration2.ex.ConfigurationException;
> public class App {
> public static void main(String[] args) throws ConfigurationException {
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder1 =
> new FileBasedConfigurationBuilder<>(YAMLConfiguration.class)
>
> .configure(params.fileBased().setFileName("file.yml"));
>
> YAMLConfiguration conf = builder1.getConfiguration();
> conf.getKeys().forEachRemaining(System.out::println);
> System.out.println("---");
> YAMLConfiguration yaml = new YAMLConfiguration();
> yaml.read(new
> InputStreamReader(ClassLoader.getSystemResourceAsStream("file.yml")));
> yaml.getKeys().forEachRemaining(System.out::println);
> }
> }
> {code}
> prints
> {code}some..key..with..dots
> ---
> some..key..with..dots
> {code}
> That is a serious bug for a configuration system. The issue may easily go
> untested for some keys and only reveal itself on production.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-685) Implicit external dependency on DynaBean while loading a config
[
https://issues.apache.org/jira/browse/CONFIGURATION-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16301688#comment-16301688
]
Oliver Heger commented on CONFIGURATION-685:
Commons Configuration has a lot of dependencies, but most are optional and are
only needed for specific configuration implementations. Therefore, they are not
pulled in automatically, but a client application has to declare them
explicitly. As Bruno mentioned, we have documented the dependencies and when
they are required on the dependencies page.
So, can this ticket be closed?
> Implicit external dependency on DynaBean while loading a config
> ---
>
> Key: CONFIGURATION-685
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-685
> Project: Commons Configuration
> Issue Type: Bug
>Reporter: Fabien Renaud
>
> 100% repro.
> Getting an exception: DynaBean not found when trying to load an apache config
> file.
> Exception:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/commons/beanutils/DynaBean
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at com.sun.proxy.$Proxy0.(Unknown Source)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:739)
> at
> org.apache.commons.configuration2.builder.fluent.Parameters.createParametersProxy(Parameters.java:307)
> at
> org.apache.commons.configuration2.builder.fluent.Parameters.fileBased(Parameters.java:186)
> at com.example.App.main(App.java:13)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.commons.beanutils.DynaBean
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 11 more
> {code}
> when running:
> {code}
> package com.example;
> import org.apache.commons.configuration2.YAMLConfiguration;
> import
> org.apache.commons.configuration2.builder.FileBasedConfigurationBuilder;
> import org.apache.commons.configuration2.builder.fluent.Parameters;
> import org.apache.commons.configuration2.ex.ConfigurationException;
> class App {
> public static void main(String[] args) throws ConfigurationException {
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder1 = new
> FileBasedConfigurationBuilder<>(YAMLConfiguration.class)
> .configure(params.fileBased().setFileName("file.yml"));
> YAMLConfiguration conf = builder1.getConfiguration();
> }
> }
> {code}
> with build.gradle:
> {code}
> apply plugin: 'java'
> apply plugin: 'application'
> mainClassName = "com.example.App"
> repositories {
> jcenter()
> }
> dependencies {
> compile group: 'org.apache.commons', name: 'commons-configuration2',
> version: '2.2'
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-684) YAMLConfiguration keys with double dots
[
https://issues.apache.org/jira/browse/CONFIGURATION-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16301678#comment-16301678
]
Oliver Heger commented on CONFIGURATION-684:
The documentation is still available for 2.x; it can be found here:
http://commons.apache.org/proper/commons-configuration/userguide/howto_hierarchical.html#Escaping_special_characters
Maybe it is confusing and could be better documented, but the behavior is
actually expected. As described in the referenced section of the documentation,
you have to duplicate dots in order to escape them, so that properties with
dots in their names can be accessed correctly. The iterator returned by
getKeys() takes this into account, i.e. it returns keys in an escaped form, so
that they can be used directly to query properties. Otherwise, you would have
very strange results: keys obtained from the configuration would be
unresolvable.
> YAMLConfiguration keys with double dots
> ---
>
> Key: CONFIGURATION-684
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-684
> Project: Commons Configuration
> Issue Type: Bug
>Reporter: Fabien Renaud
>
> h2. Issue
> Loading a YAML configuration with dotted keys causes dots to be duplicated in
> the keys of the YAMLConfiguration object.
> h2. Repro
> 100% repro:
> file.yml:
> {code}some.key.with.dots: 123{code}
> {code}
> package foo;
> import org.apache.commons.configuration2.YAMLConfiguration;
> import
> org.apache.commons.configuration2.builder.FileBasedConfigurationBuilder;
> import org.apache.commons.configuration2.builder.fluent.Parameters;
> import org.apache.commons.configuration2.ex.ConfigurationException;
> public class App {
> public static void main(String[] args) throws ConfigurationException {
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder1 =
> new FileBasedConfigurationBuilder<>(YAMLConfiguration.class)
>
> .configure(params.fileBased().setFileName("file.yml"));
>
> YAMLConfiguration conf = builder1.getConfiguration();
> conf.getKeys().forEachRemaining(System.out::println);
> System.out.println("---");
> YAMLConfiguration yaml = new YAMLConfiguration();
> yaml.read(new
> InputStreamReader(ClassLoader.getSystemResourceAsStream("file.yml")));
> yaml.getKeys().forEachRemaining(System.out::println);
> }
> }
> {code}
> prints
> {code}some..key..with..dots
> ---
> some..key..with..dots
> {code}
> That is a serious bug for a configuration system. The issue may easily go
> untested for some keys and only reveal itself on production.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-677) FileBasedConfigurationBuilder allowFailOnInit vs HomeDirectoryLocationStrategy
[
https://issues.apache.org/jira/browse/CONFIGURATION-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16279161#comment-16279161
]
Oliver Heger commented on CONFIGURATION-677:
So far the setting whether a configuration source is optional has been seen as
a property of the builder that creates the configuration and not of the
configuration itself. It may be possible and beneficial to implement this as a
configuration property. It would then have to be placed in one of the parameter
objects.
I would not go so far to introduce a priority for location strategies to
determine a default path for optional sources. This solution seems to be too
clever and will be hard to understand. It may already be sufficient to just
specify a default location explicitly.
> FileBasedConfigurationBuilder allowFailOnInit vs HomeDirectoryLocationStrategy
> --
>
> Key: CONFIGURATION-677
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-677
> Project: Commons Configuration
> Issue Type: Bug
> Components: Documentation, File reloading
>Affects Versions: 2.2
> Environment: macOS Sierra 10.12.6, Java 1.8.0_152
>Reporter: Piotr Skowronek
> Fix For: 2.x
>
>
> It seems there's a problem with configuration creation when using
> FileBasedConfigurationBuilder with allowFailOnInit together with
> HomeDirectoryLocationStrategy and autoSave option.
> If the configuration is present in user.home directory (let's say
> ~/.some.config) it is being loaded and updated properly, but if the file does
> *not exist* then the configuration is created in current working directory
> (where the java program was launched) and *not* in user home directory.
> Javadoc of BasicConfigurationBuilder states as follows:
> {quote}A builder instance can be constructed with an allowFailOnInit
> * flag. If set to true, exceptions during initialization
> * of the configuration are ignored; in such a case an empty configuration
> * object is returned. A use case for this flag is a scenario in which a
> * configuration is optional and created on demand the first time
> configuration
> * data is to be stored. Consider an application that stores user-specific
> * configuration data in the user's home directory: When started for the first
> * time by a new user there is no configuration file; so it makes sense to
> * start with an empty configuration object. On application exit, settings
> * can be stored in this object and written to the associated file. Then they
> * are available on next application start.
> {quote}
> So, either it is a bug and it should be fixed in the Configuration project or
> it is the correct behavior and it is the programmer to ensure to write the
> configuration in the right place for the first time. If the latter then I
> would suggest to update javadoc to state that clearly enough (and maybe
> provide an example on the project website).
> Code sample:
> {code}
> // file not present: ~/.some.config
> BuilderParameters params = new
> Parameters().properties().setFileName(".some.config")
> .setLocationStrategy(new HomeDirectoryLocationStrategy());
> builder = new
> FileBasedConfigurationBuilder(PropertiesConfiguration.class,
> params.getParameters(), true);
> builder.setAutoSave(true);
> config = builder.getConfiguration();
> config.setProperty("test", "test);
> // config file .some.config not present in ~/.some.config but present
> in CWD
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-677) FileBasedConfigurationBuilder allowFailOnInit vs HomeDirectoryLocationStrategy
[
https://issues.apache.org/jira/browse/CONFIGURATION-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16275730#comment-16275730
]
Oliver Heger commented on CONFIGURATION-677:
Thanks for this report.
I agree that based on the documentation a user may expect too much. The ideal
solution in your case would probably be that the configuration file was created
correctly in the user's home directory. With the current interfaces of location
strategies this cannot be achieved, however. HomeDirectoryLocationStrategy can
only find out that the requested file does not exist, but there is no way for
it to give a hint upstream where the file should be stored once it has been
created. (With multiple location strategies in place, there would probably be
no clear solution which one should define the target location.)
So an update of documentation would be appropriate. The feature of optional
configuration sources was originally intended to be used together with
{{CombinedConfigurationBuilder}}. Here optional sources can be included, and by
using interpolation with system properties the target path can be specified
exactly. I will try to improve the documentation in this area.
> FileBasedConfigurationBuilder allowFailOnInit vs HomeDirectoryLocationStrategy
> --
>
> Key: CONFIGURATION-677
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-677
> Project: Commons Configuration
> Issue Type: Bug
> Components: Documentation, File reloading
>Affects Versions: 2.2
> Environment: macOS Sierra 10.12.6, Java 1.8.0_152
>Reporter: Piotr Skowronek
> Fix For: 2.x
>
>
> It seems there's a problem with configuration creation when using
> FileBasedConfigurationBuilder with allowFailOnInit together with
> HomeDirectoryLocationStrategy and autoSave option.
> If the configuration is present in user.home directory (let's say
> ~/.some.config) it is being loaded and updated properly, but if the file does
> *not exist* then the configuration is created in current working directory
> (where the java program was launched) and *not* in user home directory.
> Javadoc of BasicConfigurationBuilder states as follow:
> {quote}A builder instance can be constructed with an allowFailOnInit
> * flag. If set to true, exceptions during initialization
> * of the configuration are ignored; in such a case an empty configuration
> * object is returned. A use case for this flag is a scenario in which a
> * configuration is optional and created on demand the first time
> configuration
> * data is to be stored. Consider an application that stores user-specific
> * configuration data in the user's home directory: When started for the first
> * time by a new user there is no configuration file; so it makes sense to
> * start with an empty configuration object. On application exit, settings
> * can be stored in this object and written to the associated file. Then they
> * are available on next application start.
> {quote}
> So, either it is a bug and it should be fixed in the Configuration project or
> it is the correct behavior and it is the programmer to ensure to write the
> configuration in the right place for the first time. If the latter then I
> would suggest to update javadoc to state that clearly enough (and maybe
> provide an example on the project website).
> Code sample:
> {code}
> // file not present: ~/.some.config
> BuilderParameters params = new
> Parameters().properties().setFileName(".some.config")
> .setLocationStrategy(new HomeDirectoryLocationStrategy());
> builder = new
> FileBasedConfigurationBuilder(PropertiesConfiguration.class,
> params.getParameters(), true);
> builder.setAutoSave(true);
> config = builder.getConfiguration();
> config.setProperty("test", "test);
> // config file .some.config not present in ~/.some.config but present
> in CWD
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-676) Configuration with OS Environment Variables
[
https://issues.apache.org/jira/browse/CONFIGURATION-676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16265517#comment-16265517
]
Oliver Heger commented on CONFIGURATION-676:
Commons Configuration already has support for reading environment variables.
There is the dedicated {{EnviromentConfiguration}} class for this purpose.
It is also possible to integrate values from environment variables into other
configurations using interpolation with the {{env}} prefix. This is described
in the user's guide at
http://commons.apache.org/proper/commons-configuration/userguide/howto_basicfeatures.html#Variable_Interpolation
> Configuration with OS Environment Variables
> ---
>
> Key: CONFIGURATION-676
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-676
> Project: Commons Configuration
> Issue Type: New Feature
>Reporter: Robin Björklin
>
> Handling configuration with Environment Variables have become more
> commonplace with the advent of containers and it would be very nice if it
> were to be supported by commons-configuration.
> An example project doing this would be Spring Boot where where an
> configuration property such as *colors.background* could be picked up as the
> environment variable *COLORS_BACKGROUND*.
> Would this make sense for commons-configuration?
> Reference:
> https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CONFIGURATION-675) Add .gitignore file
[ https://issues.apache.org/jira/browse/CONFIGURATION-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-675. Resolution: Fixed Fix Version/s: 2.3 Copied the .gitignore file from Commons Lang. Fixed in SVN in revision 1814959. > Add .gitignore file > --- > > Key: CONFIGURATION-675 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-675 > Project: Commons Configuration > Issue Type: Improvement > Components: Build >Reporter: mingleizhang >Priority: Blocker > Fix For: 2.3 > > > Add .gitignore to this project -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CONFIGURATION-673) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CONFIGURATION-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-673. Resolution: Fixed Patch applied in revision 1811254. Thanks again. > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CONFIGURATION-673 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-673 > Project: Commons Configuration > Issue Type: Improvement >Reporter: Andreas Kuhtz > Fix For: 2.2 > > > To make Commons Configuration2 usable as a Java 9 module, we need to add the > Automatic-Module-Name MANIFEST header. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-673) Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
[ https://issues.apache.org/jira/browse/CONFIGURATION-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16187462#comment-16187462 ] Oliver Heger commented on CONFIGURATION-673: Pull request from Andreas Kuhtz is available at: https://github.com/apache/commons-configuration/pull/6 > Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility > - > > Key: CONFIGURATION-673 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-673 > Project: Commons Configuration > Issue Type: Improvement >Reporter: Andreas Kuhtz > Fix For: 2.2 > > > To make Commons Configuration2 usable as a Java 9 module, we need to add the > Automatic-Module-Name MANIFEST header. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-672) zookeeper as a configuration source for configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16152811#comment-16152811 ] Oliver Heger commented on CONFIGURATION-672: Sounds interesting - well, the web tool would probably out of scope. Patches welcome. > zookeeper as a configuration source for configuration > - > > Key: CONFIGURATION-672 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-672 > Project: Commons Configuration > Issue Type: Improvement > Components: File reloading >Affects Versions: 2.1.1 >Reporter: Robert Sims >Priority: Trivial > > It would be nice enhancement for Commons Configuration to offer an > implementation for a source for properties from zookeeper. Along with the > standard getters for the configuraiton interface, If not already a part of > the configuration interface, it may be useful to be able to getBytes[] to > be able to retrieve a file from a byte[] in zookeeper as well. A Web tool > would be useful to update/manage the configuration stored in zookeeper. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CONFIGURATION-672) zookeeper as a configuration source for configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-672: --- Description: It would be nice enhancement for Commons Configuration to offer an implementation for a source for properties from zookeeper. Along with the standard getters for the configuraiton interface, If not already a part of the configuration interface, it may be useful to be able to getBytes[] to be able to retrieve a file from a byte[] in zookeeper as well. A Web tool would be useful to update/manage the configuration stored in zookeeper. > zookeeper as a configuration source for configuration > - > > Key: CONFIGURATION-672 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-672 > Project: Commons Configuration > Issue Type: Improvement > Components: File reloading >Affects Versions: 2.1.1 > Environment: It would be nice enhancement for Commons Configuration > to offer an implementation for a source for properties from zookeeper. > Along with the standard getters for the configuraiton interface, If not > already a part of the configuration interface, it may be useful to be able > to getBytes[] to be able to retrieve a file from a byte[] in zookeeper as > well. A Web tool would be useful to update/manage the configuration stored > in zookeeper. >Reporter: Robert Sims >Priority: Trivial > > It would be nice enhancement for Commons Configuration to offer an > implementation for a source for properties from zookeeper. Along with the > standard getters for the configuraiton interface, If not already a part of > the configuration interface, it may be useful to be able to getBytes[] to > be able to retrieve a file from a byte[] in zookeeper as well. A Web tool > would be useful to update/manage the configuration stored in zookeeper. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CONFIGURATION-672) zookeeper as a configuration source for configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger updated CONFIGURATION-672: --- Environment: (was: It would be nice enhancement for Commons Configuration to offer an implementation for a source for properties from zookeeper. Along with the standard getters for the configuraiton interface, If not already a part of the configuration interface, it may be useful to be able to getBytes[] to be able to retrieve a file from a byte[] in zookeeper as well. A Web tool would be useful to update/manage the configuration stored in zookeeper.) > zookeeper as a configuration source for configuration > - > > Key: CONFIGURATION-672 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-672 > Project: Commons Configuration > Issue Type: Improvement > Components: File reloading >Affects Versions: 2.1.1 >Reporter: Robert Sims >Priority: Trivial > > It would be nice enhancement for Commons Configuration to offer an > implementation for a source for properties from zookeeper. Along with the > standard getters for the configuraiton interface, If not already a part of > the configuration interface, it may be useful to be able to getBytes[] to > be able to retrieve a file from a byte[] in zookeeper as well. A Web tool > would be useful to update/manage the configuration stored in zookeeper. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CONFIGURATION-670) Inconsistency with configurationAt method.
[
https://issues.apache.org/jira/browse/CONFIGURATION-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-670.
Resolution: Fixed
Fix Version/s: 2.2
Fixed in SVN in revision 1806833.
The implementation of _getNodeModel()_ in {{SubnodeConfiguration}} has been
changed to return a model with the correct root node set. An additional method
has been added that returns the model of the top-level hierarchical
configuration. (This was needed by some tests.)
> Inconsistency with configurationAt method.
> --
>
> Key: CONFIGURATION-670
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-670
> Project: Commons Configuration
> Issue Type: Bug
> Components: Expression engine
>Affects Versions: 2.1.1
>Reporter: Magno Nascimento de Azevedo Cruz
> Fix For: 2.2
>
>
> After some testing, I found some inconsistency with the use of
> {{configurationAt()}}, to simplify it, this version is working correctly,
> returning the {{HierarchicalConfiguration}} pointing to the right property:
> {code:java}
> config.configurationAt("property.indexedProperty(0)", false);
> {code}
> While this version, instead of returning a {{HierarchicalConfiguration}} with
> the root tracking node pointing to {{indexedProperty(0)}}, it returns the
> tracking node pointing to the root of the whole tree of properties.
> {code:java}
> config.configurationAt("property.indexedProperty(0)", true);
> {code}
> I'm trying to implement a support to a new format called
> [SURF|https://urf.io/surf/] created by GlobalMentor, but I didn't override
> this method, so I think it's coming from the original implementation.
> More informations may be found at
> [https://globalmentor.atlassian.net/browse/URF-34].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CONFIGURATION-671) Empty ini section occurs NPE while save to writer
[
https://issues.apache.org/jira/browse/CONFIGURATION-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-671.
Resolution: Fixed
Fix Version/s: 2.2
Fixed in SVN in revision 1806820.
The root cause of the problem was that configuration nodes without children (as
is the case for an empty section) were not recognized as section nodes. This
has been fixed now.
Thanks again.
> Empty ini section occurs NPE while save to writer
> -
>
> Key: CONFIGURATION-671
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-671
> Project: Commons Configuration
> Issue Type: Bug
> Components: File reloading, Format
>Affects Versions: 2.1.1
> Environment: OS: OS X 10.12
> JDK: 1.8
>Reporter: yankai zhang
>Priority: Minor
> Fix For: 2.2
>
>
> Run following code:
> {code:java}
> import org.apache.commons.configuration2.INIConfiguration;
> import java.io.*;
> public class Demo {
>public static void main(String[] args) throws Exception {
> INIConfiguration ini = new INIConfiguration();
> ini.read(new StringReader("[emptySection]"));
> ini.write(new StringWriter());
> }
> }
> {code}
> Result:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.commons.configuration2.INIConfiguration.writeProperty(INIConfiguration.java:458)
> at
> org.apache.commons.configuration2.INIConfiguration.write(INIConfiguration.java:309)
> at Demo.main(Demo.java:8)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-671) Empty ini section occurs NPE while save to writer
[
https://issues.apache.org/jira/browse/CONFIGURATION-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147809#comment-16147809
]
Oliver Heger commented on CONFIGURATION-671:
Thank you for the report. I will have a look.
> Empty ini section occurs NPE while save to writer
> -
>
> Key: CONFIGURATION-671
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-671
> Project: Commons Configuration
> Issue Type: Bug
> Components: File reloading, Format
>Affects Versions: 2.1.1
> Environment: OS: OS X 10.12
> JDK: 1.8
>Reporter: yankai zhang
>Priority: Minor
>
> Run following code:
> {code:java}
> import org.apache.commons.configuration2.INIConfiguration;
> import java.io.*;
> public class Demo {
>public static void main(String[] args) throws Exception {
> INIConfiguration ini = new INIConfiguration();
> ini.read(new StringReader("[emptySection]"));
> ini.write(new StringWriter());
> }
> }
> {code}
> Result:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.commons.configuration2.INIConfiguration.writeProperty(INIConfiguration.java:458)
> at
> org.apache.commons.configuration2.INIConfiguration.write(INIConfiguration.java:309)
> at Demo.main(Demo.java:8)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-670) Inconsistency with configurationAt method.
[
https://issues.apache.org/jira/browse/CONFIGURATION-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16143155#comment-16143155
]
Oliver Heger commented on CONFIGURATION-670:
Thanks for your detailed input.
I think the problem lies in the implementation of _getNodeModel()_ in
_SubnodeConfiguration_ which returns the model of the parent configuration and
thus points to the original root node. It does so because it does not have an
_InMemoryNodeModel_ on its own which it could expose. (And I have currently no
idea how it could come to a correctly initialized model.)
Access to configuration properties work correctly because here the model
returned by the _getModel()_ method is used. If you change your examples to
replace _getNodeModel()_ by _getModel()_ they should work. However, the problem
here is that _getModel()_ is more for internal access and does not use correct
synchronization.
Not sure how to proceed. Normal usage of configuration objects works correctly,
and all methods do what is documented. Is the _getNodeModel()_ method in
_SubnodeConfiguration_ important for your implementation?
> Inconsistency with configurationAt method.
> --
>
> Key: CONFIGURATION-670
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-670
> Project: Commons Configuration
> Issue Type: Bug
> Components: Expression engine
>Affects Versions: 2.1.1
>Reporter: Magno Nascimento de Azevedo Cruz
>
> After some testing, I found some inconsistency with the use of
> {{configurationAt()}}, to simplify it, this version is working correctly,
> returning the {{HierarchicalConfiguration}} pointing to the right property:
> {code:java}
> config.configurationAt("property.indexedProperty(0)", false);
> {code}
> While this version, instead of returning a {{HierarchicalConfiguration}} with
> the root tracking node pointing to {{indexedProperty(0)}}, it returns the
> tracking node pointing to the root of the whole tree of properties.
> {code:java}
> config.configurationAt("property.indexedProperty(0)", true);
> {code}
> I'm trying to implement a support to a new format called
> [SURF|https://urf.io/surf/] created by GlobalMentor, but I didn't override
> this method, so I think it's coming from the original implementation.
> More informations may be found at
> [https://globalmentor.atlassian.net/browse/URF-34].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-670) Inconsistency with configurationAt method.
[
https://issues.apache.org/jira/browse/CONFIGURATION-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16142902#comment-16142902
]
Oliver Heger commented on CONFIGURATION-670:
I did some testing, but was not yet able to reproduce the problem. I created a
test XML configuration based on your example:
{code:xml}
red
green
blue
{code}
Then I added the following unit test:
{code}
@Test
public void testConfigurationAt() throws ConfigurationException {
conf = createFromFile("colors.xml");
HierarchicalConfiguration sub =
conf.configurationAt("favoriteColors.Color(0)", true);
assertEquals("Wrong result", "red", sub.getString(""));
}
{code}
(_createFromFile()_ is a helper method in the test class for
{{XMLConfiguration}} which loads the specified test file.) The test was green,
the correct node was resolved.
Can you provide further information how the problem can be reproduced?
> Inconsistency with configurationAt method.
> --
>
> Key: CONFIGURATION-670
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-670
> Project: Commons Configuration
> Issue Type: Bug
> Components: Expression engine
>Affects Versions: 2.1.1
>Reporter: Magno Nascimento de Azevedo Cruz
>
> After some testing, I found some inconsistency with the use of
> {{configurationAt()}}, to simplify it, this version is working correctly,
> returning the {{HierarchicalConfiguration}} pointing to the right property:
> {code:java}
> config.configurationAt("property.indexedProperty(0)", false);
> {code}
> While this version, instead of returning a {{HierarchicalConfiguration}} with
> the root tracking node pointing to {{indexedProperty(0)}}, it returns the
> tracking node pointing to the root of the whole tree of properties.
> {code:java}
> config.configurationAt("property.indexedProperty(0)", true);
> {code}
> I'm trying to implement a support to a new format called
> [SURF|https://urf.io/surf/] created by GlobalMentor, but I didn't override
> this method, so I think it's coming from the original implementation.
> More informations may be found at
> [https://globalmentor.atlassian.net/browse/URF-34].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-670) Inconsistency with configurationAt method.
[
https://issues.apache.org/jira/browse/CONFIGURATION-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16131175#comment-16131175
]
Oliver Heger commented on CONFIGURATION-670:
So, do I understand correctly that the key passed to the configuration instance
is not resolved correctly?
Any chance that you can provide a unit test or a small test program that
demonstrates the bug? This would help us to reproduce the problem.
Thanks.
> Inconsistency with configurationAt method.
> --
>
> Key: CONFIGURATION-670
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-670
> Project: Commons Configuration
> Issue Type: Bug
> Components: Expression engine
>Affects Versions: 2.1.1
>Reporter: Magno Nascimento de Azevedo Cruz
>
> After some testing, I found some inconsistency with the use of
> {{configurationAt()}}, to simplify it, this version is working correctly,
> returning the {{HierarchicalConfiguration}} pointing to the right property:
> {code:java}
> config.configurationAt("property.indexedProperty(0)", false);
> {code}
> While this version, instead of returning a {{HierarchicalConfiguration}} with
> the root tracking node pointing to {{indexedProperty(0)}}, it returns the
> tracking node pointing to the root of the whole tree of properties.
> {code:java}
> config.configurationAt("property.indexedProperty(0)", true);
> {code}
> I'm trying to implement a support to a new format called
> [SURF|https://urf.io/surf/] created by GlobalMentor, but I didn't override
> this method, so I think it's coming from the original implementation.
> More informations may be found at
> [https://globalmentor.atlassian.net/browse/URF-34].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-258) JSON configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16063698#comment-16063698
]
Oliver Heger commented on CONFIGURATION-258:
Added you to the contributors section in revision 1799978.
> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Priority: Minor
> Fix For: 2.2
>
> Attachments: commons-configuration2-yaml.and.json.support.diff
>
>
> JSON is a lightweight data-interchange format
> {code}
> {"menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {"value": "New", "onclick": "CreateNewDoc()"},
> {"value": "Open", "onclick": "OpenDoc()"},
> {"value": "Close", "onclick": "CloseDoc()"}
> ]
> }
> }}
> {code}
> All references can be located at
> http://www.json.org/
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CONFIGURATION-258) JSON configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-258.
Resolution: Fixed
Fix Version/s: (was: 2.x)
2.2
Patch applied with some changes in revision 1799599.
Thanks again. If you want to be added to the contributors section, please
provide the data you want to get in.
> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Priority: Minor
> Fix For: 2.2
>
> Attachments: commons-configuration2-yaml.and.json.support.diff
>
>
> JSON is a lightweight data-interchange format
> {code}
> {"menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {"value": "New", "onclick": "CreateNewDoc()"},
> {"value": "Open", "onclick": "OpenDoc()"},
> {"value": "Close", "onclick": "CloseDoc()"}
> ]
> }
> }}
> {code}
> All references can be located at
> http://www.json.org/
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CONFIGURATION-656) YAML Configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-656. Resolution: Fixed Fix Version/s: 2.2 Patch applied with some changes in revision 1799599. > YAML Configuration > -- > > Key: CONFIGURATION-656 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-656 > Project: Commons Configuration > Issue Type: New Feature > Components: Format >Reporter: Gary Gregory > Fix For: 2.2 > > > Like the missing JSON Configuration, we really should also support YAML. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
