[MGNLUI-2537] Cause of Vaadin-"Internal Errors" are not visible (log/pulse) Created: 26/Dec/13  Updated: 07/May/14  Resolved: 07/May/14

Status: Closed
Project: Magnolia UI
Component/s: admincentral
Affects Version/s: 5.2.1
Fix Version/s: 5.3

Type: Bug Priority: Major
Reporter: Markus Grieder Assignee: Mikaël Geljić
Resolution: Outdated Votes: 0
Labels: errorhandling
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causality
caused by MGNLUI-1140 Add global error handler on the UI root Closed
supersession
is superseded by MGNLUI-2819 No trace in logs when a Vaadin intern... 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   

Internal Errors (handled in VaadinService#handleExceptionDuringRequest) are forwarded only to an ErrorHandler registrated at VaadinSession,
but MGNLUI-1140 was setting the VaadinSession-ErrorHandler to "null".
Because of that nobody is seeing the cause of "Internal Errors" (no stacktrace/message in log or Pulse).

Example: JBoss Application Server 5.1 has a Bug which is leading to Internal Errors starting with the second AdminCentral-Login (see attached stack trace). This stack trace was only visible with an VaadinSession-ErrorHandler.

Maybe you could registrate an AdmincentralErrorHandler for VaadinSession instead of setting it to "null"



 Comments   
Comment by Mikaël Geljić [ 07/May/14 ]

Hi Markus,

Better late than never, indeed it's been an issue to set the VaadinSession's ErrorHandler to null. Fortunately we have come to fix this recently in MGNLUI-2819 (yet to be backported to 5.2.x).

For your information, just setting our AdmincentralErrorHandler on the VaadinSession turned out to be less "stable" than when it is on the UI — when an internal error occurred, it would then take at least one more refresh / ?restartApplication to get it back up. So we simply kept Vaadin's DefaultErrorHandler on the session. Doesn't log to the pulse for sure but at least there is a trace in the logs (Vaadin uses java.util.logging.* by the way).

If you don't mind, I'll close this issue as outdated then.

Thanks for reporting anyway!

Generated at Mon Feb 12 08:57:40 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.