[
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)