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.
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. Ralph 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@qos.ch http://qos.ch/mailman/listinfo/logback-user
Hello Mel/machintruc, You can pass data to your custom appender via two SLF4J primitives. 1) via MDC MDC is handy if you have contextual information which does not change over several consecutive logger calls. Typical values are userId, user's ip address, transaction id. 2) via Parameters to the printing methods of a logger The trace(), debug(), info(), warn() and error() are the printing methods defined in the org.slf4j.Logger interface. These methods take parameters which are typically used to avoid parameter concatenation for disabled log statements (essentially a performance trick). See http://www.slf4j.org/faq.html#logging_performance for more info. However, you can also pass data using the parametrized form of printing methods. For example, Map map = new HashMap(); map.put("context1", "value1"; map.put("context2", value2"); logger.debug("the sky is blue", map); Note that the formatting message has no anchor, i.e. the "{}" pair. You have not explained what the context information consists of. In the absence of more information, that's the best advice I can give. Cheers, 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.
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Ceki Gulcu wrote:
You can pass data to your custom appender via two SLF4J primitives.
1) via MDC
[...]
2) via Parameters to the printing methods of a logger
[...]
I was going to pick option 2, but just realized that there is no API in slf4j Logger to have both the parameters for formatted message AND a Throwable. I can also see that this has been an ongoing debate, therefore I believe that my use case would provide an argument for those pushing to get that API. 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?
-- View this message in context: http://www.nabble.com/custom-fields-tp24598967p24924171.html Sent from the Logback User mailing list archive at Nabble.com.
participants (4)
-
Ceki Gulcu -
Mel T -
Mel T.
-
Ralph Goers