Hello, So, no response so far, but I also tried to code a solution for this. Unfortunately, I'm not familiar with the inner workings of Logback, and I couldn't crack anything operational. Approaches tried: to create an encoder that holds a level-layout, later a level-encoder map, and choose the appropriate object inside 'doEncode'; the question is that some initialization is needed on layouts and encoders, including a context on both situations, and sharing this context between all these objects does not seem to work, not sure why. Using a map of encoders I tried to use them separately for encoding sharing the same context, no good; with a map of layouts I tried to replace my encoder's layout with the appropriate one, then back to the original layout, and it also does not work. I'm not even posting my code here, as I believe this is the wrong way to implement this. Also, just now reading the archive, I noticed that the previous messages, from Shane Kelly, are basically the same issue as mine with a different approach. Hopefully a solution can fit both. Thanks again!

Date: Wed, 16 May 2012 09:27:16 -0400 Subject: [logback-user] Multiple layouts for a single appender

Hello, My situation is this: on certain specific and frequent log statements, I need the stacktrace to identify the method that needs to be investigated. However, the whole stacktrace is too long and unnecessary in this case (it is generating too much logging and garbage), but in every other, it is useful. I'd like to change the layout for this situation, and use %throwable{5}, for example. So, I found nothing on the manual similar to this, and nothing searching around, maybe I'll need a custom class. If so, how could I do it? Multiple filtered appenders writing to the same file seems too much overhead and troublesome; I think the best approach would be a custom encoder, and do the selection inside 'doEncode', based on some event parameter, probably a specific marker. I'm just analyzing the possibilities, no coding yet, so I'm not aware of any shortcomings or limitations. Given the case, is there any API class I'm missing to do this? Should I take the custom code path? Thanks!

On 16.05.2012 15:27, Y M wrote:

Hello,

My situation is this: on certain specific and frequent log statements, I need the stacktrace to identify the method that needs to be investigated. However, the whole stacktrace is too long and unnecessary in this case (it is generating too much logging and garbage), but in every other, it is useful. I'd like to change the layout for this situation, and use %throwable{5}, for example.

So, I found nothing on the manual similar to this, and nothing searching around, maybe I'll need a custom class. If so, how could I do it? Multiple filtered appenders writing to the same file seems too much overhead and troublesome- I think the best approach would be a custom encoder, and do the selection inside 'doEncode', based on some event parameter, probably a specific marker. I'm just analyzing the possibilities, no coding yet, so I'm not aware of any shortcomings or limitations.

There is support exactly for this type of situation. See the docs for PatternLayout [1]. In particular, the docs on %ex conversion word. Here is the relevant quote: This conversion word can also use evaluators to test logging events against a given criterion before creating the output. For example, using %ex{full, EX_DISPLAY_EVAL} will display the full stack trace of the exception only if the evaluator called EX_DISPLAY_EVAL returns a negative answer. Evaluators are described further down in this document. Refer to [2] for evaluators. Let us know if this approach works for you. [1] http://logback.qos.ch/manual/layouts.html#ClassicPatternLayout [2] http://logback.qos.ch/manual/layouts.html#Evaluators -- Ceki http://twitter.com/#!/ceki