[logback-user] custom fields

Ralph Goers rgoers at apache.org
Wed Jul 22 08:05:48 CEST 2009

We use the MDC for some of this. It is a very natural fit if you have  
values such as the userid, user's ip address, etc that you want in  
multiple log records. For event handling we use the EventData object  
and EventLogger in the SLF4J extensions. The EventData gets passed as  
the "message" and can be easily converted back to a Map in the  
Appender.  With these two constructs we have found SLF4J/Logback to  
work very well.


On Jul 21, 2009, at 7:16 PM, Mel T. wrote:

> Hi,
> We have an in-house logger that we want to get rid of. This logger has
> application specific functionality.
> - We store logs in a database table
> - We have specific columns that put some very-frequently used context
> information
> - For that purpose, our logger has methods like this:
>   log(String message, String someContextID1, String  
> someContextID2, ...);
> - This is added to the DB with specific columns for someContextID1,
> someContextID2, etc...
> - We have a log viewer that allows to select logs based on that
> context information.
> So we need an appender that will continue to fill up that same table.
> If we move to a logger like logback, I am unsure how to best handle
> our application need.
> This first comes to mind:
> - Create our own facade that adds the specific log methods (like  
> above)
> - This facade assembles these arguments into a parsable message given
> to sfl4j/logback
> - An in-house DBAppender can parse the message to extract the
> arguments and store them in the right column.
> Or is there a more natural way to do that?
> I looked at markers, MDC, but is is not clear to me if any of them
> would be good for that. Maybe MDC could be used that way:
> - Create our own facade that adds the specific log methods (like  
> above)
> - This facade assembles these arguments and places them in MDC
> - An in-house DBAppender can read the MDC and store values in the  
> right column.
> Also, is'nt adding another facade on top of SLF4J/logback a little too
> much? Since we may add out own facade, should'nt we directly use
> logback?
> --
> Mel T.
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://qos.ch/mailman/listinfo/logback-user

More information about the Logback-user mailing list