[logback-user] Multiple layouts for a single appender/encoder

Y M ym119162 at hotmail.com
Fri May 18 23:59:38 CEST 2012


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!

 		 	   		  


More information about the Logback-user mailing list