Closed hohwille closed 10 years ago
We should overwrite getMessage to return rawMessage + "(" + uuid + ")" That should be reasonable for most case where you use the message, e.g. for displaying it in a user interface, result file etc
Fixed. We are using a newline and then append the UUID instead of parenthesis as this is already the behavior of toString() and how the exceptions are logged by log4j. Here you can see the stacktrace of an NlsNullPointerException logged with logback. This exception has a custom code (NPE) that is also logged after the UUID. If no custom code is defined, this will be omitted.
22:14:38.025 [main] ERROR n.s.m.u.e.api.NlsThrowableTest - This is a test and should contain the UUID and code of the exception net.sf.mmm.util.exception.api.NlsNullPointerException: The object "bad boy" is null! c3b5f44d-9b0d-41ef-91a5-e948cc518742:NPE at net.sf.mmm.util.exception.api.NlsThrowableTest.testNlsRuntimeExceptionSerializable(NlsThrowableTest.java:139) ~[test-classes/:na] ...
Unfortunately logback does not go with the default behaviour when logging exceptions such as calling toString() on the throwable. It extracts classname, message, stacktrace elements and recursively the cause. Therefore UUID is not written to the log as it is not contained in the result of getMessage(). We should consider if we put the UUID into the message and add a method to get the raw message or omitt it in getLocalizedMessage() or if we want to find another way (e.g. create a faked StackTraceElement and insert it into the stacktrace) but this sounds odd to me.
An absolute must is that we have the UUID in the log. The only question is: What is the best way to ensure this (as we can not and do not want to influence logging implementations)?