Consider the following scenario:
- You are running a public Confluence installation that contains uncountable uses of {a-macro}
- One of those instances on a page somewhere is throwing exceptions
- You didn't trigger the exception and can assume the user didn't report the red "bad macro" they saw on screen.
In the logs all you will see is a stacktrace which ripples from the macro's class through the renderer and beyond. Unfortunately there's no contextual information.
- Which ceo ID was this being rendered against? (if any)
- Which username was logged in at the time? (if any)
There may be other contextual information, but I would like to get the rendering exceptions (where possible) to give me as much contextual information so I can replicate ... the easiest way I can think of doing that is to catch and rethrow/log the runtime & macro exceptions, but tag on the context to the exception message.
Improvement
Resolved
Major
Add RenderContext information to exceptions that filter through the Wiki Renderer
This is what I have implemented so far
2007-03-05 16:39:15,556 ERROR [tcpConnection-8080-0] [renderer.v2.components.MacroRendererComponent] processMacro Unexpected error formatting macro: exceptionmacro
– url: /display/TST/Home | userName: admin | action: viewpage | page: 753666
java.lang.RuntimeException: An exception at Mon Mar 05 16:39:15 EST 2007
at com.atlassian.confluence.extra.exception.ExceptionMacro.execute(ExceptionMacro.java:27)
at com.atlassian.renderer.macro.RadeoxCompatibilityMacro.execute(RadeoxCompatibilityMacro.java:149)
at com.atlassian.confluence.renderer.v2.macros.RadeoxCompatibilityMacro.execute(RadeoxCompatibilityMacro.java:26)
.....
Note the second line containing some logging context.
Rather than only having this for render exceptions, I've added context logging from the top of the request chain. It will be immensely valuable for our support team as well. This has been implemented using Log4J Mapped Diagnostic Contexts (MDC)
Thoughts? Parseable enough?
Chris