[MGNLUI-3753] When a required for field encounters value conversion exception - the stacktrace is pushed to the error message Created: 21/Jan/16  Updated: 11/Mar/21  Resolved: 11/Mar/21

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: 5.4.4
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Aleksandr Pchelintcev Assignee: Unassigned
Resolution: Obsolete Votes: 2
Labels: form
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
is cloned by MGNLUI-3673 Field Validator Error Messages for ty... Closed
Relates
relates to JCRTOOLS-15 Entering a large number for level res... Closed
causality
caused by MGNLUI-2774 When required i18n field is emptied, ... Closed
duplicate
is duplicated by MGNLUI-2902 Stacktrace in dialog by failed Long c... 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:

 Description   

As of resolution of a linked issue - the form fields attempt to commit the invalid values to the backend, which results in this:

We need to investigate whether the workaround for MGNLUI-2774 is still required (cause for me it looks like it doesn't make a lot of sense). Suppressing it would prevent invalid values to be attempted to be written to the property data-source and error messages would look nice and clean.



 Comments   
Comment by Federico Grilli [ 21/Jan/16 ]

This is from a comment in the duplicate related issue MGNLUI-3673 that might hopefully shed some light

com.vaadin.ui.AbstractField.getErrorMessage() (line #1061) returns a com.vaadin.server.CompositeErrorMessage.CompositeErrorMessage which apparently is made up by the "short" error message AND the whole stack trace of the underlying cause as a second error. Not sure how to filter out the second message, because afaics there's nothing differentiating the ErrorMessage object wrapping the stack trace. I may assume that it is always the second error but that depends on how CompositeErrorMessage stores errors internally, therefore not very reliable.

Comment by Aleksandr Pchelintcev [ 21/Jan/16 ]

fgrilli It's actually already quite clear why this happens: as of the MGNLUI-2774 we call com.vaadin.ui.AbstractField#setInvalidCommitted from the AbstractFieldFactory (but only for the required fields!) and this forces Vaadin to try to write an invalid value to the property anyway and that's where the "unhandled" conversion attempt occurs.

Generated at Mon Feb 12 09:09:44 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.