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

Tomcat Multi Instance - Logback-Access
by MikeJC 25 Jul '12

25 Jul '12

How can I configure logback-access so that it can run in multi-instances? If I drop it in the instance conf folder I see the message "[/opt/apache-tomcat/conf/logback-access.xml] does not exist". If I drop at the root level I do not see any logging from the instance. /opt/apache-tomcat main install -- multi instance -- /opt/tomcat/app1 /opt/tomcat/app2 I have placed logback-access and logback core Tomcat : 7.0.29 logback-access-1.0.6.jar logback-core-1.0.6.jar -- View this message in context: http://old.nabble.com/Tomcat-Multi-Instance---Logback-Access-tp34207160p342… Sent from the Logback User mailing list archive at Nabble.com.

1 0

Changing logback configurations programatically
by Steve Cohen 24 Jul '12

24 Jul '12

With the scan option logback can change its configuration on the fly. I would like to take this one step further by adding to my Java Swing application that uses logback, a facility through which the user could specify a logging configuration at the direction of technical personnel, within the application's user interface, to change logging configuration without having to copy files, etc. The user would just indicate that they wanted "configuration 4" for example and it would happen. This would be implemented by the program writing a file to the place where the program had specified the configuration to live. I could obviously do this by reading the system property logback.configurationFile. Is there another way? Is there an API that provides this information? +

1 0

Hide container's logback.xml from web application
by Ross Sargant 23 Jul '12

23 Jul '12

Hello, I have a pretty simple setup consisting of Jetty and two web applications. The logging for the Jetty container and each web app is automatically configured with separate logback.xml files. The configuration works but there is a nuance which I've never been able to resolve. The web application's class loader "sees" the logback.xml loaded by the Jetty container's parent class loader. This causes logback to dump its configuration status on web app initialization to show me the "Resource [logback.xml] detected multiple times on the classpath" warning. One entry under WEB-INF/classes/logback.xml and one under the jetty resources directory. I completely understand what is going on but I'd really prefer not to look at this output all the time. Is there anyway I can re-arrange the setup to support automatic isolated configuration of jetty and the web apps without having to see this warning? I repeat, the configuration is working correctly and it is only this output (shown on the web app initialization) which is a little irksome. Thank you! -- Ross Sargant Software Engineer p: 954-796-2592 email: rsargant(a)tvrc.com TVR Communications LLC 541 S. State Road 7,Suite 5,Margate, Florida,33068 http://www.tvrc.com

1 0

Programmatic configuration of OutputStreamAppender
by Markos Fragkakis 18 Jul '12

18 Jul '12

Hi all, I am trying to configure Logback programmatically to write logs into an OutputStream. The following libraries are in my classpath: * logback-core-1.0.6.jar * logback-classic-1.0.6.jar * slf4j-api-1.6.4.jar In fact, I _do_ get the logs in the console, which tells me that Logback has started with the default configuration of outputting to the Console. What I want, however, is to programmatically add an appender to a Logger, so that it also outputs to an OutputStream. The following snippet shows what I am doing, and the result is only writing logs to the Console: Any ideas what I'm doing wrong? private static ByteArrayOutputStream baos = newByteArrayOutputStream(100000000); ... private void method() { OutputStreamAppender<ILoggingEvent> logbackAppender = newOutputStreamAppender<ILoggingEvent>(); LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); PatternLayoutEncoder encoder = new PatternLayoutEncoder(); encoder.setContext(lc); encoder.setPattern("%-5level [%thread]: %message%n"); logbackAppender.setContext(lc); logbackAppender.setName("Output stream logback appender"); logbackAppender.setOutputStream(baos); logbackAppender.setEncoder(encoder); LOGGER.addAppender(logbackAppender); LOGGER.debug("This"); LOGGER.info("can't be"); LOGGER.info("happening") } -- Sent from my iPhone

2 1

Inconsistency in printing Throwable instances?
by Abraham Lin 16 Jul '12

16 Jul '12

Hi, In comparing the outputs of Throwable#printStackTrace and logback, I found an inconsistency in how the Throwable instances are printed. While the former delegates to the Throwable instance's #toString method, the latter (partially) re-implements the default implementation in Throwable, which means that data contained in the #toString methods of Throwable subclasses is discarded. While this is easy to work around in my own code, there is still a problem when working with third-party libraries. Is there a configuration option that would allow me to specify my own IThrowableProxy implementation? (I couldn't find any pages describing the extension points and how to activate them.) Or would it be more appropriate to modify the ThrowableProxyUtil class so that it behaves similarly to #printStackTrace? Any ideas would be greatly appreciated. Thanks in advance! -Abraham

2 4

logging_event_property
by Odelya Holiday 11 Jul '12

11 Jul '12

Hi! What is the goal of logging_event_property table? Is there a way to remove it or get rid of it? Thanks -- Odelya

3 7

Re: [logback-user] Custom Logger for logging custom object?
by Adam Brightwell 09 Jul '12

09 Jul '12

Hey Andrzej, Thanks for the suggestion. I agree that this would be a straight forward solution. Unfortunately, overriding the toString() method will not work as the format of the log message must be configurable. Much in the same way that you can configure the format of a log message using the PatternLayout. For obvious reasons, I believe the format and the message data should be independent of each other. Thanks again, I appreciate the quick response. Thanks, Adam From: Andrzej Zadorozny <andrzej.zadorozny(a)gmail.com<mailto:andrzej.zadorozny@gmail.com>> Date: Friday, July 6, 2012 10:20 PM To: Adam Brightwell <abrightwell(a)lce.com<mailto:abrightwell@lce.com>> Subject: Re: [logback-user] Custom Logger for logging custom object? Hi Adam, If you could have the POJOs implement their own toString() method (if it's possible in your situation), I think that would be a straight forward solution. CheerZ! :) On Fri, Jul 6, 2012 at 7:15 PM, Adam Brightwell <abrightwell(a)lce.com<mailto:abrightwell@lce.com>> wrote: Hey All, I have an interesting logging requirement in front of me. I am required to log application specific information that is contained within a custom POJO. The developers will create and fill these POJO's with the appropriate information when a logging "event" takes place. The hope was that it could then be passed off to our logging system and it would know what to do with it. However, the obvious problem is that Logger can't be overridden to allow the overloading of the info, warn, error, etc. methods to receive the custom POJO. I have considered simply implementing the "Delegation Pattern" implementing the slf4j Logger interface and wrapping the logback Logger which would allow me to simply overload the necessary methods. I was curious what the communities thoughts might be on this potential solution. Are there other recommendations that might work better for my purposes? Any help, recommendations or guidance would be greatly appreciated. Thanks, Adam _______________________________________________ Logback-user mailing list Logback-user(a)qos.ch<mailto:Logback-user@qos.ch> http://mailman.qos.ch/mailman/listinfo/logback-user -- Andrzej Zadorozny

2 1

Java programmatic configurations
by Martinus Martinus 09 Jul '12

09 Jul '12

Hi, What is the equivalent programmatical java code for below logback.xml configuration : <configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">  <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</pattern> </encoder> </appender> <appender name="SYSLOG" class="ch.qos.logback.classic.net.SyslogAppender"> * <syslogHost>myhost</syslogHost>* * <facility>USER</facility>* * <suffixPattern>[%thread] %logger *%msg</suffixPattern> </appender> <root level="debug"> <appender-ref ref="SYSLOG"/> <appender-ref ref="STDOUT"/> </root> </configuration> Thanks.

2 2

AUTO: Manfred Kuhlmann is out of office. (Rückkehr am 30.07.2012)
by manfred.kuhlmann＠steria-mummert.de 07 Jul '12

07 Jul '12

Ich werde ab dem 06.07.2012 nicht im Büro sein. Ich kehre zurück am 30.07.2012. I will be out of the office starting 06.07.2012. I will be back on 30.07.2012. Ihre Nachricht werde ich nach meiner Rückkehr beantworten. Mit freundlichen Grüßen Manfred Kuhlmann Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht " [logback-user] Custom Logger for logging custom object?" gesendet am 07.07.2012 03:15:50. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist. Steria Mummert Consulting AG Vorsitzender des Aufsichtsrates: Jürgen Sponnagel - Vorstand: Oliver Nazet (Vors.), Dr. Reinhard Liedl, Dr. Fritz Moser Gesellschaftssitz: Hamburg - HR B 61 116 Amtsgericht Hamburg - USt-ID-Nr.: DE118671351 Bitte denken Sie an Ihre Verantwortung gegenüber der Umwelt: Jede ausgedruckte E-Mail verursacht ca. 0,3 Gramm CO2 pro Seite. Diese Nachricht kann vertrauliche Informationen enthalten und ist allein für den Adressaten bestimmt. Wenn Sie nicht der rechtmäßige Empfänger sind, sind der Zugriff, die Weiterleitung, das Kopieren, die Veröffentlichung oder anderweitige Verwendung des Inhalts untersagt. In diesem Fall bitten wir Sie, den Absender unverzüglich zu informieren und diese E-Mail sowie sämtliche Kopien dieser E-Mail zu löschen. Der Inhalt von E-Mails innerhalb des Netzwerks kann überprüft werden, um die Übereinstimmung mit den geltenden Firmenrichtlinien und Vorgehensweisen zu gewährleisten. E-Mails können auf dem Transportweg von Dritten verändert werden, so dass deren Vollständigkeit und Echtheit nicht garantiert werden können. This e-mail communication may contain confidential information and is intended only for the recipient. If you are not the intended recipient you are not allowed to read, copy, distribute, publicize or use the content of this e-mail in any way. Please notify the sender and delete the e-mail and any copies of it. The content of e-mails within our network may be monitored to ensure compliance with company policies and procedures. E-mails can be alterated by third parties in transit. Therefore any e-mail is susceptible to alteration and its integrity cannot be assured.

1 0

Custom Logger for logging custom object?
by Adam Brightwell 07 Jul '12

07 Jul '12

Hey All, I have an interesting logging requirement in front of me. I am required to log application specific information that is contained within a custom POJO. The developers will create and fill these POJO's with the appropriate information when a logging "event" takes place. The hope was that it could then be passed off to our logging system and it would know what to do with it. However, the obvious problem is that Logger can't be overridden to allow the overloading of the info, warn, error, etc. methods to receive the custom POJO. I have considered simply implementing the "Delegation Pattern" implementing the slf4j Logger interface and wrapping the logback Logger which would allow me to simply overload the necessary methods. I was curious what the communities thoughts might be on this potential solution. Are there other recommendations that might work better for my purposes? Any help, recommendations or guidance would be greatly appreciated. Thanks, Adam

1 0