April 2012 - logback-user - mailman3.qos.ch

Does logback support multiple configuration files (logback.xml) for a single application?
by david 3601 23 Apr '12

23 Apr '12

Hi, Here is what I am trying to do: 1. create an infra jar that other application depends on. In this jar file, there will be a logback.xml file for some default logging. 2. if other application defines its own logback.xml, I want the application uses both the logback.xml files. Does logback support that? Thanks a lot for your help! -David

1 0

Re: [logback-user] Nested sifting appenders
by Dario Campagna 20 Apr '12

20 Apr '12

Hi Ceki, > Would you like to post it on this list for future reference? I created a new discriminator taking the code of MCDBasedDiscriminator and modifying the method getDiscriminatingValue(ILoggingEvent event) as follows. public String getDiscriminatingValue(ILoggingEvent event) { Map<String, String> mdcMap = event.getMDCPropertyMap(); // If the MDC is empty return the default path if (mdcMap.isEmpty()) { return defaultValue; } String parentValue = mdcMap.get("parent"); String nodeValue = mdcMap.get("node"); return parentValue + "/" + nodeValue; } Cheers, Dario

1 0

SyslogAppender retains stack trace when it shouldn't
by Don Faulkner 19 Apr '12

19 Apr '12

Hi all, New subscriber & user. I'm trying to configure logback as it's used in the Shibboleth application (http://shibboleth.internet2.edu/, http://wiki.shibboleth.net/) I'm working with version 2.3.6 of their SAML Identity Provider (IdP), which uses version 1.0.0 of logback. Question: How do I configure SyslogAppender to omit stack traces? I'm attempting to configure the system to send certain messages to syslog for a security audit trail (things like authentication success/failure). I've located the correct logger, and I've successfully configured a SyslogAppender to send the events to syslog, but I'm getting an odd bit of a stack trace in the syslog, even though I think I shouldn't. I think my problem is similar/related to Ingebrigt Berg's issue http://mailman.qos.ch/pipermail/logback-user/2012-March/003054.html When the line gets logged to syslog, I see the first line correctly, but that line is followed by a stack trace, except that the beginning of the stack trace is replaced with the string "#011". What I want is no stack trace at all, which I ought to be able to get with %nopex, except that doesn't seem to work. When I dig into the code a bit, I see that the SyslogAppender already defines a prefixPattern which has %nopex in it, so I may be missing something here. Relevant bits of my logging.xml: <appender name="IDP_SYSLOG" class="ch.qos.logback.classic.net.SyslogAppender"> <SyslogHost>localhost</SyslogHost> <Port>514</Port> <Facility>AUTH</Facility> <SuffixPattern> [%logger:%level] %msg %mdc{idpSessionId} from %mdc{clientIP}%nopex</SuffixPattern> </appender> <logger name="edu.internet2.middleware.shibboleth.idp.authn" level="DEBUG"> <appender-ref ref="IDP_SYSLOG"/> </logger> The syslog output looks like: Apr 19 10:58:24 idp1 [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine: DEBUG] Processing incoming request from 192.168.56.1 Apr 19 10:58:24 idp1 [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine: DEBUG] Beginning user authentication process. from 192.168.56.1 Apr 19 10:58:24 idp1 [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine: DEBUG] Filtering configured LoginHandlers: {urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession=edu.internet2.middleware.shibboleth.idp.authn.provider.PreviousSessionLoginHandler@7b8be7, urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport=edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginHandler@11e1813} from 192.168.56.1 Apr 19 10:58:24 idp1 [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine: DEBUG] Filtering out previous session login handler because there is no existing IdP session from 192.168.56.1 Apr 19 10:58:24 idp1 [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine: DEBUG] Selecting appropriate login handler from filtered set {urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport=edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginHandler@11e1813} from 192.168.56.1 Apr 19 10:58:24 idp1 [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine: DEBUG] Authenticating user with login handler of type edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginHandler from 192.168.56.1 Apr 19 10:58:24 idp1 [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginHandler: DEBUG] Redirecting to https://idp1:443/idp/Authn/UserPassword from 192.168.56.1 Apr 19 10:58:24 idp1 [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet: DEBUG] Redirecting to login page /login.jsp from 192.168.56.1 Apr 19 10:58:53 idp1 [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet: DEBUG] Attempting to authenticate user donf from 192.168.56.1 Apr 19 10:58:55 idp1 [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet: DEBUG] User authentication for donf failed from 192.168.56.1 Apr 19 10:58:55 idp1 #011at edu.vt.middleware.ldap.jaas.LdapLoginModule.login(LdapLoginModule.java:138) Apr 19 10:58:55 idp1 #011at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) Apr 19 10:58:55 idp1 #011at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) Apr 19 10:58:55 idp1 #011at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) Apr 19 10:58:55 idp1 #011at java.lang.reflect.Method.invoke(Method.java:616) Apr 19 10:58:55 idp1 #011at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784) Apr 19 10:58:55 idp1 #011at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [...] The lines through "user authentication for donf failed" are expected. The rest are not. I can do the same thing with a RollingFileAppender and it works correctly. Am I missing something? -- me Don Faulkner, CISSP | IT Security <http://its.uark.edu/> at the University of Arkansas <http://www.uark.edu/> contact>> donf(a)uark.edu <mailto:donf@uark.edu> | +1 (479) 575-2905 connect>> uarkITS on Facebook <http://www.facebook.com/uarkITS> | @uaits <http://twitter.com/uaits> | @dfaulkner <http://twitter.com/dfaulkner>

1 0

Associating a per-class instance property with a Logger
by George C. Hawkins 19 Apr '12

19 Apr '12

Hallo -- We have a system where we have what I'll call groups. Each group has a numeric identifier and when a new group is created a corresponding large set of heterogeneous objects are created. These objects are not shared between groups. Whenever any of these objects log anything we always want to see the numeric identifier (of the group to which they belong) in the log message. Ideally I'd create all loggers as instance variables (rather than as static) and at the point of creation somehow associate a group identifier with them. E.g. public class Foo { private final Logger logger = LoggerFactory.getLogger(Foo.class); public Foo(long groupId) { logger.setProperty("groupId", groupId); } } So far the best I can come up with is to create a helper class like so: public static class GroupId { private final String id; public GroupId(long id) { this.id = Long.toString(id); } public Object[] args(Object... o) { MDC.put("group", id); return o; } } I then make one of these a member of each class that also has a logger - and then require people to only use the Logger methods that take an Object array and use them like so: logger.error("expected [0, 1] but received [{}, {}]", groupId.args(x, y)); [ If I do this I don't have to move from static to instance variables for my loggers ] This approach means I have to update MDC every call (I thought of maintaining a lastId ThreadLocal value but it didn't look as if the cost of using this to avoid not calling put on MDC every time would really save anything). And it also means people have to use the GroupId instance even if they have no arguments for a given log message, e.g.: logger.error("limit exceeded", groupId.args()); I'm inclined to think using Markers would be better. I would create a Marker instance in every class where I also had a logger, and initialize it such that its name would return something like "groupId=" + groupId. However comments like the following on stackoverflow suggest this is an inappropriate use of Markers: http://stackoverflow.com/a/4167298/245602 At the moment though I think I'll ignore this and uses Markers unless someone can suggest a better approach? Regards, /George ________________________________ The information in this e-mail is intended only for the person or entity to which it is addressed. It may contain confidential and /or privileged material. If someone other than the intended recipient should receive this e-mail, he / she shall not be entitled to read, disseminate, disclose or duplicate it. If you receive this e-mail unintentionally, please inform us immediately by "reply" and then delete it from your system. Although this information has been compiled with great care, neither IMC Financial Markets & Asset Management nor any of its related entities shall accept any responsibility for any errors, omissions or other inaccuracies in this information or for the consequences thereof, nor shall it be bound in any way by the contents of this e-mail or its attachments. In the event of incomplete or incorrect transmission, please return the e-mail to the sender and permanently delete this message and any attachments. Messages and attachments are scanned for all known viruses. Always scan attachments before opening them.

2 1

Re: [logback-user] Nested sifting appenders
by Dario Campagna 19 Apr '12

19 Apr '12

Hi Ceki, [cut] > Sifting appenders cannot be nested. The error messages don't make much > sense. Probably due to the fact that sifting appenders cannot be nested. Ok. [cut] > Anyway, instead of nesting sifting appender, you should create your own > discriminator class which merges the values for MDC keys parent and node > into ${parent}/${node}. Just emulate the code in MDCBasedDiscriminator > [1]. If you run into trouble ask for help here. Thank you for your suggestion. I implemented my own discriminator and it works. Cheers, Dario

2 1

Nested sifting appenders
by Dario Campagna 18 Apr '12

18 Apr '12

Hi, I am Dario Campagna, I am a software developer working for an Italian company. Few days ago I discovered Logback and started studying it to see if it is suitable for the application I am working on. In particular, I made some experiments with different appenders and layouts defined in a configuration file. I encountered some problems trying to run the application I am using for my experiment with a configuration file that attach to the root logger the following sifting appender. <appender name="SIFT-txt" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator> <key>parent</key> <defaultValue>unknown</defaultValue> </discriminator> <sift> <appender name="SIFT-${parent}" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator> <key>node</key> <defaultValue>unknown</defaultValue> </discriminator> <sift> <appender name="FILE-${parent}-${node}" class="ch.qos.logback.core.FileAppender"> <file>${parent}/${node}/log.txt</file> <append>true</append> <layout class="ch.qos.logback.classic.PatternLayout"> <pattern>%level%date{ISO8601}: %mdc - %msg%n </pattern> </layout> </appender> </sift> </appender> </sift> </appender> With the above appender I would like to write a log event in a file whose path depends on two keys of the mdc. The ideas is that the outmost sifting appender discriminates on the key named "parent", while the innermost sifting appender discriminates on the key named "node". The FileAppender writes log events to a file inside the ${parent}/${node} folder. When I run my application I get the following errors (I omit the full stack trace of the exception) 17:48:15,213 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.classic.sift.SiftingAppender] 17:48:15,213 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [SIFT-txt] 17:48:15,233 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.sift.MDCBasedDiscriminator] for [discriminator] property 17:48:15,233 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Pushing component [discriminator] on top of the object stack. 17:48:15,243 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Popping appender named [SIFT-txt] from the object stack 17:48:15,243 |-INFO in ch.qos.logback.classic.joran.action.JMXConfiguratorAction - begin 17:48:15,243 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to ALL 17:48:15,243 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [SIFT-txt] to Logger[ROOT] 2012-04-18 17:48:15.823::INFO: No Transaction manager found - if your webapp requires one, please configure one. 17:48:15,580 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.classic.sift.SiftingAppender] 17:48:15,581 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [SIFT-Process_0] 17:48:15,581 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.sift.MDCBasedDiscriminator] for [discriminator] property 17:48:15,581 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Pushing component [discriminator] on top of the object stack. 17:48:15,581 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@38:11 - no applicable action for [sift], current pattern is [[configuration][appender][sift]] 17:48:15,582 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@39:87 - no applicable action for [appender], current pattern is [[configuration][appender][sift][appender]] 17:48:15,582 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@40:13 - no applicable action for [file], current pattern is [[configuration][appender][sift][appender][file]] 17:48:15,582 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@41:15 - no applicable action for [append], current pattern is [[configuration][appender][sift][appender][append]] 17:48:15,591 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Pushing component [layout] on top of the object stack. 17:48:15,607 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Popping appender named [SIFT-Process_0] from the object stack 17:48:15,607 |-ERROR in ch.qos.logback.classic.sift.SiftingAppender[SIFT-Process_0] - Appender [SIFT-Process_0] failed to append. java.lang.NullPointerException at java.lang.NullPointerException at at ch.qos.logback.core.sift.SiftingAppenderBase.append(SiftingAppenderBase.java:79) I have not been able to discover the cause of the errors. In particular, I do not understand the following error 17:48:15,581 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@38:11 - no applicable action for [sift], current pattern is [[configuration][appender][sift]] Isn't the configurator/appender/sift a pattern defined by logback-classic? Is the nesting of sifting appender in the configuration file allowed? If it is not allowed, is this limitation mentioned somewhere? Best regards, Dario

2 1

How to load logback.xml from ear?
by sdoca sdoca 17 Apr '12

17 Apr '12

Hi, I have an ear file deployed to Glassfish (v.3.1.1) and cannot get the logback.xml to be loaded. I have bundled it in the ear in the META-INF directory. Where should it be located? Thanks!

3 2

Logback + Perf4j groovy configuration
by Arsene Lee 17 Apr '12

17 Apr '12

Hi, I'm using Logback with groovy configuration. I want to use Perf4j with Logback but I'm having problem with the groovy configuration. I want to add an AsyncCoalescingStatisticsAppender. The XML confugration looks like this. <appender name="CoalescingStatistics" class="org.perf4j.logback.AsyncCoalescingStatisticsAppender"> <param name="TimeSlice" value="60000"/> <appender-ref ref="graphExecutionTimes"/> <appender-ref ref="graphExecutionTPS"/>  <appender-ref ref="perf4jJmxAppender"/> </appender> I don't know how to translate it into groovy's configuration. Especially the the appender-ref ref part. I tried the logback.xml to logback.groovy translator to translate but it generates which I don't think it is correct. appender("CoalescingStatistics", AsyncCoalescingStatisticsAppender) { param = appender-ref = appender-ref = appender-ref = } Regards, Arsene

2 1

ContextDetachingSCL, because it does not implement any of the required ServletContextListener …. ?
by R. van Twisk 13 Apr '12

13 Apr '12

Hello, I am trying to deploy a application on a glassfish cluster and I am receiving this warning: [#|2012-04-13T13:35:34.223-0400|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=25;_ThreadName=Thread-2;|Exception while invoking class com.sun.enterprise.web.WebApplication start method java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: java.lang.IllegalArgumentException: PW C1430: Unable to add listener of type: ch.qos.logback.classic.selector.servlet.ContextDetachingSCL, because it does not implement any of the required ServletContextListener, ServletContextAttributeLi stener, ServletRequestListener, ServletRequestAttributeListener, HttpSessionListener, or HttpSessionAttributeListener interfaces I am at a loss why I get this warning because ContextDetachingSCL implements ServletContextListener. So That can't be the issues. What else should I lookout for? Ries

1 0

RollingFileAppender - Current Log with No Date
by sdoca sdoca 13 Apr '12

13 Apr '12

Hi, Is it possible to set up a RollingFileAppender so that the current log file (i.e. today's) doesn't have a date as part of the filename? Then when the log rolls over, the date is appended to the filename similar to how log4j's DailyRollingFileAppender works? Thanks!

2 2