additional informations for appenders?

Hello, I would like to use slf4j together with logback as logging framework. But I have some special requirements, which I'm not happy with them, but I can not drop them. 1) I need to transfer additional informations with each request to the appender. E.g. a thing like a "logDocumentId". Furthermore, I need to have multiple of such Ids active in one session/thread. I have to give the id int each request and an own appender implementation has to do something with it. What would be the best way to carry such Id besides the standard log message and parameters throug the slf4j api to the logback appenders? Can I store such objects in the MDC? How does this affect the performance, when used on every log request? Or would it be better to add the informations as additional elements at the end of the "argArray" parameter of the Logger methods, hoping that all appenders will ignore them, when there is no "{}" for the position? 2) I know that logback can be reconfigured on runtime, but all I know is that during this re-configuration, all log-requests will be droped. Is there a way to only add / remove / change a single TurboFilter or Appender without losing processing of requests by the "normal" loggers / appenders? Best regards, Lars

Hi Lars, 1) For data which stays relatively stable during the scope of (service) request, MDC is the way to go. 2) You can remove a TurboFilter and attach a modified version programmatically. You don't need to reset the LoggerContext. HTH, On 21/09/2011 3:09 PM, Lars Fischer wrote:
Hello,
I would like to use slf4j together with logback as logging framework. But I have some special requirements, which I'm not happy with them, but I can not drop them.
1) I need to transfer additional informations with each request to the appender.
E.g. a thing like a "logDocumentId". Furthermore, I need to have multiple of such Ids active in one session/thread. I have to give the id int each request and an own appender implementation has to do something with it.
What would be the best way to carry such Id besides the standard log message and parameters throug the slf4j api to the logback appenders?
Can I store such objects in the MDC? How does this affect the performance, when used on every log request?
Or would it be better to add the informations as additional elements at the end of the "argArray" parameter of the Logger methods, hoping that all appenders will ignore them, when there is no "{}" for the position?
2) I know that logback can be reconfigured on runtime, but all I know is that during this re-configuration, all log-requests will be droped.
Is there a way to only add / remove / change a single TurboFilter or Appender without losing processing of requests by the "normal" loggers / appenders? Best regards, Lars

Hello Ceki, thank you for your answer! 2011/9/22 Ceki Gülcü <ceki@qos.ch>:
1) For data which stays relatively stable during the scope of (service) request, MDC is the way to go.
What about data which could change, lets say for every log event? (e.g. two alternating docIds) Reading the documentation, the MDC is no good choice for such often changing data. Can I put this data into the Object[] of the Logger methods?
2) You can remove a TurboFilter and attach a modified version programmatically. You don't need to reset the LoggerContext.
This sounds very good. Regards, Lars

On 23.09.2011 10:40, Lars Fischer wrote:
Hello Ceki,
thank you for your answer!
2011/9/22 Ceki Gülcü<ceki@qos.ch>:
1) For data which stays relatively stable during the scope of (service) request, MDC is the way to go.
What about data which could change, lets say for every log event? (e.g. two alternating docIds) Reading the documentation, the MDC is no good choice for such often changing data.
If the alternation occurs in the same thread very frequently, then you are correct, MDC is not a good choice. However, if alternation frequency is say every 10 or 20 logging events, then MDC should be OK.
Can I put this data into the Object[] of the Logger methods?
Yes, you can do that. For example, if docId data is typed as DocID, you can write: DocId docId1 = new DocId("1"); DocId docId2 = new DocId("2"); logger.info("starting processing", docId1); logger.info("starting processing", docId2); // now with two parameters logger.info("adding a paragraph {}", paragraph, docId1); logger.info("end of processing", docId1); logger.info("end of processing", docId2); Please let me know if you run into trouble with this approach. It should work though. If you wish to output the data using PatternLayout, you will need to write a custom converter. Writing a custom converter is documented at [1]. Again, in case you encounter any difficulty, just ask for help here. [1] http://logback.qos.ch/manual/layouts.html#customConversionSpecifier -- Ceki http://twitter.com/ceki

Hello, Is there a way to add rules to interpret the data in logback.xml before logback starts its 1st initialisation, I want to add some specific parameters to logback.xml which i will use in my application specific logger Or is there a way to launch logback configuration on demand (not starts at the application starts) i can use JoranConfigurator but this means 2 times configuration Thanks

Hello, Is there a way to programmatically get the attached appenders to a given logger ? something like Logger.getAppenders() which returns appenders names or objects Thanks

Hi, Look at the iteratorForAppenders method in the Logger class: http://logback.qos.ch/apidocs/ch/qos/logback/classic/Logger.html HTH, -- http://twitter.com/ceki On 26/09/2011 11:51 AM, BAKHTI Mohammed wrote:
Hello,
Is there a way to programmatically get the attached appenders to a given logger ? something like Logger.getAppenders() which returns appenders names or objects
Thanks

Thanks :)
Date: Mon, 26 Sep 2011 14:25:29 +0200 From: ceki@qos.ch To: logback-user@qos.ch Subject: Re: [logback-user] How to get logger attached appenders
Hi, Look at the iteratorForAppenders method in the Logger class: http://logback.qos.ch/apidocs/ch/qos/logback/classic/Logger.html HTH, -- http://twitter.com/ceki
On 26/09/2011 11:51 AM, BAKHTI Mohammed wrote:
Hello,
Is there a way to programmatically get the attached appenders to a given logger ? something like Logger.getAppenders() which returns appenders names or objects
Thanks
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user

Hello again, I'm having some questions about JMS Appenders : - How to detect if the broker is up or no ? when logback starts it not give any exception or error message if the broker endpoint is down - Is there a way to support the failover protocol ? any idea how to do ? Thanks
participants (4)
-
BAKHTI Mohammed
-
Ceki Gulcu
-
Ceki Gülcü
-
Lars Fischer