[jira] Created: (COLLECTIONS-299) ExtendedProperties.convertProperties loses non-String values

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (COLLECTIONS-299) ExtendedProperties.convertProperties loses non-String values

ASF GitHub Bot (Jira)
ExtendedProperties.convertProperties loses non-String values
------------------------------------------------------------

                 Key: COLLECTIONS-299
                 URL: https://issues.apache.org/jira/browse/COLLECTIONS-299
             Project: Commons Collections
          Issue Type: Bug
          Components: Core
            Reporter: Simon Kitching


A Properties object normally has Strings as its values. But it does partially support non-String-typed values via the raw put and get methods inherited from Hashtable. And other Properties methods are aware that the value might not be a String; see documentation for methods propertyNames() and stringPropertyNames() for example.

ExtendedProperties.convertProperties does this:
       for (Enumeration e = props.propertyNames(); e.hasMoreElements();) {
            String s = (String) e.nextElement();
            c.setProperty(s, props.getProperty(s));
        }

Properties.propertyNames() returns the names of all keys in the set, regardless of the associated value's type. But Properties.getProperty(key) returns null if the value type is not a String. The call to c.setProperty invokes setPropertyInternal, which can pass this null value to Hashtable.put, which then throws a NullPointerException.

It's rather puzzling to have a valid (string-key, non-string-value) entry in the Properties object and get a NullPointerException.

Perhaps the call
  props.getProperty(s)
can be changed to
  props.get(s)

Alternately, at least documenting that this method does not support non-string values in the input Properties object would be useful.


--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (COLLECTIONS-299) ExtendedProperties.convertProperties loses non-String values

ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/COLLECTIONS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sebb updated COLLECTIONS-299:
-----------------------------

    Description:
A Properties object normally has Strings as its values. But it does partially support non-String-typed values via the raw put and get methods inherited from Hashtable. And other Properties methods are aware that the value might not be a String; see documentation for methods propertyNames() and stringPropertyNames() for example.

ExtendedProperties.convertProperties does this:
{code}
for (Enumeration e = props.propertyNames(); e.hasMoreElements();) {
      String s = (String) e.nextElement();
      c.setProperty(s, props.getProperty(s));
}
{code}

Properties.propertyNames() returns the names of all keys in the set, regardless of the associated value's type. But Properties.getProperty(key) returns null if the value type is not a String. The call to c.setProperty invokes setPropertyInternal, which can pass this null value to Hashtable.put, which then throws a NullPointerException.

It's rather puzzling to have a valid (string-key, non-string-value) entry in the Properties object and get a NullPointerException.

Perhaps the call
  props.getProperty(s)
can be changed to
  props.get(s)

Alternately, at least documenting that this method does not support non-string values in the input Properties object would be useful.


  was:
A Properties object normally has Strings as its values. But it does partially support non-String-typed values via the raw put and get methods inherited from Hashtable. And other Properties methods are aware that the value might not be a String; see documentation for methods propertyNames() and stringPropertyNames() for example.

ExtendedProperties.convertProperties does this:
       for (Enumeration e = props.propertyNames(); e.hasMoreElements();) {
            String s = (String) e.nextElement();
            c.setProperty(s, props.getProperty(s));
        }

Properties.propertyNames() returns the names of all keys in the set, regardless of the associated value's type. But Properties.getProperty(key) returns null if the value type is not a String. The call to c.setProperty invokes setPropertyInternal, which can pass this null value to Hashtable.put, which then throws a NullPointerException.

It's rather puzzling to have a valid (string-key, non-string-value) entry in the Properties object and get a NullPointerException.

Perhaps the call
  props.getProperty(s)
can be changed to
  props.get(s)

Alternately, at least documenting that this method does not support non-string values in the input Properties object would be useful.



Add code markers to stop reformatting of code section - and conversion of ;\) to ;)

> ExtendedProperties.convertProperties loses non-String values
> ------------------------------------------------------------
>
>                 Key: COLLECTIONS-299
>                 URL: https://issues.apache.org/jira/browse/COLLECTIONS-299
>             Project: Commons Collections
>          Issue Type: Bug
>          Components: Core
>            Reporter: Simon Kitching
>
> A Properties object normally has Strings as its values. But it does partially support non-String-typed values via the raw put and get methods inherited from Hashtable. And other Properties methods are aware that the value might not be a String; see documentation for methods propertyNames() and stringPropertyNames() for example.
> ExtendedProperties.convertProperties does this:
> {code}
> for (Enumeration e = props.propertyNames(); e.hasMoreElements();) {
>       String s = (String) e.nextElement();
>       c.setProperty(s, props.getProperty(s));
> }
> {code}
> Properties.propertyNames() returns the names of all keys in the set, regardless of the associated value's type. But Properties.getProperty(key) returns null if the value type is not a String. The call to c.setProperty invokes setPropertyInternal, which can pass this null value to Hashtable.put, which then throws a NullPointerException.
> It's rather puzzling to have a valid (string-key, non-string-value) entry in the Properties object and get a NullPointerException.
> Perhaps the call
>   props.getProperty(s)
> can be changed to
>   props.get(s)
> Alternately, at least documenting that this method does not support non-string values in the input Properties object would be useful.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (COLLECTIONS-299) ExtendedProperties.convertProperties loses non-String values

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/COLLECTIONS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Henri Yandell updated COLLECTIONS-299:
--------------------------------------

    Fix Version/s: 3.3

> ExtendedProperties.convertProperties loses non-String values
> ------------------------------------------------------------
>
>                 Key: COLLECTIONS-299
>                 URL: https://issues.apache.org/jira/browse/COLLECTIONS-299
>             Project: Commons Collections
>          Issue Type: Bug
>          Components: Core
>            Reporter: Simon Kitching
>             Fix For: 3.3
>
>
> A Properties object normally has Strings as its values. But it does partially support non-String-typed values via the raw put and get methods inherited from Hashtable. And other Properties methods are aware that the value might not be a String; see documentation for methods propertyNames() and stringPropertyNames() for example.
> ExtendedProperties.convertProperties does this:
> {code}
> for (Enumeration e = props.propertyNames(); e.hasMoreElements();) {
>       String s = (String) e.nextElement();
>       c.setProperty(s, props.getProperty(s));
> }
> {code}
> Properties.propertyNames() returns the names of all keys in the set, regardless of the associated value's type. But Properties.getProperty(key) returns null if the value type is not a String. The call to c.setProperty invokes setPropertyInternal, which can pass this null value to Hashtable.put, which then throws a NullPointerException.
> It's rather puzzling to have a valid (string-key, non-string-value) entry in the Properties object and get a NullPointerException.
> Perhaps the call
>   props.getProperty(s)
> can be changed to
>   props.get(s)
> Alternately, at least documenting that this method does not support non-string values in the input Properties object would be useful.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (COLLECTIONS-299) ExtendedProperties.convertProperties loses non-String values

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

    [ https://issues.apache.org/jira/browse/COLLECTIONS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644858#action_12644858 ]

Henri Yandell commented on COLLECTIONS-299:
-------------------------------------------

Interestingly this mimics the same issue in java.util.Properties. If you pass a value into its Properties(Properties) constructor then any non-String values are lost. I think the javadoc route is probably best here - especially as the getProperty to get change makes tests fail.

> ExtendedProperties.convertProperties loses non-String values
> ------------------------------------------------------------
>
>                 Key: COLLECTIONS-299
>                 URL: https://issues.apache.org/jira/browse/COLLECTIONS-299
>             Project: Commons Collections
>          Issue Type: Bug
>          Components: Core
>            Reporter: Simon Kitching
>             Fix For: 3.3
>
>
> A Properties object normally has Strings as its values. But it does partially support non-String-typed values via the raw put and get methods inherited from Hashtable. And other Properties methods are aware that the value might not be a String; see documentation for methods propertyNames() and stringPropertyNames() for example.
> ExtendedProperties.convertProperties does this:
> {code}
> for (Enumeration e = props.propertyNames(); e.hasMoreElements();) {
>       String s = (String) e.nextElement();
>       c.setProperty(s, props.getProperty(s));
> }
> {code}
> Properties.propertyNames() returns the names of all keys in the set, regardless of the associated value's type. But Properties.getProperty(key) returns null if the value type is not a String. The call to c.setProperty invokes setPropertyInternal, which can pass this null value to Hashtable.put, which then throws a NullPointerException.
> It's rather puzzling to have a valid (string-key, non-string-value) entry in the Properties object and get a NullPointerException.
> Perhaps the call
>   props.getProperty(s)
> can be changed to
>   props.get(s)
> Alternately, at least documenting that this method does not support non-string values in the input Properties object would be useful.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Closed: (COLLECTIONS-299) ExtendedProperties.convertProperties loses non-String values

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/COLLECTIONS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Henri Yandell closed COLLECTIONS-299.
-------------------------------------

    Resolution: Fixed

I added null-protection to stop the NPE.

svn ci -m "Adding a test for COLLECTIONS-299 and a fix. Fixes by not adding any non-String values as per java.util.Properties; also adding to the javadoc" src

Sending        src/java/org/apache/commons/collections/ExtendedProperties.java
Sending        src/test/org/apache/commons/collections/TestExtendedProperties.java
Transmitting file data ..
Committed revision 711140.

> ExtendedProperties.convertProperties loses non-String values
> ------------------------------------------------------------
>
>                 Key: COLLECTIONS-299
>                 URL: https://issues.apache.org/jira/browse/COLLECTIONS-299
>             Project: Commons Collections
>          Issue Type: Bug
>          Components: Core
>            Reporter: Simon Kitching
>             Fix For: 3.3
>
>
> A Properties object normally has Strings as its values. But it does partially support non-String-typed values via the raw put and get methods inherited from Hashtable. And other Properties methods are aware that the value might not be a String; see documentation for methods propertyNames() and stringPropertyNames() for example.
> ExtendedProperties.convertProperties does this:
> {code}
> for (Enumeration e = props.propertyNames(); e.hasMoreElements();) {
>       String s = (String) e.nextElement();
>       c.setProperty(s, props.getProperty(s));
> }
> {code}
> Properties.propertyNames() returns the names of all keys in the set, regardless of the associated value's type. But Properties.getProperty(key) returns null if the value type is not a String. The call to c.setProperty invokes setPropertyInternal, which can pass this null value to Hashtable.put, which then throws a NullPointerException.
> It's rather puzzling to have a valid (string-key, non-string-value) entry in the Properties object and get a NullPointerException.
> Perhaps the call
>   props.getProperty(s)
> can be changed to
>   props.get(s)
> Alternately, at least documenting that this method does not support non-string values in the input Properties object would be useful.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.