|
| Re: Interpreting problem popus [message #1758846 is a reply to message #1758500] |
Mon, 03 April 2017 18:15   |
|
Urs,
Basically, "unexpected problems" occur if an exception was not properly handled, it's some kind of catch-all fallback. Simply ignoring the error could be even more confusing. JavaScipt and Java errors look very similar (the only difference is the text "internal UI error" vs. "internal processing error"), because they both indicate code errors, not business errors. In an ideal world, the user would never see such errors.
The "error code" does not have much significance. In fact, the message texts are purposely generic, because server applications should not expose any internal information (e.g. stack traces) for security reasons. However, the full message should always be written to the server log for later analysis. As you say, it would be quite hard to look into a bug report without. (That's why we try to log java script errors to the server log as well.)
I can think of three reasons why you don't see any error in the log:
1. The exceptions are handled by a custom ExceptionHandler that only displays a message box, but does not write log messages. (Quite unlikely, but check your workspace for subclasses of org.eclipse.scout.rt.platform.exception.ExceptionHandler.)
2. The log level is not set correctly. Again, the relevant class here is ExceptionHandler.
3. You are looking at the wrong log file. Sometimes, the logger configuration can be quite confusing, especially if running on a "big" application server. Scout uses SLF4J as logging facade. The exact configuration is dependent on the implementation (e.g. Logback or Log4j).
I suggest that you purposely program an exception in a hidden menu (e.g. a NullPointerException) and then set a few breakpoints to "follow" the exception through the code to see where it is consumed.
The Analysis ID is a "correlation ID". Each and every AJAX request from the UI is assigned a random correlation ID. This correlation ID is sent to the server as a HTTP header (X-Scout-Correlation-Id). On the server, it is passed along the Scout run contexts, even over the HTTP service tunnel. The purpose of this ID is to find all events and log messages that belong to the same user request, even over different server tiers. You can always access the current correlation ID using the ThreadLocal org.eclipse.scout.rt.platform.context.CorrelationId.CURRENT. It is automatically set as a SLF4J MDC value (Mapped Diagnostic Context), so you can automatically add it to every log message. Simply include the MDC placeholder scout.correlation.id in your log pattern.
Regards,
Beat
|
|
|
|
Powered by
FUDForum. Page generated in 0.03393 seconds
] 
Search
Help
Register
Login
Home
