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.