<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>I&#39;m not opposed to shortening stack traces but omitting the cause(s) drops vitally important error context in many if not most cases.</div></div></div></blockquote><div><br></div><div>I took some time to review logback source and do some testing. The source was pretty clear that the limit applies to all levels of the stack trace, which is the behavior that Scott expected and what I want. I have tested with an action in the IdP, and with %ex{3} I see 3 lines of stack per level:</div><div><br></div><div><div>2015-03-24 10:56:33,782 - ERROR [net.shibboleth.idp.cas:-2] - Uncaught runtime exception</div><div>java.lang.RuntimeException: Three threw</div><div>        at net.shibboleth.idp.cas.flow.NestedThrowAction.three(NestedThrowAction.java:30)</div><div>        at net.shibboleth.idp.cas.flow.NestedThrowAction.two(NestedThrowAction.java:23)</div><div>        at net.shibboleth.idp.cas.flow.NestedThrowAction.one(NestedThrowAction.java:19)</div><div>Caused by: java.lang.RuntimeException: Sub-three threw</div><div>        at net.shibboleth.idp.cas.flow.NestedThrowAction.subThree(NestedThrowAction.java:43)</div><div>        at net.shibboleth.idp.cas.flow.NestedThrowAction.subTwo(NestedThrowAction.java:39)</div><div>        at net.shibboleth.idp.cas.flow.NestedThrowAction.subOne(NestedThrowAction.java:35)</div></div><div><br></div><div>I have no idea what happened in the case where I spotted this initially; there may be a bug somewhere, but more likely it was a configuration problem unrelated to logging config per se.</div><div><br></div><div>Summary: what we have works like we want.</div><div><br></div><div>M</div><div><div dir="ltr"><div class="gmail_quote"><div><br></div></div></div></div></div></div>