[ 
https://issues.apache.org/jira/browse/STORM-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14059102#comment-14059102
 ] 

ASF GitHub Bot commented on STORM-328:
--------------------------------------

Github user d2r commented on a diff in the pull request:

    https://github.com/apache/incubator-storm/pull/187#discussion_r14834365
  
    --- Diff: storm-core/src/jvm/backtype/storm/ConfigValidation.java ---
    @@ -82,6 +82,76 @@ public void validateField(String name, Object field)
         public static Object MapsValidator = 
FieldListValidatorFactory(Map.class);
     
         /**
    +     * Validates a Integer.
    +     */
    +    public static Object IntegerValidator = new FieldValidator() {
    +        @Override
    +        public void validateField(String name, Object o) throws 
IllegalArgumentException {
    +            if (o == null) {
    +                // A null value is acceptable.
    --- End diff --
    
    Before this change, a null value for these fields would throw an exception:
    
https://github.com/apache/incubator-storm/blob/master/storm-core/src/clj/backtype/storm/config.clj#L51
    
    Now, when it is null, it will pass validation.
    
    This is probably fine, but wanted to bring it up since it is a change.
    
    (This is not the case with the new `IntegersValidator` below.)


> Config.java and Utils.get{Int,Long} are not in sync for floating point
> ----------------------------------------------------------------------
>
>                 Key: STORM-328
>                 URL: https://issues.apache.org/jira/browse/STORM-328
>             Project: Apache Storm (Incubating)
>          Issue Type: Bug
>    Affects Versions: 0.9.2-incubating, 0.9.1-incubating, 0.9.0.1
>            Reporter: Robert Joseph Evans
>              Labels: newbie
>
> For most numeric configuration values Config.java has a type of Number 
> listed, but the values are parsed using Utils.getInt or Utils.getLong, which 
> means if someone gave a floating point number it would pass the 
> ConfigValidation, but would blow up when it is used.  This is most critical 
> for values that Nimbus reads, but would be good to have them consistent 
> everywhere.
> We should also check that getInt works properly for numbers that are larger 
> then would fit in an integer.
> Either we need to update Utils to be more lenient when looking at doubles, or 
> we need to make Config more strict, which may be difficult with the YAML and 
> JSON parsing that happens, where ints are often converted into longs.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to