June 2011 - logback-user - mailman3.qos.ch

Bug in include tag
by Amit A Gadkari 15 Jun '11

15 Jun '11

We are having ear project with multiple web modules and ejb module. Logback is in shared library (websphere shared library which is loaded by different class loader) We have logback configuration files for each module. We have but all common appenders, logger in common included file which is in Java shared project which is used by all web modules and ejb modules in ear project. This included file we are including in logback configuration file for each module. Now logback is not able to find this included file. Reason: Logback.xml file of each module is loaded by classloader of web module While loading include file instead of using classloader of web module, it uses classloader of shared library. (Logback internally uses class loader of Loader.class) <include resource="common-configuration.xml" /> I think that this is bug as classloader which loaded logback.xml file of each module, should be used for loading included file also. Is there any workaround for this issue? -- View this message in context: http://old.nabble.com/Bug-in-include-tag-tp31840099p31840099.html Sent from the Logback User mailing list archive at Nabble.com.

2 2

Tomcat and webapp logging to same file with rollingFileAppender
by Roy McMorran 14 Jun '11

14 Jun '11

Greetings, We're currently using Logback for Tomcat logging via the method described at : https://github.com/grgrzybek/tomcat-slf4j-logback#readme There are two separate logback.xml files, one for Tomcat logging at $CATALINA_HOME/conf and another in the application WEB-INF/classes directory. Both use rollingFileAppender with TimeBasedRollingPolicy to roll over nightly. Both appenders write to the same file - $CATALINA_HOME/logs/tomcat.log . The contents of the logback.xml files can be viewed at http://pastebin.com/UHzy4AZe and http://pastebin.com/pEQAga4r This seems to work well until it is time for the log to roll over. After midnight the tomcat.log file is renamed to tomcat.yyyy-MM-dd.log as expected. Tomcat begins logging to a new tomcat.log file, as expected. However, the application is now logging to the tomcat.yyyy-MM-dd.log , which is not what we want. The lsof command tells me that the Tomcat process (jsvc) still has both files open. Can anyone suggest where we may have went wrong in the configuration? Thanks! PS: Tomcat 6.0.29, logback 0.9.26 -- Roy McMorran Systems Administrator MDI Biological Laboratory mcmorran(a)mdibl.org

1 0

What controls API version?
by Christopher Paulicka 13 Jun '11

13 Jun '11

Hello, Is there a way to control the logback version? If I create the following Gradle script: apply plugin: 'java' apply plugin: 'maven' repositories { mavenCentral() } dependencies { compile group: 'ch.qos.logback', name: 'logback-classic', version: '0.9.28' compile group: 'org.slf4j', name: 'slf4j-api', version: '1.5.8' } Then run 'gradle dependencies', my 'slf4j-api' version is now '1.6.1'. How does this happen? And how can I keep it at '1.5.8'? Strayph P.S. I found (by iterating) that '0.9.17' stays with '1.5.8', but that is a cheesy hack.

2 1

Java 7 automatic resource management and suppressed exceptions
by Christopher BROWN 13 Jun '11

13 Jun '11

Hello, I just read this article: http://www.oracle.com/technetwork/articles/java/trywithresources-401775.html I was aware of auto-close in Java 7, but have just seen (here) an example of "suppressed exceptions", which appear in stacktraces. Will this have an impact/be supported with logback? For reference, this example: MyException: Exception in work() at AutoClose.work(AutoClose.java:11) at AutoClose.runWithoutMasking(AutoClose.java:27) at AutoClose.main(AutoClose.java:58) Suppressed: java.lang.RuntimeException: Exception in close() at AutoClose.close(AutoClose.java:6) at AutoClose.runWithoutMasking(AutoClose.java:34) ... 1 more Thanks, Christopher

2 4

How to direct calls to another API into Logback classic
by Christopher BROWN 10 Jun '11

10 Jun '11

Hello, I'm using Logback classic via the SLF4J API, in a big application where other log APIs (some standard, such as OSGI logging, and other proprietary in-house historical APIs) are present. I would like to re-implement these APIs to "redirect" onto Logback classic, but to get to the point: it's a big API and I'm lost. If I reimplement said APIs with a naive implementation that just calls into SLF4J or logback using the "user" API, I'll incur an extra stack frame in stack traces and generally hide the origin of calls. What's the best, cleanest way of doing this (given SLF4J and the choice of logback classic) ? I will add the Log4J API implementation to address some cases (the SLF4J implementation of Log4J APIs) but for the other stuff, I'm a bit stuck. Thanks, Christopher

2 2

Release of logback v0.9.29
by Ceki Gülcü 10 Jun '11

10 Jun '11

Hello all, I am happy to announce the release of logback version 0.9.29. Please refer to the news page for precise details. http://logback.qos.ch/news.html You can download logback, including full source code, class files and documentation on our download page, shown below. http://logback.qos.ch/download.html You can receive logback related announcements by subscribing to the QOS.ch announce mailing list. To subscribe to QOS.ch announce list, please visit the following URL. http://www.qos.ch/mailman/listinfo/announce Enjoy, -- Ceki

2 1

question reg. reading JNDI env entries
by Ravikanth Gangarapu 08 Jun '11

08 Jun '11

Hi, I am using logback-classic (0.9.28) for a web application running on tomcat 5.5. I am trying to read the JNDI env entry values using the <insertFromJNDI env-entry-name="java:comp/env/stderr-logging" as="stdErrLogging" /> tag in the logback.xml file. I have lots of env entry values that can be read from META-INF/context.xml file. For this specific example, my context.xml file has this. <context> .... <Environment name="stderr-logging" type="java.lang.String" value="true"/> .... But, this insertFromJNDI tags always says the entry value is null or empty. However, Once I am in a servlet code, new InitialContext().lookup("java:comp/env/stderr-logging") retrieves the correct value from context xml file. I looked in the JNDIUtil class from ch.qos.logback.classic.util package and the code throws error saying "javax.naming.NameNotFoundException: Name java:comp is not bound in this Context". Would somebody know how to read the environment entry values from the META-INF/context.xml file ? Thanks for help Ravi

2 4

using logback in an API w/o impacting other applications
by Richard Sand 07 Jun '11

07 Jun '11

Hi all, In an API I had to write for a client to interface with an COTS application, I used log4j to bridge to the COTS application's log capability. To totally isolate the usage of log4j in the API I created a wrapper around a Logger with its own Hierarchy. I'm wondering if there is an analogous mechanism for accomplishing this in logback. public final class AgentLogger { public static Hierarchy heirarchy = new Hierarchy(new RootLogger(Level.TRACE)); private Logger wl = null; /** * Private constructor * * @param name */ private AgentLogger (String name) { wl = heirarchy.getLogger(name); wl.setAdditivity(false); } Any advice appreciated. Thanks! Best regards, Richard Sand | CEO 239 Kings Highway East | Haddonfield | New Jersey 08033 | USA Mobile: +1 267 984 3651| Office: +1 856 795 1722| Fax: +1 856 795 1733 <http://www.skyworthttg.com/>

2 3

DBAppender issue
by Stephen Schaeffer 07 Jun '11

07 Jun '11

Hi all, I'm attempting to use the DBAppender, with the MySQL dialect. I am unable to actually put any records into my DB however. It seems that the culprit is that in DBAppenderBase:append, there is a call to subAppend, which is implemented either in Access, in which case it takes an AccessEvent as it's first argument, or in Classic, in which case it takes an ILoggingEvent as it's first argument. What it is actually passing is a LoggingEvent (no initial I) object, and so I'm getting ClassCastExceptions, and nothing in my DB. I'm assuming that someone out there has this working, and I'm just wondering what I'm doing wrong. Thanks for any help. Stephen Schaeffer ________________________________ This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

2 5

Logback logging to MySQL
by Stephen Schaeffer 03 Jun '11

03 Jun '11

Hi all, I am in the process of exploring logback so we can migrate our logging off of our current mishmash. As part of that I have been trying to configure to write to a MySQL database. In the configuration file I have this: <appender name="DB" class="ch.qos.logback.access.db.DBAppender"> <connectionSource class="ch.qos.logback.core.db.DriverManagerConnectionSource"> <driverClass>com.mysql.jdbc.Driver</driverClass> <url>jdbc:mysql://localhost:3306/test</url> <user>logback</user> <password>logback</password> </connectionSource> <insertHeaders>true</insertHeaders> </appender> <root level="DEBUG"> <appender-ref ref="STDOUT" /> <appender-ref ref="FILE" /> <appender-ref ref="DB" /> </root> And I've run the scripts to set up the tables in MySQL, and logback can apparently connect ok - if I change any of the parameters in the config I get errors about it not connecting. On the console and in the logfile I can see output as I would expect, but the DB remains empty. I'm using MySQL 5.1.51 on a Mac, for what that's worth. Stephen Schaeffer ________________________________ This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

2 2