[jira] [Commented] (CONFIGURATION-837) MapConfiguration$1 does not implement Cloneable exception
[
https://issues.apache.org/jira/browse/CONFIGURATION-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785141#comment-17785141
]
Rob Walker commented on CONFIGURATION-837:
--
Thanks Gary - I did think that was likely to be the case. Not viable for us to
migrate at this time, but we can fix it in our own local fork.
FWIW (and for anyone else who lands here) - another option here seems to be
just to use the 2.x flavour of convertPropertiesToMap:
{code:java}
/**
* Helper method for converting the type of the {@code Properties} object
to a supported map type. As stated by the
* comment of the constructor, we expect the {@code Properties} object to
contain only String key; therefore, it is safe
* to do this cast.
*
* @param props the {@code Properties} to be copied
* @return a newly created map with all string keys of the properties
*/
@SuppressWarnings("unchecked")
private static Map convertPropertiesToMap(final Properties
props) {
@SuppressWarnings("rawtypes")
final Map map = props;
return map;
} {code}
> MapConfiguration$1 does not implement Cloneable exception
> -
>
> Key: CONFIGURATION-837
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-837
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 1.10
>Reporter: Rob Walker
>Priority: Major
> Attachments: MapConfiguration.java
>
>
> Note sure if 1.10 is actively maintained, but there's an issue with cloning
> MapConfiguration objects.
> When trying to convert using an interpolatedConfiguration:
>
> {code:java}
> Map expanded =
> ConfigurationConverter.getProperties(launchConfig.interpolatedConfiguration());
>
> {code}
> The following exception is thrown
>
> {code:java}
> org.apache.commons.configuration.ConfigurationRuntimeException:
> java.lang.reflect.InvocationTargetException at
> org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:325)
> at
> org.apache.commons.configuration.ConfigurationUtils.cloneConfiguration(ConfigurationUtils.java:282)
> at
> org.apache.commons.configuration.CombinedConfiguration.clone(CombinedConfiguration.java:670)
> at
> org.apache.commons.configuration.HierarchicalConfiguration.interpolatedConfiguration(HierarchicalConfiguration.java:937)
> at com.ascert.vt.launch.VtLauncher.launchFelix(VtLauncher.java:1220) Caused
> by: java.lang.reflect.InvocationTargetException at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:311)
> ... 7 more Caused by:
> org.apache.commons.configuration.ConfigurationRuntimeException:
> java.lang.CloneNotSupportedException:
> org.apache.commons.configuration.MapConfiguration$1 does not implement
> Cloneable at
> org.apache.commons.configuration.MapConfiguration.clone(MapConfiguration.java:249)
> ... 12 more Caused by: java.lang.CloneNotSupportedException:
> org.apache.commons.configuration.MapConfiguration$1 does not implement
> Cloneable at
> org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:330)
> at
> org.apache.commons.configuration.MapConfiguration.clone(MapConfiguration.java:242)
> ... 12 more
>
> {code}
> The issue seems to be caused by extending AbstractMap as an anyonymous return
> class. From line 253 of MapConfiguration:
>
> {code:java}
> /**
> * Helper method for copying all string keys from the given
> * {@code Properties} object to a newly created map.
> *
> * @param props the {@code Properties} to be copied
> * @return a newly created map with all string keys of the properties
> */
> private static Map convertPropertiesToMap(final
> Properties props)
> {
> return new AbstractMap() {
> @Override
> public Set> entrySet()
>
> {code}
> This class does not implement Cloneable as noted in the error message.
> Don't really know the rest of the code well enough to know whether it could
> just return a cloneable subclass here (such as HashMap) or if that's not the
> best way to go as that then becomes a mutable Map which AbstractMap is not. I
> guess another approach would be to create an inner class based on this which
> supports Cloneable and implements a manual clone() method, but nothing else.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CONFIGURATION-837) MapConfiguration$1 does not implement Cloneable exception
[
https://issues.apache.org/jira/browse/CONFIGURATION-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784972#comment-17784972
]
Rob Walker commented on CONFIGURATION-837:
--
Not proposing the attached as a proper / long term solution, but I think it
does prove the issue and solve it by creating a cloneable subclass.
[^MapConfiguration.java]
And yes, I know it's not using generics properly. I wanted to make sure I was
understanding the issue properly.
> MapConfiguration$1 does not implement Cloneable exception
> -
>
> Key: CONFIGURATION-837
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-837
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 1.10
>Reporter: Rob Walker
>Priority: Major
> Attachments: MapConfiguration.java
>
>
> Note sure if 1.10 is actively maintained, but there's an issue with cloning
> MapConfiguration objects.
> When trying to convert using an interpolatedConfiguration:
>
> {code:java}
> Map expanded =
> ConfigurationConverter.getProperties(launchConfig.interpolatedConfiguration());
>
> {code}
> The following exception is thrown
>
> {code:java}
> org.apache.commons.configuration.ConfigurationRuntimeException:
> java.lang.reflect.InvocationTargetException at
> org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:325)
> at
> org.apache.commons.configuration.ConfigurationUtils.cloneConfiguration(ConfigurationUtils.java:282)
> at
> org.apache.commons.configuration.CombinedConfiguration.clone(CombinedConfiguration.java:670)
> at
> org.apache.commons.configuration.HierarchicalConfiguration.interpolatedConfiguration(HierarchicalConfiguration.java:937)
> at com.ascert.vt.launch.VtLauncher.launchFelix(VtLauncher.java:1220) Caused
> by: java.lang.reflect.InvocationTargetException at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:311)
> ... 7 more Caused by:
> org.apache.commons.configuration.ConfigurationRuntimeException:
> java.lang.CloneNotSupportedException:
> org.apache.commons.configuration.MapConfiguration$1 does not implement
> Cloneable at
> org.apache.commons.configuration.MapConfiguration.clone(MapConfiguration.java:249)
> ... 12 more Caused by: java.lang.CloneNotSupportedException:
> org.apache.commons.configuration.MapConfiguration$1 does not implement
> Cloneable at
> org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:330)
> at
> org.apache.commons.configuration.MapConfiguration.clone(MapConfiguration.java:242)
> ... 12 more
>
> {code}
> The issue seems to be caused by extending AbstractMap as an anyonymous return
> class. From line 253 of MapConfiguration:
>
> {code:java}
> /**
> * Helper method for copying all string keys from the given
> * {@code Properties} object to a newly created map.
> *
> * @param props the {@code Properties} to be copied
> * @return a newly created map with all string keys of the properties
> */
> private static Map convertPropertiesToMap(final
> Properties props)
> {
> return new AbstractMap() {
> @Override
> public Set> entrySet()
>
> {code}
> This class does not implement Cloneable as noted in the error message.
> Don't really know the rest of the code well enough to know whether it could
> just return a cloneable subclass here (such as HashMap) or if that's not the
> best way to go as that then becomes a mutable Map which AbstractMap is not. I
> guess another approach would be to create an inner class based on this which
> supports Cloneable and implements a manual clone() method, but nothing else.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CONFIGURATION-837) MapConfiguration$1 does not implement Cloneable exception
[
https://issues.apache.org/jira/browse/CONFIGURATION-837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Walker updated CONFIGURATION-837:
-
Attachment: MapConfiguration.java
> MapConfiguration$1 does not implement Cloneable exception
> -
>
> Key: CONFIGURATION-837
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-837
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 1.10
>Reporter: Rob Walker
>Priority: Major
> Attachments: MapConfiguration.java
>
>
> Note sure if 1.10 is actively maintained, but there's an issue with cloning
> MapConfiguration objects.
> When trying to convert using an interpolatedConfiguration:
>
> {code:java}
> Map expanded =
> ConfigurationConverter.getProperties(launchConfig.interpolatedConfiguration());
>
> {code}
> The following exception is thrown
>
> {code:java}
> org.apache.commons.configuration.ConfigurationRuntimeException:
> java.lang.reflect.InvocationTargetException at
> org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:325)
> at
> org.apache.commons.configuration.ConfigurationUtils.cloneConfiguration(ConfigurationUtils.java:282)
> at
> org.apache.commons.configuration.CombinedConfiguration.clone(CombinedConfiguration.java:670)
> at
> org.apache.commons.configuration.HierarchicalConfiguration.interpolatedConfiguration(HierarchicalConfiguration.java:937)
> at com.ascert.vt.launch.VtLauncher.launchFelix(VtLauncher.java:1220) Caused
> by: java.lang.reflect.InvocationTargetException at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:311)
> ... 7 more Caused by:
> org.apache.commons.configuration.ConfigurationRuntimeException:
> java.lang.CloneNotSupportedException:
> org.apache.commons.configuration.MapConfiguration$1 does not implement
> Cloneable at
> org.apache.commons.configuration.MapConfiguration.clone(MapConfiguration.java:249)
> ... 12 more Caused by: java.lang.CloneNotSupportedException:
> org.apache.commons.configuration.MapConfiguration$1 does not implement
> Cloneable at
> org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:330)
> at
> org.apache.commons.configuration.MapConfiguration.clone(MapConfiguration.java:242)
> ... 12 more
>
> {code}
> The issue seems to be caused by extending AbstractMap as an anyonymous return
> class. From line 253 of MapConfiguration:
>
> {code:java}
> /**
> * Helper method for copying all string keys from the given
> * {@code Properties} object to a newly created map.
> *
> * @param props the {@code Properties} to be copied
> * @return a newly created map with all string keys of the properties
> */
> private static Map convertPropertiesToMap(final
> Properties props)
> {
> return new AbstractMap() {
> @Override
> public Set> entrySet()
>
> {code}
> This class does not implement Cloneable as noted in the error message.
> Don't really know the rest of the code well enough to know whether it could
> just return a cloneable subclass here (such as HashMap) or if that's not the
> best way to go as that then becomes a mutable Map which AbstractMap is not. I
> guess another approach would be to create an inner class based on this which
> supports Cloneable and implements a manual clone() method, but nothing else.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CONFIGURATION-837) MapConfiguration$1 does not implement Cloneable exception
[
https://issues.apache.org/jira/browse/CONFIGURATION-837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Walker updated CONFIGURATION-837:
-
Description:
Note sure if 1.10 is actively maintained, but there's an issue with cloning
MapConfiguration objects.
When trying to convert using an interpolatedConfiguration:
{code:java}
Map expanded =
ConfigurationConverter.getProperties(launchConfig.interpolatedConfiguration());
{code}
The following exception is thrown
{code:java}
org.apache.commons.configuration.ConfigurationRuntimeException:
java.lang.reflect.InvocationTargetException at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:325)
at
org.apache.commons.configuration.ConfigurationUtils.cloneConfiguration(ConfigurationUtils.java:282)
at
org.apache.commons.configuration.CombinedConfiguration.clone(CombinedConfiguration.java:670)
at
org.apache.commons.configuration.HierarchicalConfiguration.interpolatedConfiguration(HierarchicalConfiguration.java:937)
at com.ascert.vt.launch.VtLauncher.launchFelix(VtLauncher.java:1220) Caused
by: java.lang.reflect.InvocationTargetException at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:311)
... 7 more Caused by:
org.apache.commons.configuration.ConfigurationRuntimeException:
java.lang.CloneNotSupportedException:
org.apache.commons.configuration.MapConfiguration$1 does not implement
Cloneable at
org.apache.commons.configuration.MapConfiguration.clone(MapConfiguration.java:249)
... 12 more Caused by: java.lang.CloneNotSupportedException:
org.apache.commons.configuration.MapConfiguration$1 does not implement
Cloneable at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:330)
at
org.apache.commons.configuration.MapConfiguration.clone(MapConfiguration.java:242)
... 12 more
{code}
The issue seems to be caused by extending AbstractMap as an anyonymous return
class. From line 253 of MapConfiguration:
{code:java}
/**
* Helper method for copying all string keys from the given
* {@code Properties} object to a newly created map.
*
* @param props the {@code Properties} to be copied
* @return a newly created map with all string keys of the properties
*/
private static Map convertPropertiesToMap(final Properties
props)
{
return new AbstractMap() {
@Override
public Set> entrySet()
{code}
This class does not implement Cloneable as noted in the error message.
Don't really know the rest of the code well enough to know whether it could
just return a cloneable subclass here (such as HashMap) or if that's not the
best way to go as that then becomes a mutable Map which AbstractMap is not. I
guess another approach would be to create an inner class based on this which
supports Cloneable and implements a manual clone() method, but nothing else.
was:
Note sure if 1.10 is actively maintained, but there's an issue with cloning
MapConfiguration objects.
When trying to convert using an interpolatedConfiguration:
{code:java}
Map expanded =
ConfigurationConverter.getProperties(launchConfig.interpolatedConfiguration());
{code}
The following exception is thrown
{code:java}
org.apache.commons.configuration.ConfigurationRuntimeException:
java.lang.reflect.InvocationTargetException at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:325)
at
org.apache.commons.configuration.ConfigurationUtils.cloneConfiguration(ConfigurationUtils.java:282)
at
org.apache.commons.configuration.CombinedConfiguration.clone(CombinedConfiguration.java:670)
at
org.apache.commons.configuration.HierarchicalConfiguration.interpolatedConfiguration(HierarchicalConfiguration.java:937)
at com.ascert.vt.launch.VtLauncher.launchFelix(VtLauncher.java:1220) Caused
by: java.lang.reflect.InvocationTargetException at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:311)
... 7 more Caused by:
org.apache.commons.configuration.ConfigurationRuntimeException:
java.lang.CloneNotSupportedException:
[jira] [Updated] (CONFIGURATION-837) MapConfiguration$1 does not implement Cloneable exception
[
https://issues.apache.org/jira/browse/CONFIGURATION-837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Walker updated CONFIGURATION-837:
-
Description:
Note sure if 1.10 is actively maintained, but there's an issue with cloning
MapConfiguration objects.
When trying to convert using an interpolatedConfiguration:
{code:java}
Map expanded =
ConfigurationConverter.getProperties(launchConfig.interpolatedConfiguration());
{code}
The following exception is thrown
{code:java}
org.apache.commons.configuration.ConfigurationRuntimeException:
java.lang.reflect.InvocationTargetException at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:325)
at
org.apache.commons.configuration.ConfigurationUtils.cloneConfiguration(ConfigurationUtils.java:282)
at
org.apache.commons.configuration.CombinedConfiguration.clone(CombinedConfiguration.java:670)
at
org.apache.commons.configuration.HierarchicalConfiguration.interpolatedConfiguration(HierarchicalConfiguration.java:937)
at com.ascert.vt.launch.VtLauncher.launchFelix(VtLauncher.java:1220) Caused
by: java.lang.reflect.InvocationTargetException at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:311)
... 7 more Caused by:
org.apache.commons.configuration.ConfigurationRuntimeException:
java.lang.CloneNotSupportedException:
org.apache.commons.configuration.MapConfiguration$1 does not implement
Cloneable at
org.apache.commons.configuration.MapConfiguration.clone(MapConfiguration.java:249)
... 12 more Caused by: java.lang.CloneNotSupportedException:
org.apache.commons.configuration.MapConfiguration$1 does not implement
Cloneable at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:330)
at
org.apache.commons.configuration.MapConfiguration.clone(MapConfiguration.java:242)
... 12 more
{code}
The issue seems to be caused by extending AbstractMap as an anyonymous return
class. From line 253 of MapConfiguration:
{code:java}
/**
* Helper method for copying all string keys from the given
* {@code Properties} object to a newly created map.
*
* @param props the {@code Properties} to be copied
* @return a newly created map with all string keys of the properties
*/
private static Map convertPropertiesToMap(final Properties
props)
{
return new AbstractMap() {
@Override
public Set> entrySet()
{code}
This class does not implement Cloneable as noted in the error message.
Don't really know the rest of the code well enough to know whether it could
just return a cloneable subclass here (such as HashMap) or if that's not the
best way to go as that then becomes a mutable Map which AbstractMap is not.
was:
Note sure if 1.10 is actively maintained, but there's an issue with cloning
MapConfiguration objects.
When trying to convert using an interpolatedConfiguration:
{code:java}
Map expanded =
ConfigurationConverter.getProperties(launchConfig.interpolatedConfiguration());
{code}
The following exception is thrown
{code:java}
org.apache.commons.configuration.ConfigurationRuntimeException:
java.lang.reflect.InvocationTargetException at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:325)
at
org.apache.commons.configuration.ConfigurationUtils.cloneConfiguration(ConfigurationUtils.java:282)
at
org.apache.commons.configuration.CombinedConfiguration.clone(CombinedConfiguration.java:670)
at
org.apache.commons.configuration.HierarchicalConfiguration.interpolatedConfiguration(HierarchicalConfiguration.java:937)
at com.ascert.vt.launch.VtLauncher.launchFelix(VtLauncher.java:1220) Caused
by: java.lang.reflect.InvocationTargetException at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:311)
... 7 more Caused by:
org.apache.commons.configuration.ConfigurationRuntimeException:
java.lang.CloneNotSupportedException:
org.apache.commons.configuration.MapConfiguration$1 does not implement
Cloneable at
org.apache.commons.configuration.MapConfiguration.clone(MapConfiguration.java:249)
... 12 more Caused by:
[jira] [Updated] (CONFIGURATION-837) MapConfiguration$1 does not implement Cloneable exception
[
https://issues.apache.org/jira/browse/CONFIGURATION-837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Walker updated CONFIGURATION-837:
-
Description:
Note sure if 1.10 is actively maintained, but there's an issue with cloning
MapConfiguration objects.
When trying to convert using an interpolatedConfiguration:
{code:java}
Map expanded =
ConfigurationConverter.getProperties(launchConfig.interpolatedConfiguration());
{code}
The following exception is thrown
{code:java}
org.apache.commons.configuration.ConfigurationRuntimeException:
java.lang.reflect.InvocationTargetException at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:325)
at
org.apache.commons.configuration.ConfigurationUtils.cloneConfiguration(ConfigurationUtils.java:282)
at
org.apache.commons.configuration.CombinedConfiguration.clone(CombinedConfiguration.java:670)
at
org.apache.commons.configuration.HierarchicalConfiguration.interpolatedConfiguration(HierarchicalConfiguration.java:937)
at com.ascert.vt.launch.VtLauncher.launchFelix(VtLauncher.java:1220) Caused
by: java.lang.reflect.InvocationTargetException at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:311)
... 7 more Caused by:
org.apache.commons.configuration.ConfigurationRuntimeException:
java.lang.CloneNotSupportedException:
org.apache.commons.configuration.MapConfiguration$1 does not implement
Cloneable at
org.apache.commons.configuration.MapConfiguration.clone(MapConfiguration.java:249)
... 12 more Caused by: java.lang.CloneNotSupportedException:
org.apache.commons.configuration.MapConfiguration$1 does not implement
Cloneable at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:330)
at
org.apache.commons.configuration.MapConfiguration.clone(MapConfiguration.java:242)
... 12 more
{code}
The issue seems to be caused by extending AbstractMap as an anyonymous return
class. From line 253 of MapConfiguration:
{code:java}
/**
* Helper method for copying all string keys from the given
* {@code Properties} object to a newly created map.
*
* @param props the {@code Properties} to be copied
* @return a newly created map with all string keys of the properties
*/
private static Map convertPropertiesToMap(final Properties
props)
{
return new AbstractMap() { @Override
public Set> entrySet()
{code}
This class does not implement Cloneable as noted in the error message. Just
looking for a decent solution, but returning some inner subclass which supports
cloneable seems the way to go.
was:
Note sure if 1.10 is actively maintained, but there's an issue with cloning
MapConfiguration objects.
When trying to convert using an interpolatedConfiguration:
{{Map expanded =
ConfigurationConverter.getProperties(launchConfig.interpolatedConfiguration());}}
The following exception is thrown
{{org.apache.commons.configuration.ConfigurationRuntimeException:
java.lang.reflect.InvocationTargetException at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:325)
at
org.apache.commons.configuration.ConfigurationUtils.cloneConfiguration(ConfigurationUtils.java:282)
at
org.apache.commons.configuration.CombinedConfiguration.clone(CombinedConfiguration.java:670)
at
org.apache.commons.configuration.HierarchicalConfiguration.interpolatedConfiguration(HierarchicalConfiguration.java:937)
at com.ascert.vt.launch.VtLauncher.launchFelix(VtLauncher.java:1220) Caused
by: java.lang.reflect.InvocationTargetException at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:311)
... 7 more Caused by:
org.apache.commons.configuration.ConfigurationRuntimeException:
java.lang.CloneNotSupportedException:
org.apache.commons.configuration.MapConfiguration$1 does not implement
Cloneable at
org.apache.commons.configuration.MapConfiguration.clone(MapConfiguration.java:249)
... 12 more Caused by: java.lang.CloneNotSupportedException:
org.apache.commons.configuration.MapConfiguration$1 does not implement
Cloneable at
[jira] [Updated] (CONFIGURATION-837) MapConfiguration$1 does not implement Cloneable exception
[
https://issues.apache.org/jira/browse/CONFIGURATION-837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Walker updated CONFIGURATION-837:
-
Description:
Note sure if 1.10 is actively maintained, but there's an issue with cloning
MapConfiguration objects.
When trying to convert using an interpolatedConfiguration:
{code:java}
Map expanded =
ConfigurationConverter.getProperties(launchConfig.interpolatedConfiguration());
{code}
The following exception is thrown
{code:java}
org.apache.commons.configuration.ConfigurationRuntimeException:
java.lang.reflect.InvocationTargetException at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:325)
at
org.apache.commons.configuration.ConfigurationUtils.cloneConfiguration(ConfigurationUtils.java:282)
at
org.apache.commons.configuration.CombinedConfiguration.clone(CombinedConfiguration.java:670)
at
org.apache.commons.configuration.HierarchicalConfiguration.interpolatedConfiguration(HierarchicalConfiguration.java:937)
at com.ascert.vt.launch.VtLauncher.launchFelix(VtLauncher.java:1220) Caused
by: java.lang.reflect.InvocationTargetException at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:311)
... 7 more Caused by:
org.apache.commons.configuration.ConfigurationRuntimeException:
java.lang.CloneNotSupportedException:
org.apache.commons.configuration.MapConfiguration$1 does not implement
Cloneable at
org.apache.commons.configuration.MapConfiguration.clone(MapConfiguration.java:249)
... 12 more Caused by: java.lang.CloneNotSupportedException:
org.apache.commons.configuration.MapConfiguration$1 does not implement
Cloneable at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:330)
at
org.apache.commons.configuration.MapConfiguration.clone(MapConfiguration.java:242)
... 12 more
{code}
The issue seems to be caused by extending AbstractMap as an anyonymous return
class. From line 253 of MapConfiguration:
{code:java}
/**
* Helper method for copying all string keys from the given
* {@code Properties} object to a newly created map.
*
* @param props the {@code Properties} to be copied
* @return a newly created map with all string keys of the properties
*/
private static Map convertPropertiesToMap(final Properties
props)
{
return new AbstractMap() {
@Override
public Set> entrySet()
{code}
This class does not implement Cloneable as noted in the error message. Just
looking for a decent solution, but returning some inner subclass which supports
cloneable seems the way to go.
was:
Note sure if 1.10 is actively maintained, but there's an issue with cloning
MapConfiguration objects.
When trying to convert using an interpolatedConfiguration:
{code:java}
Map expanded =
ConfigurationConverter.getProperties(launchConfig.interpolatedConfiguration());
{code}
The following exception is thrown
{code:java}
org.apache.commons.configuration.ConfigurationRuntimeException:
java.lang.reflect.InvocationTargetException at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:325)
at
org.apache.commons.configuration.ConfigurationUtils.cloneConfiguration(ConfigurationUtils.java:282)
at
org.apache.commons.configuration.CombinedConfiguration.clone(CombinedConfiguration.java:670)
at
org.apache.commons.configuration.HierarchicalConfiguration.interpolatedConfiguration(HierarchicalConfiguration.java:937)
at com.ascert.vt.launch.VtLauncher.launchFelix(VtLauncher.java:1220) Caused
by: java.lang.reflect.InvocationTargetException at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:311)
... 7 more Caused by:
org.apache.commons.configuration.ConfigurationRuntimeException:
java.lang.CloneNotSupportedException:
org.apache.commons.configuration.MapConfiguration$1 does not implement
Cloneable at
org.apache.commons.configuration.MapConfiguration.clone(MapConfiguration.java:249)
... 12 more Caused by: java.lang.CloneNotSupportedException:
org.apache.commons.configuration.MapConfiguration$1 does not implement
Cloneable at
[jira] [Created] (CONFIGURATION-837) MapConfiguration$1 does not implement Cloneable exception
Rob Walker created CONFIGURATION-837:
Summary: MapConfiguration$1 does not implement Cloneable exception
Key: CONFIGURATION-837
URL: https://issues.apache.org/jira/browse/CONFIGURATION-837
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.10
Reporter: Rob Walker
Note sure if 1.10 is actively maintained, but there's an issue with cloning
MapConfiguration objects.
When trying to convert using an interpolatedConfiguration:
{{Map expanded =
ConfigurationConverter.getProperties(launchConfig.interpolatedConfiguration());}}
The following exception is thrown
{{org.apache.commons.configuration.ConfigurationRuntimeException:
java.lang.reflect.InvocationTargetException at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:325)
at
org.apache.commons.configuration.ConfigurationUtils.cloneConfiguration(ConfigurationUtils.java:282)
at
org.apache.commons.configuration.CombinedConfiguration.clone(CombinedConfiguration.java:670)
at
org.apache.commons.configuration.HierarchicalConfiguration.interpolatedConfiguration(HierarchicalConfiguration.java:937)
at com.ascert.vt.launch.VtLauncher.launchFelix(VtLauncher.java:1220) Caused
by: java.lang.reflect.InvocationTargetException at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:311)
... 7 more Caused by:
org.apache.commons.configuration.ConfigurationRuntimeException:
java.lang.CloneNotSupportedException:
org.apache.commons.configuration.MapConfiguration$1 does not implement
Cloneable at
org.apache.commons.configuration.MapConfiguration.clone(MapConfiguration.java:249)
... 12 more Caused by: java.lang.CloneNotSupportedException:
org.apache.commons.configuration.MapConfiguration$1 does not implement
Cloneable at
org.apache.commons.configuration.ConfigurationUtils.clone(ConfigurationUtils.java:330)
at
org.apache.commons.configuration.MapConfiguration.clone(MapConfiguration.java:242)
... 12 more}}
The issue seems to be caused by extending AbstractMap as an anyonymous return
class. From line 253 of MapConfiguration:
{{ /**}}
{{ * Helper method for copying all string keys from the given}}
{{ * \{@code Properties} object to a newly created map.}}
{{ *}}
{{ * @param props the \{@code Properties} to be copied}}
{{ * @return a newly created map with all string keys of the properties}}
{{ */}}
{{ private static Map convertPropertiesToMap(final
Properties props)}}
{{ {}}
{{ return new AbstractMap() {}}{{ @Override}}
{{ public Set> entrySet()}}
This class does not implement Cloneable as noted in the error message. Just
looking for a decent solution, but returning some inner subclass which supports
cloneable seems the way to go.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CONFIGURATION-572) Possibe memory leak when using CombinedConfiguration
[ https://issues.apache.org/jira/browse/CONFIGURATION-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Walker updated CONFIGURATION-572: - Attachment: 2960.patch Possibe memory leak when using CombinedConfiguration Key: CONFIGURATION-572 URL: https://issues.apache.org/jira/browse/CONFIGURATION-572 Project: Commons Configuration Issue Type: Bug Reporter: Rob Walker Priority: Minor Attachments: 2960.patch We altered our code to use CombinedConfiguration in a more dynamic way and immediately started to see large memory usage. Looking for a potential leak, we realised we were missing a clear() when the config objects were done with. Even with this call in, the leak persisted. It seems that whilst the clear() method cleans up the object, it doesn't clear the listener list as well. This leaves around stale references which then never become GC. Will attach the patch we found worked at curing this -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CONFIGURATION-572) Possibe memory leak when using CombinedConfiguration
Rob Walker created CONFIGURATION-572: Summary: Possibe memory leak when using CombinedConfiguration Key: CONFIGURATION-572 URL: https://issues.apache.org/jira/browse/CONFIGURATION-572 Project: Commons Configuration Issue Type: Bug Reporter: Rob Walker Priority: Minor We altered our code to use CombinedConfiguration in a more dynamic way and immediately started to see large memory usage. Looking for a potential leak, we realised we were missing a clear() when the config objects were done with. Even with this call in, the leak persisted. It seems that whilst the clear() method cleans up the object, it doesn't clear the listener list as well. This leaves around stale references which then never become GC. Will attach the patch we found worked at curing this -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] Closed: (LANG-482) Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
[
https://issues.apache.org/jira/browse/LANG-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Walker closed LANG-482.
---
Fix seems to work fine in our sandbox. Won't be able to fully roll out into our
full env until beta-3.0 is usable with Commons Configuration.
Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
--
Key: LANG-482
URL: https://issues.apache.org/jira/browse/LANG-482
Project: Commons Lang
Issue Type: Improvement
Components: lang.text.*
Reporter: Rob Walker
Priority: Minor
Fix For: 3.0
Attachments: lang-482.diff, StrSubstitutor.java.nested.patch
t would be really handy of StrSubstitutor could support nested variable
interpolation:
org.osgi.framework.system.packages=org.osgi.framework; version=1.4.0, \
org.osgi.service.packageadmin; version=1.2.0, \
org.osgi.service.startlevel; version=1.1.0, \
org.osgi.service.url; version=1.0.0, \
org.osgi.util.tracker; version=1.3.3 \
${jre-${java.specification.version}}
The process being to expand innermost variable references first and work
outwards - this allows for very advance config, such as the above, which can
dynamically detect the Java version and expand a JRE version specific
property into the property being defined.
Looking at the implementation, it seems it might be a fairly straightforward
enhancement to:
private int substitute(StrBuilder buf, int offset, int length, List
priorVariables)
The code already has the cyclic map in place.
I already have code that achieves this within Apache Felix, so I will see if
I can retro-fit a similar model to the above and if so submit a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-482) Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
[
https://issues.apache.org/jira/browse/LANG-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12917496#action_12917496
]
Rob Walker commented on LANG-482:
-
Nice one Oliver, well done. Sorry you beat me to this - been on my when I get
time list for ages, but I never have any time!
Will either give the patch a try here in our local install at some stage or
update our install to latest codebase if it gets accepted and merged in before
then.
Not sure it matters to us either way on constructor vs setter/getter approach -
as long as we can enable the nesting option when used in Commons Config somehow.
Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
--
Key: LANG-482
URL: https://issues.apache.org/jira/browse/LANG-482
Project: Commons Lang
Issue Type: Improvement
Components: lang.text.*
Reporter: Rob Walker
Priority: Minor
Fix For: 3.1
Attachments: lang-482.diff, StrSubstitutor.java.nested.patch
t would be really handy of StrSubstitutor could support nested variable
interpolation:
org.osgi.framework.system.packages=org.osgi.framework; version=1.4.0, \
org.osgi.service.packageadmin; version=1.2.0, \
org.osgi.service.startlevel; version=1.1.0, \
org.osgi.service.url; version=1.0.0, \
org.osgi.util.tracker; version=1.3.3 \
${jre-${java.specification.version}}
The process being to expand innermost variable references first and work
outwards - this allows for very advance config, such as the above, which can
dynamically detect the Java version and expand a JRE version specific
property into the property being defined.
Looking at the implementation, it seems it might be a fairly straightforward
enhancement to:
private int substitute(StrBuilder buf, int offset, int length, List
priorVariables)
The code already has the cyclic map in place.
I already have code that achieves this within Apache Felix, so I will see if
I can retro-fit a similar model to the above and if so submit a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-482) Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
[
https://issues.apache.org/jira/browse/LANG-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839833#action_12839833
]
Rob Walker commented on LANG-482:
-
We find them useful and use them extensively. If others have objections to them
or don't find them useful, it's not really a big deal for us. We've got this
work applied to our locally customised version anyhow, so we'll just keep
re-applying it whenever we upgrade the root Apache version.
Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
--
Key: LANG-482
URL: https://issues.apache.org/jira/browse/LANG-482
Project: Commons Lang
Issue Type: Improvement
Components: lang.text.*
Reporter: Rob Walker
Priority: Minor
Fix For: 3.1
Attachments: StrSubstitutor.java.nested.patch
t would be really handy of StrSubstitutor could support nested variable
interpolation:
org.osgi.framework.system.packages=org.osgi.framework; version=1.4.0, \
org.osgi.service.packageadmin; version=1.2.0, \
org.osgi.service.startlevel; version=1.1.0, \
org.osgi.service.url; version=1.0.0, \
org.osgi.util.tracker; version=1.3.3 \
${jre-${java.specification.version}}
The process being to expand innermost variable references first and work
outwards - this allows for very advance config, such as the above, which can
dynamically detect the Java version and expand a JRE version specific
property into the property being defined.
Looking at the implementation, it seems it might be a fairly straightforward
enhancement to:
private int substitute(StrBuilder buf, int offset, int length, List
priorVariables)
The code already has the cyclic map in place.
I already have code that achieves this within Apache Felix, so I will see if
I can retro-fit a similar model to the above and if so submit a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-482) Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
[
https://issues.apache.org/jira/browse/LANG-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12840022#action_12840022
]
Rob Walker commented on LANG-482:
-
Sounds good Paul, thanks for clarifying
- Rob
Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
--
Key: LANG-482
URL: https://issues.apache.org/jira/browse/LANG-482
Project: Commons Lang
Issue Type: Improvement
Components: lang.text.*
Reporter: Rob Walker
Priority: Minor
Fix For: 3.1
Attachments: StrSubstitutor.java.nested.patch
t would be really handy of StrSubstitutor could support nested variable
interpolation:
org.osgi.framework.system.packages=org.osgi.framework; version=1.4.0, \
org.osgi.service.packageadmin; version=1.2.0, \
org.osgi.service.startlevel; version=1.1.0, \
org.osgi.service.url; version=1.0.0, \
org.osgi.util.tracker; version=1.3.3 \
${jre-${java.specification.version}}
The process being to expand innermost variable references first and work
outwards - this allows for very advance config, such as the above, which can
dynamically detect the Java version and expand a JRE version specific
property into the property being defined.
Looking at the implementation, it seems it might be a fairly straightforward
enhancement to:
private int substitute(StrBuilder buf, int offset, int length, List
priorVariables)
The code already has the cyclic map in place.
I already have code that achieves this within Apache Felix, so I will see if
I can retro-fit a similar model to the above and if so submit a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONFIGURATION-404) Revisit - Brackets in property key causes NumberFormatException
[ https://issues.apache.org/jira/browse/CONFIGURATION-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12805488#action_12805488 ] Rob Walker commented on CONFIGURATION-404: -- Great, thanks Oliver. I can move us back the official SVN rev here and remove our local patch. Good news. Revisit - Brackets in property key causes NumberFormatException --- Key: CONFIGURATION-404 URL: https://issues.apache.org/jira/browse/CONFIGURATION-404 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.5 Reporter: Rob Walker Assignee: Oliver Heger Fix For: 1.7 Attachments: DefaultConfigurationKey.java-NFE.patch, DefaultConfigurationKey.java.patch Hi, When using brackets in property key we get an exception every time. Escaping brackets with \ doesn't help. Example #property in property file test(ef)=false causes java.lang.NumberFormatException: For input string: ef at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Integer.parseInt(Integer.java:447) at java.lang.Integer.parseInt(Integer.java:497) at org.apache.commons.configuration.tree.DefaultConfigurationKey $KeyIterator.checkIndex(DefaultConfigurationKey.java:834) at org.apache.commons.configuration.tree.DefaultConfigurationKey $KeyIterator.nextKey(DefaultConfigurationKey.java:511) at org.apache.commons.configuration.tree.DefaultExpressionEngine.findNodesForKey(DefaultExpressionEngine.java:462) at org.apache.commons.configuration.tree.DefaultExpressionEngine.query(DefaultExpressionEngine.java:286) at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:925 at org.apache.commons.configuration.HierarchicalConfiguration.setProperty(HierarchicalConfiguration.java:735) at org.apache.commons.configuration.ConfigurationUtils.copy(ConfigurationUtils.java:143) at org.apache.commons.configuration.ConfigurationUtils.convertToHierarchical(ConfigurationUtils.java:199) at org.apache.commons.configuration.CombinedConfiguration $ConfigData.getTransformedRoot(CombinedConfiguration.java:794) at org.apache.commons.configuration.CombinedConfiguration.constructCombinedNode(CombinedConfiguration.java:653) at org.apache.commons.configuration.CombinedConfiguration.getRootNode(CombinedConfiguration.java:504) at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:925) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:327) at org.apache.commons.configuration.CombinedConfiguration.getProperty(CombinedConfiguration.java:578) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1155) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1034) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1017) Explanation i got in mailing list from Oliver Heger I guess you use DefaultConfigurationBuilder for loading a combined configuration? The exception is due to the fact that brackets have a special meaning in the query syntax for hierarchical configurations. (DefaultConfigurationBuilder transforms all configuration sources into hierarchical configurations, so also for properties, which are not hierarchical by default, the same rules apply.) So far escaping brackets or other specific characters in property keys is not supported. It seems to be rather unusual to use brackets in property keys, so you may well be the first one who noticed this problem. Unfortunately I don't have a working solution for this problem right now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CONFIGURATION-404) Revisit - Brackets in property key causes NumberFormatException
[ https://issues.apache.org/jira/browse/CONFIGURATION-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Walker updated CONFIGURATION-404: - Attachment: DefaultConfigurationKey.java.patch Hope the attached patch is better - did it in SVN this time. I think I must have used Winmerge for the previous one. Revisit - Brackets in property key causes NumberFormatException --- Key: CONFIGURATION-404 URL: https://issues.apache.org/jira/browse/CONFIGURATION-404 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.5 Reporter: Rob Walker Assignee: Oliver Heger Fix For: 1.6 Attachments: DefaultConfigurationKey.java-NFE.patch, DefaultConfigurationKey.java.patch Hi, When using brackets in property key we get an exception every time. Escaping brackets with \ doesn't help. Example #property in property file test(ef)=false causes java.lang.NumberFormatException: For input string: ef at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Integer.parseInt(Integer.java:447) at java.lang.Integer.parseInt(Integer.java:497) at org.apache.commons.configuration.tree.DefaultConfigurationKey $KeyIterator.checkIndex(DefaultConfigurationKey.java:834) at org.apache.commons.configuration.tree.DefaultConfigurationKey $KeyIterator.nextKey(DefaultConfigurationKey.java:511) at org.apache.commons.configuration.tree.DefaultExpressionEngine.findNodesForKey(DefaultExpressionEngine.java:462) at org.apache.commons.configuration.tree.DefaultExpressionEngine.query(DefaultExpressionEngine.java:286) at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:925 at org.apache.commons.configuration.HierarchicalConfiguration.setProperty(HierarchicalConfiguration.java:735) at org.apache.commons.configuration.ConfigurationUtils.copy(ConfigurationUtils.java:143) at org.apache.commons.configuration.ConfigurationUtils.convertToHierarchical(ConfigurationUtils.java:199) at org.apache.commons.configuration.CombinedConfiguration $ConfigData.getTransformedRoot(CombinedConfiguration.java:794) at org.apache.commons.configuration.CombinedConfiguration.constructCombinedNode(CombinedConfiguration.java:653) at org.apache.commons.configuration.CombinedConfiguration.getRootNode(CombinedConfiguration.java:504) at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:925) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:327) at org.apache.commons.configuration.CombinedConfiguration.getProperty(CombinedConfiguration.java:578) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1155) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1034) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1017) Explanation i got in mailing list from Oliver Heger I guess you use DefaultConfigurationBuilder for loading a combined configuration? The exception is due to the fact that brackets have a special meaning in the query syntax for hierarchical configurations. (DefaultConfigurationBuilder transforms all configuration sources into hierarchical configurations, so also for properties, which are not hierarchical by default, the same rules apply.) So far escaping brackets or other specific characters in property keys is not supported. It seems to be rather unusual to use brackets in property keys, so you may well be the first one who noticed this problem. Unfortunately I don't have a working solution for this problem right now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONFIGURATION-404) Revisit - Brackets in property key causes NumberFormatException
[ https://issues.apache.org/jira/browse/CONFIGURATION-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12804406#action_12804406 ] Rob Walker commented on CONFIGURATION-404: -- Oliver - hope the new patch is usable. I'm not so familiar with the unit test architecture, but it should be pretty simple - just include property with brackets in and make sure it doesn't throw a NumberFormatException. The specific Windows Vista/7 ones that trip this now are system properties like C:\Program Files(x86) Revisit - Brackets in property key causes NumberFormatException --- Key: CONFIGURATION-404 URL: https://issues.apache.org/jira/browse/CONFIGURATION-404 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.5 Reporter: Rob Walker Assignee: Oliver Heger Fix For: 1.6 Attachments: DefaultConfigurationKey.java-NFE.patch, DefaultConfigurationKey.java.patch Hi, When using brackets in property key we get an exception every time. Escaping brackets with \ doesn't help. Example #property in property file test(ef)=false causes java.lang.NumberFormatException: For input string: ef at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Integer.parseInt(Integer.java:447) at java.lang.Integer.parseInt(Integer.java:497) at org.apache.commons.configuration.tree.DefaultConfigurationKey $KeyIterator.checkIndex(DefaultConfigurationKey.java:834) at org.apache.commons.configuration.tree.DefaultConfigurationKey $KeyIterator.nextKey(DefaultConfigurationKey.java:511) at org.apache.commons.configuration.tree.DefaultExpressionEngine.findNodesForKey(DefaultExpressionEngine.java:462) at org.apache.commons.configuration.tree.DefaultExpressionEngine.query(DefaultExpressionEngine.java:286) at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:925 at org.apache.commons.configuration.HierarchicalConfiguration.setProperty(HierarchicalConfiguration.java:735) at org.apache.commons.configuration.ConfigurationUtils.copy(ConfigurationUtils.java:143) at org.apache.commons.configuration.ConfigurationUtils.convertToHierarchical(ConfigurationUtils.java:199) at org.apache.commons.configuration.CombinedConfiguration $ConfigData.getTransformedRoot(CombinedConfiguration.java:794) at org.apache.commons.configuration.CombinedConfiguration.constructCombinedNode(CombinedConfiguration.java:653) at org.apache.commons.configuration.CombinedConfiguration.getRootNode(CombinedConfiguration.java:504) at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:925) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:327) at org.apache.commons.configuration.CombinedConfiguration.getProperty(CombinedConfiguration.java:578) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1155) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1034) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1017) Explanation i got in mailing list from Oliver Heger I guess you use DefaultConfigurationBuilder for loading a combined configuration? The exception is due to the fact that brackets have a special meaning in the query syntax for hierarchical configurations. (DefaultConfigurationBuilder transforms all configuration sources into hierarchical configurations, so also for properties, which are not hierarchical by default, the same rules apply.) So far escaping brackets or other specific characters in property keys is not supported. It seems to be rather unusual to use brackets in property keys, so you may well be the first one who noticed this problem. Unfortunately I don't have a working solution for this problem right now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONFIGURATION-336) Brackets in property key causes NumberFormatException
[
https://issues.apache.org/jira/browse/CONFIGURATION-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800203#action_12800203
]
Rob Walker commented on CONFIGURATION-336:
--
The fixes above provide a workaround, but it's not exactly a low pain / low
effort option, and is made harder by a lot of use of private methods in
DefaultConfigurationKey etc preventing a simple subclassing approach.
I suspect it's going to become a bigger issue for more people too, since Vista
and Windows 7 both have additional environment/path variables that break this
e.g.
ProgamFiles(x86)
It seems a small and simple fix to DefaultConfigurationKey.KeyIterator could
take away a ton of pain for the simple case e.g.
private boolean checkIndex(String key)
{
boolean result = false;
try
{
int idx =
key.lastIndexOf(getExpressionEngine().getIndexStart());
if (idx 0)
{
int endidx =
key.indexOf(getExpressionEngine().getIndexEnd(),
idx);
if (endidx idx + 1)
{
indexValue = Integer.parseInt(key.substring(idx + 1,
endidx));
current = key.substring(0, idx);
result = true;
}
}
}
catch (NumberFormatException nfe)
{
result = false;
}
return result;
}
Brackets in property key causes NumberFormatException
-
Key: CONFIGURATION-336
URL: https://issues.apache.org/jira/browse/CONFIGURATION-336
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.5
Reporter: Pavel Savara
Assignee: Oliver Heger
Fix For: 1.6
Hi,
When using brackets in property key we get an exception every time.
Escaping brackets with \ doesn't help.
Example
#property in property file
test(ef)=false
causes
java.lang.NumberFormatException: For input string: ef at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:447)
at java.lang.Integer.parseInt(Integer.java:497)
at org.apache.commons.configuration.tree.DefaultConfigurationKey
$KeyIterator.checkIndex(DefaultConfigurationKey.java:834)
at org.apache.commons.configuration.tree.DefaultConfigurationKey
$KeyIterator.nextKey(DefaultConfigurationKey.java:511) at
org.apache.commons.configuration.tree.DefaultExpressionEngine.findNodesForKey(DefaultExpressionEngine.java:462)
at
org.apache.commons.configuration.tree.DefaultExpressionEngine.query(DefaultExpressionEngine.java:286)
at
org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:925
at
org.apache.commons.configuration.HierarchicalConfiguration.setProperty(HierarchicalConfiguration.java:735)
at
org.apache.commons.configuration.ConfigurationUtils.copy(ConfigurationUtils.java:143)
at
org.apache.commons.configuration.ConfigurationUtils.convertToHierarchical(ConfigurationUtils.java:199)
at org.apache.commons.configuration.CombinedConfiguration
$ConfigData.getTransformedRoot(CombinedConfiguration.java:794) at
org.apache.commons.configuration.CombinedConfiguration.constructCombinedNode(CombinedConfiguration.java:653)
at
org.apache.commons.configuration.CombinedConfiguration.getRootNode(CombinedConfiguration.java:504)
at
org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:925)
at
org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:327)
at
org.apache.commons.configuration.CombinedConfiguration.getProperty(CombinedConfiguration.java:578)
at
org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1155)
at
org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1034)
at
org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1017)
Explanation i got in mailing list from Oliver Heger
I guess you use DefaultConfigurationBuilder for loading a combined
configuration?
The exception is due to the fact that brackets have a special meaning in
the query syntax for hierarchical configurations.
(DefaultConfigurationBuilder transforms all configuration sources into
hierarchical configurations, so also for properties, which are not
hierarchical by default, the same rules apply.)
So far escaping brackets or other specific characters in property keys
is not supported. It seems to be rather unusual to use brackets in
[jira] Created: (CONFIGURATION-404) Revisit - Brackets in property key causes NumberFormatException
Revisit - Brackets in property key causes NumberFormatException --- Key: CONFIGURATION-404 URL: https://issues.apache.org/jira/browse/CONFIGURATION-404 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.5 Reporter: Rob Walker Assignee: Oliver Heger Fix For: 1.6 Hi, When using brackets in property key we get an exception every time. Escaping brackets with \ doesn't help. Example #property in property file test(ef)=false causes java.lang.NumberFormatException: For input string: ef at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Integer.parseInt(Integer.java:447) at java.lang.Integer.parseInt(Integer.java:497) at org.apache.commons.configuration.tree.DefaultConfigurationKey $KeyIterator.checkIndex(DefaultConfigurationKey.java:834) at org.apache.commons.configuration.tree.DefaultConfigurationKey $KeyIterator.nextKey(DefaultConfigurationKey.java:511) at org.apache.commons.configuration.tree.DefaultExpressionEngine.findNodesForKey(DefaultExpressionEngine.java:462) at org.apache.commons.configuration.tree.DefaultExpressionEngine.query(DefaultExpressionEngine.java:286) at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:925 at org.apache.commons.configuration.HierarchicalConfiguration.setProperty(HierarchicalConfiguration.java:735) at org.apache.commons.configuration.ConfigurationUtils.copy(ConfigurationUtils.java:143) at org.apache.commons.configuration.ConfigurationUtils.convertToHierarchical(ConfigurationUtils.java:199) at org.apache.commons.configuration.CombinedConfiguration $ConfigData.getTransformedRoot(CombinedConfiguration.java:794) at org.apache.commons.configuration.CombinedConfiguration.constructCombinedNode(CombinedConfiguration.java:653) at org.apache.commons.configuration.CombinedConfiguration.getRootNode(CombinedConfiguration.java:504) at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:925) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:327) at org.apache.commons.configuration.CombinedConfiguration.getProperty(CombinedConfiguration.java:578) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1155) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1034) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1017) Explanation i got in mailing list from Oliver Heger I guess you use DefaultConfigurationBuilder for loading a combined configuration? The exception is due to the fact that brackets have a special meaning in the query syntax for hierarchical configurations. (DefaultConfigurationBuilder transforms all configuration sources into hierarchical configurations, so also for properties, which are not hierarchical by default, the same rules apply.) So far escaping brackets or other specific characters in property keys is not supported. It seems to be rather unusual to use brackets in property keys, so you may well be the first one who noticed this problem. Unfortunately I don't have a working solution for this problem right now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONFIGURATION-404) Revisit - Brackets in property key causes NumberFormatException
[ https://issues.apache.org/jira/browse/CONFIGURATION-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800546#action_12800546 ] Rob Walker commented on CONFIGURATION-404: -- The bug reported above was raised under JIRA-336, and closed as having ways to workaround - which is correct. On Vista and Win7 this issue now crops up a lot because of the usage of ProgramFiles(x86) as a standard directory name. The workaround proposal under the original issue requires every user to implement their own workaround, and it's non trivial because many of the member fields and methods of tree classes are private and so a simple subclass based solution can't be used. An alternative approach is to simple catch the exception and handle it, reporting the item as not an index.. TBH I'd say an unhandled of this nature is less than ideal in library code anyway, so my view is that this also strengthens the codebase. We have locally implemented this patch and it's working very well, so would like to see it in the codebase. Revisit - Brackets in property key causes NumberFormatException --- Key: CONFIGURATION-404 URL: https://issues.apache.org/jira/browse/CONFIGURATION-404 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.5 Reporter: Rob Walker Assignee: Oliver Heger Fix For: 1.6 Hi, When using brackets in property key we get an exception every time. Escaping brackets with \ doesn't help. Example #property in property file test(ef)=false causes java.lang.NumberFormatException: For input string: ef at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Integer.parseInt(Integer.java:447) at java.lang.Integer.parseInt(Integer.java:497) at org.apache.commons.configuration.tree.DefaultConfigurationKey $KeyIterator.checkIndex(DefaultConfigurationKey.java:834) at org.apache.commons.configuration.tree.DefaultConfigurationKey $KeyIterator.nextKey(DefaultConfigurationKey.java:511) at org.apache.commons.configuration.tree.DefaultExpressionEngine.findNodesForKey(DefaultExpressionEngine.java:462) at org.apache.commons.configuration.tree.DefaultExpressionEngine.query(DefaultExpressionEngine.java:286) at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:925 at org.apache.commons.configuration.HierarchicalConfiguration.setProperty(HierarchicalConfiguration.java:735) at org.apache.commons.configuration.ConfigurationUtils.copy(ConfigurationUtils.java:143) at org.apache.commons.configuration.ConfigurationUtils.convertToHierarchical(ConfigurationUtils.java:199) at org.apache.commons.configuration.CombinedConfiguration $ConfigData.getTransformedRoot(CombinedConfiguration.java:794) at org.apache.commons.configuration.CombinedConfiguration.constructCombinedNode(CombinedConfiguration.java:653) at org.apache.commons.configuration.CombinedConfiguration.getRootNode(CombinedConfiguration.java:504) at org.apache.commons.configuration.HierarchicalConfiguration.fetchNodeList(HierarchicalConfiguration.java:925) at org.apache.commons.configuration.HierarchicalConfiguration.getProperty(HierarchicalConfiguration.java:327) at org.apache.commons.configuration.CombinedConfiguration.getProperty(CombinedConfiguration.java:578) at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1155) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1034) at org.apache.commons.configuration.AbstractConfiguration.getString(AbstractConfiguration.java:1017) Explanation i got in mailing list from Oliver Heger I guess you use DefaultConfigurationBuilder for loading a combined configuration? The exception is due to the fact that brackets have a special meaning in the query syntax for hierarchical configurations. (DefaultConfigurationBuilder transforms all configuration sources into hierarchical configurations, so also for properties, which are not hierarchical by default, the same rules apply.) So far escaping brackets or other specific characters in property keys is not supported. It seems to be rather unusual to use brackets in property keys, so you may well be the first one who noticed this problem. Unfortunately I don't have a working solution for this problem right now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-482) Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
[
https://issues.apache.org/jira/browse/LANG-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12794598#action_12794598
]
Rob Walker commented on LANG-482:
-
Not as yet I'm afraid, got distracted on other tasks - and the patch worked for
us as we don't hit the boundary cases that case the tests to fail.
Just recently we hit an Apache Configuration error on Vista/Win7 paths of the
form Program Files(x86), which Apache raises exceptions on as it thinks the
value in brackets should be a numeric property index. So I need to look into
that and maybe raise a JIRA issue if not already covered, and if so I may get a
chance to revisit and improve this patch.
Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
--
Key: LANG-482
URL: https://issues.apache.org/jira/browse/LANG-482
Project: Commons Lang
Issue Type: Improvement
Components: lang.text.*
Reporter: Rob Walker
Priority: Minor
Fix For: 3.0
Attachments: StrSubstitutor.java.nested.patch
t would be really handy of StrSubstitutor could support nested variable
interpolation:
org.osgi.framework.system.packages=org.osgi.framework; version=1.4.0, \
org.osgi.service.packageadmin; version=1.2.0, \
org.osgi.service.startlevel; version=1.1.0, \
org.osgi.service.url; version=1.0.0, \
org.osgi.util.tracker; version=1.3.3 \
${jre-${java.specification.version}}
The process being to expand innermost variable references first and work
outwards - this allows for very advance config, such as the above, which can
dynamically detect the Java version and expand a JRE version specific
property into the property being defined.
Looking at the implementation, it seems it might be a fairly straightforward
enhancement to:
private int substitute(StrBuilder buf, int offset, int length, List
priorVariables)
The code already has the cyclic map in place.
I already have code that achieves this within Apache Felix, so I will see if
I can retro-fit a similar model to the above and if so submit a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-482) Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
[
https://issues.apache.org/jira/browse/LANG-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12677897#action_12677897
]
Rob Walker commented on LANG-482:
-
Cool - I just need to make time to fix the tests Oliver reported as not
working. The code in the patch does work for basic use cases though, so feel
free to try it. Will hopefully get around to looking at a better version
sometime this week.
Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
--
Key: LANG-482
URL: https://issues.apache.org/jira/browse/LANG-482
Project: Commons Lang
Issue Type: Improvement
Reporter: Rob Walker
Priority: Minor
Fix For: 3.0
Attachments: StrSubstitutor.java.nested.patch
t would be really handy of StrSubstitutor could support nested variable
interpolation:
org.osgi.framework.system.packages=org.osgi.framework; version=1.4.0, \
org.osgi.service.packageadmin; version=1.2.0, \
org.osgi.service.startlevel; version=1.1.0, \
org.osgi.service.url; version=1.0.0, \
org.osgi.util.tracker; version=1.3.3 \
${jre-${java.specification.version}}
The process being to expand innermost variable references first and work
outwards - this allows for very advance config, such as the above, which can
dynamically detect the Java version and expand a JRE version specific
property into the property being defined.
Looking at the implementation, it seems it might be a fairly straightforward
enhancement to:
private int substitute(StrBuilder buf, int offset, int length, List
priorVariables)
The code already has the cyclic map in place.
I already have code that achieves this within Apache Felix, so I will see if
I can retro-fit a similar model to the above and if so submit a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-482) Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
[
https://issues.apache.org/jira/browse/LANG-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12675777#action_12675777
]
Rob Walker commented on LANG-482:
-
Thanks - I'll need to take a look at these. The changes are working nicely to
great benefit in our usage with a Felix based App here, but clearly they trip
out some of the standard tests.
- Rob
Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
--
Key: LANG-482
URL: https://issues.apache.org/jira/browse/LANG-482
Project: Commons Lang
Issue Type: Improvement
Reporter: Rob Walker
Priority: Minor
Attachments: StrSubstitutor.java.nested.patch
t would be really handy of StrSubstitutor could support nested variable
interpolation:
org.osgi.framework.system.packages=org.osgi.framework; version=1.4.0, \
org.osgi.service.packageadmin; version=1.2.0, \
org.osgi.service.startlevel; version=1.1.0, \
org.osgi.service.url; version=1.0.0, \
org.osgi.util.tracker; version=1.3.3 \
${jre-${java.specification.version}}
The process being to expand innermost variable references first and work
outwards - this allows for very advance config, such as the above, which can
dynamically detect the Java version and expand a JRE version specific
property into the property being defined.
Looking at the implementation, it seems it might be a fairly straightforward
enhancement to:
private int substitute(StrBuilder buf, int offset, int length, List
priorVariables)
The code already has the cyclic map in place.
I already have code that achieves this within Apache Felix, so I will see if
I can retro-fit a similar model to the above and if so submit a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CONFIGURATION-365) Bean handling not allowing an XPathExpressionEngine
Bean handling not allowing an XPathExpressionEngine
---
Key: CONFIGURATION-365
URL: https://issues.apache.org/jira/browse/CONFIGURATION-365
Project: Commons Configuration
Issue Type: Bug
Environment: OSGi / Felix
Reporter: Rob Walker
Trying to set an XPathExpressionEngine in the config file:
===
xml
config-name=config.product.xml
fileName=${sys:bundle.root}/etc/${sys:launch.target}.properties.xml
expressionEngine
config-class=org.apache.commons.configuration.tree.xpath.XPathExpressionEngine/
/xml
===
And it throws an exception:
Caused by: org.apache.commons.configuration.ConfigurationException:
org.apache.commons.configuration.ConfigurationRuntimeException:
java.lang.IllegalArgumentException: Cannot invoke
org.apache.commons.configuration.HierarchicalConfiguration.setExpressionEngine
on
bean class 'class org.apache.commons.configuration.XMLConfiguration' - argument
type mismatch - had objects of type org.apache.comm
ons.configuration.tree.xpath.XPathExpressionEngine but expected signature
org.apache.commons.configuration.tree.ExpressionEngine
at
org.apache.commons.configuration.DefaultConfigurationBuilder.createConfigurationAt(DefaultConfigurationBuilder.java:752)
at
org.apache.commons.configuration.DefaultConfigurationBuilder.initCombinedConfiguration(DefaultConfigurationBuilder.java:6
28)
at
org.apache.commons.configuration.DefaultConfigurationBuilder.getConfiguration(DefaultConfigurationBuilder.java:560)
at
com.ascert.vt.modules.propsmgr.PropsMgrMainOSGI.init(PropsMgrMainOSGI.java:102)
... 13 more
Caused by: org.apache.commons.configuration.ConfigurationRuntimeException:
java.lang.IllegalArgumentException: Cannot invoke org.apa
che.commons.configuration.HierarchicalConfiguration.setExpressionEngine on bean
class 'class org.apache.commons.configuration.XMLCon
figuration' - argument type mismatch - had objects of type
org.apache.commons.configuration.tree.xpath.XPathExpressionEngine but e
xpected signature org.apache.commons.configuration.tree.ExpressionEngine
at
org.apache.commons.configuration.beanutils.BeanHelper.createBean(BeanHelper.java:252)
at
org.apache.commons.configuration.beanutils.BeanHelper.createBean(BeanHelper.java:269)
at
org.apache.commons.configuration.beanutils.BeanHelper.createBean(BeanHelper.java:283)
at
org.apache.commons.configuration.DefaultConfigurationBuilder.createConfigurationAt(DefaultConfigurationBuilder.java:747)
... 16 more
Caused by: java.lang.IllegalArgumentException: Cannot invoke
org.apache.commons.configuration.HierarchicalConfiguration.setExpressio
nEngine on bean class 'class org.apache.commons.configuration.XMLConfiguration'
- argument type mismatch - had objects of type org.
apache.commons.configuration.tree.xpath.XPathExpressionEngine but expected
signature org.apache.commons.configuration.tree.Express
ionEngine
===
Since XPathExpressionEngine implements ExpressionEngine, this looks like a
reflection bug to me i.e. not finding a method with a signature for implemented
interfaces as opposed to just subclasses.
Not sure if this is OSGi / Felix classloading related, but don't think so
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CONFIGURATION-363) Consider enhancing to allow nested variable interpolation
Consider enhancing to allow nested variable interpolation
-
Key: CONFIGURATION-363
URL: https://issues.apache.org/jira/browse/CONFIGURATION-363
Project: Commons Configuration
Issue Type: Improvement
Components: Interpolation
Reporter: Rob Walker
Priority: Minor
It would be really handy of Commons Configuration could support nested variable
interpolation:
org.osgi.framework.system.packages=org.osgi.framework; version=1.4.0, \
org.osgi.service.packageadmin; version=1.2.0, \
org.osgi.service.startlevel; version=1.1.0, \
org.osgi.service.url; version=1.0.0, \
org.osgi.util.tracker; version=1.3.3 \
${jre-${java.specification.version}}
The process being to expand innermost variable references first and work
outwards - this allows for very advance config, such as the above, which can
dynamically detect the Java version and expand a JRE version specific property
into the property being defined.
Care is needed to avoid recursion, which can been handled through use of a
Cycle Map that detects of an inner variable has already been referenced.
An example of this can be found in the substVars method of the Apache Felix
org.apache.felix.framework.util.Util class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CONFIGURATION-363) Consider enhancing to allow nested variable interpolation
[
https://issues.apache.org/jira/browse/CONFIGURATION-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12671120#action_12671120
]
walkerr edited comment on CONFIGURATION-363 at 2/6/09 5:18 AM:
--
It looks like this would be an enhancement to the StrSubstitutor class in
Commons Lang.
Will raise a JIRA their and also see if I can figure and submit a patch
was (Author: walkerr):
It looks like this would be an enhancement to the StrSubstitution class in
Commons Lang.
Will raise a JIRA their and also see if I can figure and submit a patch
Consider enhancing to allow nested variable interpolation
-
Key: CONFIGURATION-363
URL: https://issues.apache.org/jira/browse/CONFIGURATION-363
Project: Commons Configuration
Issue Type: Improvement
Components: Interpolation
Reporter: Rob Walker
Priority: Minor
It would be really handy of Commons Configuration could support nested
variable interpolation:
org.osgi.framework.system.packages=org.osgi.framework; version=1.4.0, \
org.osgi.service.packageadmin; version=1.2.0, \
org.osgi.service.startlevel; version=1.1.0, \
org.osgi.service.url; version=1.0.0, \
org.osgi.util.tracker; version=1.3.3 \
${jre-${java.specification.version}}
The process being to expand innermost variable references first and work
outwards - this allows for very advance config, such as the above, which can
dynamically detect the Java version and expand a JRE version specific
property into the property being defined.
Care is needed to avoid recursion, which can been handled through use of a
Cycle Map that detects of an inner variable has already been referenced.
An example of this can be found in the substVars method of the Apache Felix
org.apache.felix.framework.util.Util class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (CONFIGURATION-364) Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
[
https://issues.apache.org/jira/browse/CONFIGURATION-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Walker closed CONFIGURATION-364.
Resolution: Fixed
Woops - should have raised in Lang
Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
--
Key: CONFIGURATION-364
URL: https://issues.apache.org/jira/browse/CONFIGURATION-364
Project: Commons Configuration
Issue Type: Improvement
Reporter: Rob Walker
It would be really handy of StrSubstitutor could support nested variable
interpolation:
org.osgi.framework.system.packages=org.osgi.framework; version=1.4.0, \
org.osgi.service.packageadmin; version=1.2.0, \
org.osgi.service.startlevel; version=1.1.0, \
org.osgi.service.url; version=1.0.0, \
org.osgi.util.tracker; version=1.3.3 \
${jre-${java.specification.version}}
The process being to expand innermost variable references first and work
outwards - this allows for very advance config, such as the above, which can
dynamically detect the Java version and expand a JRE version specific
property into the property being defined.
Looking at the implementation, it seems it might be a fairly straightforward
enhancement to:
private int substitute(StrBuilder buf, int offset, int length, List
priorVariables)
The code already has the cyclic map in place.
I already have code that achieves this within Apache Felix, so I will see if
I can retro-fit a similar model to the above and if so submit a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CONFIGURATION-364) Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
--
Key: CONFIGURATION-364
URL: https://issues.apache.org/jira/browse/CONFIGURATION-364
Project: Commons Configuration
Issue Type: Improvement
Reporter: Rob Walker
It would be really handy of StrSubstitutor could support nested variable
interpolation:
org.osgi.framework.system.packages=org.osgi.framework; version=1.4.0, \
org.osgi.service.packageadmin; version=1.2.0, \
org.osgi.service.startlevel; version=1.1.0, \
org.osgi.service.url; version=1.0.0, \
org.osgi.util.tracker; version=1.3.3 \
${jre-${java.specification.version}}
The process being to expand innermost variable references first and work
outwards - this allows for very advance config, such as the above, which can
dynamically detect the Java version and expand a JRE version specific property
into the property being defined.
Looking at the implementation, it seems it might be a fairly straightforward
enhancement to:
private int substitute(StrBuilder buf, int offset, int length, List
priorVariables)
The code already has the cyclic map in place.
I already have code that achieves this within Apache Felix, so I will see if I
can retro-fit a similar model to the above and if so submit a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-482) Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
--
Key: LANG-482
URL: https://issues.apache.org/jira/browse/LANG-482
Project: Commons Lang
Issue Type: Improvement
Reporter: Rob Walker
Priority: Minor
t would be really handy of StrSubstitutor could support nested variable
interpolation:
org.osgi.framework.system.packages=org.osgi.framework; version=1.4.0, \
org.osgi.service.packageadmin; version=1.2.0, \
org.osgi.service.startlevel; version=1.1.0, \
org.osgi.service.url; version=1.0.0, \
org.osgi.util.tracker; version=1.3.3 \
${jre-${java.specification.version}}
The process being to expand innermost variable references first and work
outwards - this allows for very advance config, such as the above, which can
dynamically detect the Java version and expand a JRE version specific property
into the property being defined.
Looking at the implementation, it seems it might be a fairly straightforward
enhancement to:
private int substitute(StrBuilder buf, int offset, int length, List
priorVariables)
The code already has the cyclic map in place.
I already have code that achieves this within Apache Felix, so I will see if I
can retro-fit a similar model to the above and if so submit a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONFIGURATION-363) Consider enhancing to allow nested variable interpolation
[
https://issues.apache.org/jira/browse/CONFIGURATION-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12671120#action_12671120
]
Rob Walker commented on CONFIGURATION-363:
--
It looks like this would be an enhancement to the StrSubstitution class in
Commons Lang.
Will raise a JIRA their and also see if I can figure and submit a patch
Consider enhancing to allow nested variable interpolation
-
Key: CONFIGURATION-363
URL: https://issues.apache.org/jira/browse/CONFIGURATION-363
Project: Commons Configuration
Issue Type: Improvement
Components: Interpolation
Reporter: Rob Walker
Priority: Minor
It would be really handy of Commons Configuration could support nested
variable interpolation:
org.osgi.framework.system.packages=org.osgi.framework; version=1.4.0, \
org.osgi.service.packageadmin; version=1.2.0, \
org.osgi.service.startlevel; version=1.1.0, \
org.osgi.service.url; version=1.0.0, \
org.osgi.util.tracker; version=1.3.3 \
${jre-${java.specification.version}}
The process being to expand innermost variable references first and work
outwards - this allows for very advance config, such as the above, which can
dynamically detect the Java version and expand a JRE version specific
property into the property being defined.
Care is needed to avoid recursion, which can been handled through use of a
Cycle Map that detects of an inner variable has already been referenced.
An example of this can be found in the substVars method of the Apache Felix
org.apache.felix.framework.util.Util class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-482) Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
[
https://issues.apache.org/jira/browse/LANG-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Walker updated LANG-482:
Attachment: StrSubstitutor.java.nested.patch
Attached is a provisional patch that seems to work for this.
It works for a pretty good array of tests that I have here, plus seems to catch
the recursion nasty. Will continue with more checks against our apps usage via
Commons Configuration next week
Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
--
Key: LANG-482
URL: https://issues.apache.org/jira/browse/LANG-482
Project: Commons Lang
Issue Type: Improvement
Reporter: Rob Walker
Priority: Minor
Attachments: StrSubstitutor.java.nested.patch
t would be really handy of StrSubstitutor could support nested variable
interpolation:
org.osgi.framework.system.packages=org.osgi.framework; version=1.4.0, \
org.osgi.service.packageadmin; version=1.2.0, \
org.osgi.service.startlevel; version=1.1.0, \
org.osgi.service.url; version=1.0.0, \
org.osgi.util.tracker; version=1.3.3 \
${jre-${java.specification.version}}
The process being to expand innermost variable references first and work
outwards - this allows for very advance config, such as the above, which can
dynamically detect the Java version and expand a JRE version specific
property into the property being defined.
Looking at the implementation, it seems it might be a fairly straightforward
enhancement to:
private int substitute(StrBuilder buf, int offset, int length, List
priorVariables)
The code already has the cyclic map in place.
I already have code that achieves this within Apache Felix, so I will see if
I can retro-fit a similar model to the above and if so submit a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
