[JCRTOOLS-15] Entering a large number for level results in error in UI Created: 15/Dec/15  Updated: 29/Mar/22  Resolved: 06/Jan/16

Status: Closed
Project: JCR Tools
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0

Type: Bug Priority: Neutral
Reporter: Philip Mundt Assignee: Bradley Andersen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0d
Time Spent: 5.5h
Original Estimate: Not Specified

Attachments: PNG File Screen Shot 2016-01-06 at 12.53.02.png     PNG File Screen Shot 2016-01-06 at 12.53.16.png     PNG File large_level.png    
Issue Links:
Relates
relates to MGNLUI-3753 When a required for field encounters ... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Sprint: Basel 27
Story Points: 5
Team: Nucleus

 Description   

We should be providing proper validation to prevent error in UI and log:

Caused by: java . lang.NumberFormatException: For input string: "1000000000000"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:495)
at java.lang.Integer.parseInt(Integer.java:527)
at info.magnolia.jcrtools.dumper.DumperSubApp.onActionTriggered(DumperSubApp.java:84)
at info.magnolia.jcrtools.JcrToolsViewImpl$1.buttonClick(JcrToolsViewImpl.java:91)
at sun.reflect.GeneratedMethodAccessor212.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:508)
... 91 more


 Comments   
Comment by Bradley Andersen [ 06/Jan/16 ]

STEPS TO DUPLICATE

1. Open the webapp; in AdminCentral select Jcr Tools from the Dev group.
2. Open the Dumper sub app of the Jcr Tools app.
3. Select a dump level by filling out the "Level" field. Optionally, select a Workspace from the dropdown, and a Base Path (the defaults are OK). To trigger the error, enter a number > 2147483647.
4. Click Execute to submit the form.

BEHAVIOR

The dump level is a String which gets converted on submit to an integer. The problem here is that, if a dump level larger than the largest possible integer is entered (2^31 - 1 = 2147483647), Java is unable to create an integer from that dump level String, which throws a NumberFormatException. The exception is "handled" by the system (i.e., it is not a fatal exception), but pollutes the logs with notices, and is not handled by validators as it should be (Screen shots of the UI upon error are attached).

Here's what we find in the logs:
https://gist.github.com/anonymous/8c549f06e5a5d67d5b9f#file-gistfile1-txt

SIMILAR UI ISSUES ELSEWHERE IN THE SYSTEM

We have multiple places in the system where such problems might occur; that is, there are other places in the system where input validation (for this class of problem, at least) could be made better. Better input validation means more granular control over the UIX, which ultimately means a better UIX.

A couple of examples:

1. Mail Tools app "SMTP port" field
2. Contacts app "Zip Code" field

QUICK FIXES / DISCUSSION

1. Use a regular expression to validate the user input level, either as the first of two chained validators, or by itself. Similarly, a CompositeValidator could be used.

A regular expression will work, but it will suffer from two major drawbacks:
a. It will be complicated. There is no simple way to use a regular expression to validate an integer range. A complicated regular expression will be slow (in terms of processing) and difficult to understand and to maintain. Here's an example discussion on the topic: https://aliteralmind.wordpress.com/2014/03/02/regex_numeric_range/.
b. It will be a one-off configuration. If we later find the same problem elsewhere in the system, we must copy this solution to that second place. Even if a third such place is never found, we now have two places with duplicated code. There are many maintenance issues associated with such a scheme.

2. Set Level on the range [0, jackrabbit.LEVEL_MAX] (So far, I have been unable to find such a max in the documentation).

Even if such a max exists, then we are still validating on a range, and we're in the same situation as with the regular expression validator.

SUGGESTED SOLUTION
Due to drawbacks with the quick fixes, I suggest we use one of Vaadin's existing validators.
Such validators solve the issues associated with the regular expression quick fix:

1. It already exists in the system; no need to write anything new (just change the jcr properties for the field to be validated).

2. This validator can be re-used anywhere. No need for code duplication, easier maintenance.

For this particular case, we should use Vaadin's LongRangeValidator.

Generated at Mon Feb 12 02:17:06 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.