January 2015 - logback-user

Hiding Groovy language internal methods in Logback log files, to locate the "real" call to the logger
by Christopher BROWN 22 Jan '15

22 Jan '15

Hello, I'll start with a quick clarification, to avoid confusion: my question relates to usage of Logback loggers via SLF4J (and, sometimes but not always, also via the Log4J-to-SLF4J bridge) from Groovy code, and is not about configuring Logback using Groovy (as it happens, we configure Logback directly via the API, and not using configuration files). In Groovy code, it's perfectly fine to write something like this: def somevar = 'world' log.debug "Hello ${somevar}" The "debug" method call doesn't need parentheses because there's only one parameter (and, furthermore, it's using the "GString" interpolation approach). Our application can be extended with Groovy scripts by our customers, so we find this in their code when helping them customize. So we often end up with entries like this (obviously simplified here) in our log files: 2015-01-20 17:55:17,715 DEBUG - [Category$debug.call:?] Hello world So the class name and method name being reported as the location are actually the locations of the Groovy call site, and not the actual "log.debug" call. Some sort of general capability along the lines of LOGBACK-540 might be helpful, but here the requirement is just to truncate the topmost "internal Groovy" stack frame (or frames) so that the reported location is the call into the logger in the script. Is this possible, and how could it be achieved? I seem to remember an example of this a long time ago, but I can't find it amongst all the search results referring to Groovy configuration. Thanks, Christopher

1 0

ContextJNDISelector required in tomcat6 with logback-access?
by kevko5212 . 21 Jan '15

21 Jan '15

I have 2 webapps, each with their own maven dependencies of slf4j and logback-classic declared, deployed to tomcat6. Each webapp writes to their own log file. Works beautifully. However, when deployed to a production tomcat6 configured with logback-access, the webapp logback configs do not appear to be read and the log files are not created. If I add code to the contextInitialized() of my ServletContextListener like the one found here: http://logback.qos.ch/manual/configuration.html#joranDirectly the log files are created for both webapps, but then log messages from both webapps are written to only one of the log files. I also found that if I add <contextName>WEBAPP_NAME<contextName> to the logback config files of each webapp, where WEBAPP_NAME = unique name for the given webapp, an error message pops up when deploying the 2nd webapp saying something like "the context name has already been set to appA". This leads me to believe that both apps are sharing the same Logger Context, as described here: http://logback.qos.ch/manual/loggingSeparation.html I followed the steps to enable ContextJNDISelector, and it does now work. Each webapp is logging to their respective log file. However, there are a large number of other webapps that are deployed to the same environment, and I am unsure of the impact enabling ContextJNDISelector might have on them. My question is, is something like ContextJNDISelector necessary on an environment using logback access? Or should I be able to simply include the necessary maven dependencies in appA and appB, and perhaps missed something small along the way? Shouldn't tomcat's child-first class loading allow me to do so?

1 0

How to save logs in home directory of application
by Mejmoo 20 Jan '15

20 Jan '15

Hi, I need very simple thing. I need to put any logs from file appender to the file in application directory, where jar is located. (this is Java desktop application). If I define it explicitly it works: <file>C:\logname.log</file> but this does not work <file>logname.log</file> I know I can pass some variable to java interpreter and use it as ${LOGHOME} and then use it like <file>${LOGHOME}/logname.log</file> but it is really needed? Thanks, Martin

2 1

conditions in logback configuration
by Aneesh Joseph 07 Jan '15

07 Jan '15

Hi, I'm trying to remove redundant logback config files by using janino's conditional processing. Below is the conditional logic which I had added within the configuration tag (along with the appender details) <root level="INFO"> <appender-ref ref="ROLLING" />  <if condition='property("os.name").contains("win")'> <then> <appender-ref ref="CONSOLE" /> </then> <else> <appender-ref ref="EMAIL" /> </else> </if> </root> but this throws the below errors when logback is initialized 12:30:34,877 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@90:55 - no applicable action for [if], current pattern is [[configuration][root][if]] 12:30:34,877 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@91:10 - no applicable action for [then], current pattern is [[configuration][root][if][then]] 12:30:34,877 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@92:35 - no applicable action for [appender-ref], current pattern is [[configuration][root][if][then][appender-ref]] 12:30:34,877 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@94:10 - no applicable action for [else], current pattern is [[configuration][root][if][else]] 12:30:34,877 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@95:35 - no applicable action for [appender-ref], current pattern is [[configuration][root][if][else][appender-ref]] The configuration works fine if I remove the conditional logic and use something like <root level="INFO"> <appender-ref ref="ROLLING" /> <appender-ref ref="CONSOLE" /> <appender-ref ref="EMAIL" /> </root> I have already added janino as a Maven dependency. How can I configure this correctly in such a way that the CONSOLE appender is used only on Windows and the EMAIL appender everywhere else? Thanks, Aneesh

1 0