January 2007 - logback-user

Using logback in tomcat
by Michael Abato 17 Apr '07

17 Apr '07

I'm successfully using logback with Tomcat and have a small suggestion that will help people with complex deployments: look for logback-access.xml in system property catalina.base rather than catalina.home. Tomcat is intentionally setup such that multiple instances (java VMs) can be running off the same copy of the tomcat distribution and set up private CATALINA_BASE directories for server config, logs, temp space, etc. Such setups will naturally want to configure logback in CATALINA_BASE, not in the (potentially read-only) CATALINA_HOME. In cases where the user does *not* set CATALINA_BASE, it takes the same value as CATALINA_HOME (which is generally the same as TOMCAT_HOME). I've patched the source of LogbackValve.java to do this and it works well. The change of "catalina.home" to "catalina.base" is to trivial for a formal patch... On a related note, I've also configured tomcat to use log4j/logback for internal logging, which also works quite well. I noticed in a previous post you "don't recommend this at this time" and would like to know the reason(s). Routing *all* logging through one logger/one config, which in turn can separate "live" logs from rotated out "archive" logs in a separate directory is a godsend. I'm assuming it is because doing this requires mucking around with the tomcat startup scripts to replace ACL from the very beginning of the tomcat boot process. I'd already created a "boot" directory with a dynamic set of jar's and classes (for unrelated reasons) so switching ACL to log4j/logback was pretty trivial for me. Is there more to the reluctance than the fact that there is no "drop in" way to do it? If there's interest, I can tidy up my tomcat patch and post the details. -- View this message in context: http://www.nabble.com/Using-logback-in-tomcat-tf2890321.html#a8074672 Sent from the Logback User mailing list archive at Nabble.com.

2 2

[ANN] Release of logback 0.9
by Sebastien Pennec 31 Jan '07

31 Jan '07

January 31st, 2007 - Release of version 0.9 This version contains a new component, namely the ContextSelector, that provides context separation and management when logback is used by several web-apps running under the same server. A new chapter[1] was added to the logback manual to detail the use of the ContextSelector, along with its associated components. The JMXConfigurator has been improved. It now shows the context's Status objects, which lets users check the internal state of logback. The logback manual's chapter 2, about logback's architecture[2], has been updated with two sections: Under the hood and Performance. Cheers, Sébastien Links: [1] http://logback.qos.ch/manual/contextSelector.html [2] http://logback.qos.ch/manual/architecture.html -- Sébastien Pennec sebastien(a)qos.ch Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch/

1 0

Using logback simply
by shef 24 Jan '07

24 Jan '07

Hello, I've read the docs, and I'm having a hard time understanding how to perform basic tasks. The manual, is, ah, less than straightforward... All I want to do is log to a disk file, and configure this in code. Using XML config files is not an option. I see no sample code in the docs that shows how to do this. The manual gets lost in complexity very, very quickly. All I want is something like this: someClass.setType(...) // console, disk file, whatever someClass.setDestination("/mydir"); someClass.setRolloverPolicy("some_policy_here"); Also -- where does it explain what is contained in logback-access.jar, logback-classic.jar, and logback-core.jar? Do I need all three, plus the slf4j-apis? Why not just one jar file? ____________________________________________________________________________________ 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news

3 4

[ANN] Release of logback 0.7.1
by Sebastien Pennec 23 Jan '07

23 Jan '07

December 19th, 2006 - Release of version 0.7 Version 0.7.1 of logback has been released. This version contains more detailled information about logback access module, and its JMX components. A dedicated page[1] explains how to configure and use logback access in Tomcat and Jetty, and access some of its components via JMX. Links: [1] http://logback.qos.ch/access.html -- Sébastien Pennec sebastien(a)qos.ch Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch/

1 1

configuration: Joran vs logback.xml
by Deirdre 18 Jan '07

18 Jan '07

Hi, I'm a new user of logging and have decided to start of with logback. I have a question regarding the configuration file: The manual states: "When logback is not configured by instanciating JoranConfigurator objects, it follows a simple policy to configure itself. Logback first tries to find a file called logback.xml within the classpath." Why then bother instanciating JoranConfigurator objects and asking that the configurator parse a certain configuration file 'sample.xml'. Why not just save the file as 'logback.xml' and it will be automatically read and parsed as the configuration file, without the use of JoranConfigurator objects, or?

2 1

Why am I only seeing one log generated?
by Samuel Doyle 17 Jan '07

17 Jan '07

Hi, In my following properties file only the first logfile (bitranlog) gets generated and output directed to that. Should the one for the soccslog be generated as well from the SOCCSService class? Thanks, S.D. ---- <?xml version="1.0" encoding="UTF-8"?> <configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <layout class="ch.qos.logback.classic.PatternLayout"> <param name="pattern" value="%-4relative [%thread] %-5level %class - %msg%n" /> </layout> </appender> <appender name="bitranlog" class="ch.qos.logback.core.rolling.RollingFileAppender"> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <param name="FileNamePattern" value="bitran_%d{yyyy-MM}.log.gz" /> <param name="ActiveFileName" value="/var/log/smartcorridors/bitran.log" /> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <param name="pattern" value="%-4relative [%thread] %-5level %class - %msg%n" /> </layout> </appender> <logger name="org.accma.concentrator.services.bitran.BiTranService"> <level value="debug"/> <appender-ref ref="bitranlog"/> </logger> <appender name="soccslog" class="ch.qos.logback.core.rolling.RollingFileAppender"> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <param name="FileNamePattern" value="soccs_%d{yyyy-MM}.log.gz" /> <param name="ActiveFileName" value="/var/log/smartcorridors/soccs.log" /> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <param name="pattern" value="%-4relative [%thread] %-5level %class - %msg%n" /> </layout> </appender> <logger name="org.accma.concentrator.services.soccs.SOCCSService"> <level value="debug"/> <appender-ref ref="soccslog"/> </logger> <root> <level value="debug" /> <appender-ref ref="STDOUT" /> </root> </configuration>

2 1

Re: Using Logback on JDK1.4 possible?
by Gerweck Andy - agerwe 16 Jan '07

16 Jan '07

Personally, I have had excellent luck using Retroweaver [http://retroweaver.sourceforge.net/] to back-convert my Java 5 code for deployment on earlier JVM runtimes. Retroweaver can handle *every* linguistic feature from Java 5. (Most of the linguistic changes in Java 5, even generics, have almost no incompatible effects on the compiled bytecode.) You feed it classes compiled with Java 5 and it spits out classes that will work on earlier JVMs. It requires only that you add a small JAR to your classpath. It also combines with the backport-util-concurrent project [http://dcl.mathcs.emory.edu/util/backport-util-concurrent/] to handle java.util.concurrent, Java 5's biggest library enhancement. Except where Java 5 adds new methods (e.g., String.format(...)) to old classes, Retroweaver can handle almost any Java 5 program. I put some back-compiled code through our QA department, which could find no performance or functionality problems. I *strongly* recommend you put in the slight extra effort to run Retroweaver's library-check utility. Point it to your JRE libraries and it will go through the code to ensure it doesn't try to use any methods or classes not available in your JRE (make sure to include the Retroweaver runtime JAR). This will catch those library changes I mentioned that Retroweaver doesn't handle--which is much better than a missing class or method at runtime. If you pass this test, you shouldn't have any problems. I have no affiliation with Retroweaver, though I did submit a patch to the backport-util-concurrent project. I make no claims that it'll work for you, but I'd bet you could run through the LOGBack JAR and get it running on JDK 1.4. If you do, you may want to share your work. Just feed in the LOGBack JARs you need and use the output instead of the original. Andy Gerweck Software Engineer PS: In good conscience, I can't help but recommend you upgrade to Java 5 or higher if at all possible. We're reaching the point where it's bad practice and poor style not to use Java 5's important language enhancements. There are also great runtime advantages, so it's not advisable to force a runtime upgrade where possible. *************************************************************************** The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank You. ****************************************************************************

2 2

Release of Logback 0.8
by Sebastien Pennec 12 Jan '07

12 Jan '07

January 12th, 2007 - Release of version 0.8 This version contains a whole new chapter, namely Chapter 3, about logback configuration. Several other documentation pages have been improved. Logback now uses Generics in many components. Several new components have been added to logback. A JMX Configurator now allows users to see and modify loggers or reload configuration among other possibilities. A document about this configurator is available in the corresponding section of the site. We'd like to thank Sebastian Davids for his ideas and contributions to this component. A JMSTopicAppender and JMSQueueAppender are now available, as well as two new filters: LevelFilter and ThresholdFilter. A refactoring was done in the filters objects to ease the implementation of custom filters. -- Sébastien Pennec sebastien(a)qos.ch Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch/

1 0

configuration - why no DTD?
by andrew wulf 08 Jan '07

08 Jan '07

Now that I have logback working, I can't figure out the whole syntax of the logback.xml file - why is there no DTD? All the examples show only a single appender and one root element. How would I, for example, add a console appender and a fileappender to the root? Or add a appender at another level? Documentation needs to be better, since confusion about configuration is likely to stop people from trying it. - andrew

2 1

How To Use Filters
by Yoram Forscher 04 Jan '07

04 Jan '07

After reading chapter 6, "Filter Chains," I tried to use some filters myself with no success. My configuration file contains the following: <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> <evaluator name="myEval"> <expression>marker.getName().equals("printConfiguration")</expression> </evaluator> <OnMismatch>NEUTRAL</OnMismatch> <OnMatch>DENY</OnMatch> </filter> <layout class="ch.qos.logback.classic.PatternLayout"> <param name="pattern" value="%d{ISO8601} %-5p [%c{40}] %m%n"/> </layout> </appender> In my code I have the following: private Marker pcMarker = MarkerFactory.getMarker("printConfiguration"); ... logger.debug(pcMarker, "Configuration Information"); ... I expect in that case that no output will be created, but it keeps printing it regardless of how I set it up. I also tried to change the expression to 'marker.contains("printConfiguration")' and change the OnMismatch and OnMatch both to DENY. Same result. What am I doing wrong?

4 15