Bug 749315 - config editor: INTEGER props can be set to values greater than Integer.MAX_VALUE or less than Integer.MIN_VALUE
config editor: INTEGER props can be set to values greater than Integer.MAX_VA...
Product: RHQ Project
Classification: Other
Component: Core UI (Show other bugs)
Unspecified Unspecified
medium Severity high (vote)
: ---
: ---
Assigned To: Stefan Negrea
Mike Foley
Depends On:
Blocks: config/individual-config jon3 rhq-uxd
  Show dependency treegraph
Reported: 2011-10-26 13:24 EDT by Ian Springer
Modified: 2013-09-04 03:48 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-09-04 03:48:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ian Springer 2011-10-26 13:24:38 EDT
The client-side field validation should not allow values outside of the valid range for Java Integers.

We need to write our own Integer validator that validates the range, since SmartGWT's IsIntegerValidator, which is what we currently use, apparently does not. IsIntegerValidator also has the broken feature of automatically converting the value to scientific notation if it exceeds 100000000000000000000. For example , it auto-converts to "1000000000000000000000" to "1e+21". This seems fine at first, but it then proceeds to flag the value as invalid since it "Must be a whole number." So it essentially sets the field's value to something it considers invalid.
Comment 1 Charles Crouch 2012-02-16 13:32:51 EST
Unassigning from ips since he's not looking at this currently.
Comment 2 Stefan Negrea 2012-02-24 16:40:49 EST
Updated the code to always set max and min values for integer validators to corresponding integer limits when they are not specified other config properties.

This prevents users from entering values outside of integer range and also avoids the automatic conversion to scientific notation since the limits are smaller then length at which automatic conversion occurs.

There was no need to create/use a custom validator.

Commit to master branch:
Comment 4 Heiko W. Rupp 2013-09-04 03:48:54 EDT
Bulk closing of some old issues

Note You need to log in before you can comment on or make changes to this bug.