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

JMXConfigurator OName
by Pritchard, Ellis - Ealing 15 Aug '08

15 Aug '08

Hi, I've currently got multiple logback-enabled servlets running under the same JVM, each in separate web contexts, and each with their own logback.xml and slf4j/logback jars in WEB-INF. Whist this works (in terms of logging), the jmxConfigurator MBean seems to only refer to one of the contexts, and has the name 'default'. I can't see the loggers listed for the other contexts. What I'd expected to see is a different MBean listed for each webapp context. Looking at the jmxConfigurator code, it seems to use the name of the logging context for the JMX name; how does this get set? Can it be set in the logback.xml? Ellis. ------------------------------------------------------------------------------------------------------------ This email (and any attachment) is confidential, may be legally privileged and is intended solely for the use of the individual or entity to whom it is addressed. If you are not the intended recipient please do not disclose, copy or take any action in reliance on it. If you have received this message in error please tell us by reply and delete all copies on your system. Although this email has been scanned for viruses you should rely on your own virus check as the sender accepts no liability for any damage arising out of any bug or virus infection. Please note that email traffic data may be monitored and that emails may be viewed for security reasons. John Wiley & Sons Limited is a private limited company registered in England with registered number 641132. Registered office address: The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ. ------------------------------------------------------------------------------------------------------------

4 7

Just started playing with logback
by Rob Ross 06 Aug '08

06 Aug '08

Hello. I finally got around to downloading logback and playing with it. So far, it's been very easy to substitute it for log4j. Let me say first that I think log4j is one of the best Java frameworks ever written, up there with JUnit. It does a specific job very well, with a very lightweight API and it is very easy to get started using it. It also has enough depth to be able to customize things when you need to customize them. So let me say you've done a very good job with log4j, and I'm sure logback will be even better. I have a few comments for you. First, the log4j properties translator ( http://logback.qos.ch/translator/Welcome.do ) does not quite work. Maybe it's based on an old version and is now out of date, but you should think about updating it. The file it produced did not translate my properties that I used in log4j.properties to specify the log file path into the equivalent substitutionProperty elements, and it did not translate the Levels I had set on the log4j appenders. It did wrap them in Threshold elements, but the current XML schema wants these specified in a "filter" element on the appender. Also, it did not translate the settings for the rolling file appender into the FileNamePattern element. However, the Joran configurator gave me detailed enough Exception messages that it was easy to determine what the problems were and fix them. Also, on Chapter 3 of the current Logback documentation manual, when it discusses variable substitution it mentions "Recursive Substitution." Well, if you re-read that section carefully I think you'll agree that this example is in fact NOT doing any kind of *recursion*, it is just using multiple variables. They are not even being nested. So I would suggest calling it something other than "recursion." The people that will read this manual are programmers, and we all know (or should know ) what recursion is, and I think this will just confuse people. I also have a question about functionality. The only difference between log4j and logback that I have noticed so far is a different behavior between the way each will create the log file (for a FileAppender) if it does not yet exist. In log4j when I specified a full path, it would also create the directory for the log file if it did not already exist. Logback does not create the directory, it throws an exception. So I will have to add this to my Java code, but it smells a little fishy to have to configure where the logs are created in two different contexts, one in my application (by creating the directory), one in the logback configuration file. Maybe you can give me a good reason for why this new way is better, or maybe it's just an oversight and it has not been implemented yet? I was wondering what your thoughts were about this? Thank you for your great work on creating some great logging frameworks that really provide useful functionality for Java programs! Rob Ross, Lead Software Engineer E! Networks --------------------------------------------------- "Beware of he who would deny you access to information, for in his heart he dreams himself your master." -- Commissioner Pravin Lal

3 3

FallBack Appender and error handler
by Jonathan Dray 24 Jul '08

24 Jul '08

Hi, I previously used log4j with a JMSAppender sending messages to a specific ActiveMq Queue. I managed to configure a FallBackErrorHandlor with a second JMSAppender in case the first JMSAppender was not able to write to the queue. The ErrorHandler was also configured to send emails when something went wrong. I now want to try logback and wonder if there is a way to get errors returned by loggers at runtime. Plesae consider the following situation : ** * Hello world! * */ public class App { public static void main( String[] args ) { ... ... (some code herer) Logger log = LoggerFactory.getLogger("myLogger"); log.debug("App : main"); System.out.println( "Normal end of my process" ); } } Let's assume the "myLogger" is configured to use a JMSAppender. I want to know if the log.debug call failed and then not to display "Normal end of my process." 1. Is this possible ? 2. How should I handle errors dealing with logback logger ? Thank you Regards, Jonathan Dray

2 2

Manfred Kuhlmann is out of office.
by Manfred.Kuhlmann＠steria-mummert.de 21 Jul '08

21 Jul '08

Ich werde ab dem 21.07.2008 nicht im Büro sein. Ich kehre zurück am 11.08.2008. I will be out of the office starting 21.07.2008. I will be back on 11.08.2008. Ihre Nachricht werde ich nach meiner Rückkehr beantworten. I will answer your message after my return. Mit freundlichen Grüßen Best regards Manfred Kuhlmann

1 0

Re: [logback-user] Configuring jndi db access in tomcat5.5: some thoughts
by Ceki Gulcu 17 Jul '08

17 Jul '08

Diego Louzán wrote: > The last couple of days I've been learning about SLF4J and Logback. IMHO > this is a great piece of software. Thanks. > One of my needs was to configure logging to a JNDI shared database > inside tomcat 5.5. I followed the directions outlined in > http://logback.qos.ch/manual/appenders.html for configuring the > DBAppender with a JNDIConnectionSource. > > The example code in the manual is like this: > > <connectionSource class="ch.qos.logback.core.db.JNDIConnectionSource"> > <param name="jndiLocation" value="jdbc/MySQLDS" /> > <param name="username" value="myUser" /> > <param name="password" value="myPassword" /> > </connectionSource> > > (BTW, the "username" param in the documentation is wrong, it must be > "user"). If it's not too much to ask, could you please enter a bug report regarding this problem? Actually, you might want to reference this whole thread as from what I could understand, there are multiple issues involved. [snip] > As you can see, tomcat references a JCL logger in > "org.apache.catalina.core.ContainerBase.getLogger" just when first > loading the webapp. This triggers logback initialization, and when the > JNDIConnectionSource tries to get a reference to the DataSource, it > finds nothing. Interesting problem. One way to solve it would be to perform logback configuration in two stages. In the first stage, you would configure logback as usual, using logback.xml. In the second, you would use another config file, say logback-db.xml and invoke Joran after tomcat has been initialized. Here is sample code: LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); URL url = Loader.getResource("logback-db.xml", classLoader); JoranConfigurator configurator = new JoranConfigurator(); LoggerContext loggerContext = () configurator.setContext(lc); configurator.doConfigure(url); > I found a reference to a similar problem with JNDI contexts in the old > bugzilla tracker (http://marc.info/?l=logback-dev&m=119005116732589&w=2) > but although I tried locating this bug report in the new JIRA tracker I > could not find it. Maybe it got lost during the migration? It's here: http://jira.qos.ch/browse/LBCLASSIC-30 I found it by going to jira.qos.ch, FIND ISSUES and entering 96 as the bugzilla id to search for (at the bottom of the page). Entering "ContextSelectors" as the query text also yields valid results. So, it looks like the migration was OK. > At the moment I'm still trying to fully understand the codebase. Do you > figure out any solution to the problem? See above. > I'm sorry for such a lengthy message. Hope this info helps the project. > Regards and keep up the good work. Thanks, > Diego. -- Ceki Gülcü QOS.ch is looking to hire talented developers located in Switzerland to work on cutting-edge software projects. If you think you are qualified, then please contact ceki(a)qos.ch.

1 0

Re: [logback-user] jndi db access in tomcat5.5
by Anton Tagunov 17 Jul '08

17 Jul '08

Hello Diego, [1] > using tomcat5.5, username/password can't be specified when > trying to use a JNDI-shared DataSource > when using pooled data sources the user and > password version of getConnection method can't be used. > I don't know if this is tomcat-specific behaviour. this is indeed an iteresting question; do we have anybody here with a better knowledge of J2EE? > ... in ... ch.qos.logback.core.db.JNDIConnectionSource: > Maybe some sort of "if jndi then don't use user/pass" testing could be done > for better error reporting I guess if the answer to prev. question is positive this could be a worthy idea [2] > Added to that, the JNDI name used in the "jndiLocation" must be > prepended by "java:comp/env", as this is the standard context for java > objects and the JNDIConnectionSource does not prepend the searched values with it. Looks like a nice idea to me. Will not be backwards compatible but logback is not version 1 yet. I suggest that you create a Jira item for this /and maybe attach a patch/ [3] > Another thing I got problems with was slf4j's jcl-over-slf4j-1.5.2.jar. > logback ... initialized too early when using jcl-over-slf4j, before tomcat > makes the JNDI resources available to the web application > ch.qos.logback.core.db.JNDIConnectionSource@67c1a6 - Error while getting > data source javax.naming.NameNotFoundException: > javax.naming.NameNotFoundException: 'comp' can't be found in this context > at org.apache.naming.NamingContext.lookup(NamingContext.java:770) ... > org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155) > org.apache.commons.logging.LogFactory.getLog(LogFactory.java:704) > org.apache.catalina.core.ContainerBase.getLogger(ContainerBase.java:381) ... > org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149) Looks pretty weird to me. Diego what folder is jcl-over-slf4j-1.5.2.jar in? Do you have another copy in shared tomcat libraries? Or together with tomcat own jars? Cheers, Anton Tagunov logback user

4 4

Re: [logback-user] Special Joran substitution
by Diego Louzán 15 Jul '08

15 Jul '08

Ceki Gulcu escribió: > Hello Diego, > > The special syntax originates from Bash, at least that's where I saw it fist. > > http://www.faqs.org/docs/abs/HTML/parameter-substitution.html > http://tldp.org/LDP/abs/html/refcards.html#AEN20779 > http://www.purinchu.net/wp/2005/06/11/advanced-parameter-substitution-with-… > > Thus, "${varnname:-word}" means, if varname exists and isn't null, return its > value, otherwise return 'word'. > > If my memory serves me correctly, the special substitution syntax is needed > because, we would like to have the name of the parameter to vary with the > circumstances. More precisely, while most database drivers take expect the name > of the "url" parameter to be "url", some database drivers expect that the value > be passed using a different variable name. > > Does this help? > > Diego Louzán wrote: >> In chapter4 of the documentation the following example is shown: >> >> <dataSource class="${dataSourceClass}"> >>  >> <param name="${url-key:-url}" value="${url_value}"/> >> <serverName>${serverName}</serverName> >> <databaseName>${databaseName}</databaseName> >> </dataSource> >> >> I can't figure out that special syntax for Joran in "${url-key:-url}", >> can anybody explain it to me? Why is it needed in that example? >> >> Regards. >> Diego. I'm not much of a bash fan, so no wonder I had never heard about that syntax xD Thanks for clearing that up. Regards. Diego.

1 0

Problem with FileNamePattern that includes ${user.home} on windows
by Michel Collette 14 Jul '08

14 Jul '08

Hello, I'm been unsuccessful at using the RollingFileAppender with a FixedWindowRollingPolicy that has this FileNamePattern: <FileNamePattern>${user.home}/Client%i.log</FileNamePattern> "${user.home}/Client%i.log" gets correctly expanded to "C:\\Documents and Settings\\Michel/Client%i.log" when it's passed to the FixedWindowRollingPolicy constructor. The problem starts once the filename gets parsed by ch.qos.logback.core.pattern.parser.Parser: the filename becomes "C:ocuments and Settingsichel/Client". File rotations then fails (as would be expected) when trying to rename the current log to "C:ocuments and Settingsichel/Client1.log" Is there a way to configure logback to correctly deal with the "\\" used in windows? Thanks.

2 1

Re: [logback-user] Test logging in unittest
by Ceki Gulcu 14 Jul '08

14 Jul '08

Claus, Thank you for posting your recipe for unit testing. If you wanted, you could inspect the contents of the log events to see if it meets your expectations. For example you could write. assertEquals("Exactly 1 failure should have been logged.", 1, listAppender.list.size()); // inspect message contents: LoggingEvent le = listAppender.list.get(0); assertTrue(le.getFormattedMessage().startsWith("whatever you expect it to start with")); HTH, clanie wrote: > Yes, that's certainly clearer, thank you. > > Just to in case others with the same problem stumbles upon this thread, > here's the new improved version the test: > > /** > * Tests that closeChannels() tries to close all the supplied Channels, > * even if supplied with nulls and Channels which fail to close. > */ > @Test > public void testCloseChannels() { > // Capture log entries from FileUtil > Logger logger = (Logger) LoggerFactory.getLogger(FileUtil.class); > logger.setAdditive(false); > ListAppender<LoggingEvent> listAppender = > new ListAppender<LoggingEvent>(); > listAppender.start(); > logger.addAppender(listAppender); > // Close a mix of normal, broken and completely missing channels > closeChannelse(null, new UnclosableChannelStub(), > null, new ChannelStub(), new ChannelStub()); > // Restore normal logging > logger.detachAppender(listAppender); > logger.setAdditive(true); > // Perform checks > assertEquals("Exactly 1 failure should have been logged.", 1, > listAppender.list.size()); > } > > > > > Ceki Gulcu-2 wrote: >> >> Hello Claus, >> >> A slightly easier way would be to use a ListAppender, which appends each >> event >> into a ...list. Logback-core has an implementation of about 10 lines each >> which >> is extensively for testing purposes in the other modules. >> >> Here it is: >> >> package ch.qos.logback.core.read; >> >> import java.util.ArrayList; >> import java.util.List; >> >> import ch.qos.logback.core.AppenderBase; >> >> public class ListAppender<E> extends AppenderBase<E> { >> >> public List<E> list = new ArrayList<E>(); >> >> protected void append(E e) { >> list.add(e); >> } >> } >> >> Check the tests where ListAppender is used. I think BasicLoggerTest should >> give >> you a good idea of usage. >> >> >> >> HTH, >> >> Claus Nielsen wrote: >>> I have a unit test which checks that a class writes the log statements >>> it's supposed to. >>> >>> The following code works, but I was wondering if there isn't a better or >>> easier way to do this. >>> >>> Here's what I have now: >>> >>> public void testCloseChannels() { >>> Logger rootLogger = (Logger) >>> LoggerFactory.getLogger( >>> LoggerContext.ROOT_NAME); >>> Appender<LoggingEvent> appender = >>> rootLogger.getAppender("console"); >>> appender.addFilter(new Filter() { >>> @Override >>> public FilterReply decide(Object o) { >>> LoggingEvent event = (LoggingEvent) o; >>> if (event.getMessage().equals("Failed to close channel.")) { >>> expectedLogEntryCount.incrementAndGet(); >>> return FilterReply.DENY; >>> } >>> return FilterReply.NEUTRAL; >>> } >>> }); >>> close(null, new UnclosableChannelStub(), null, >>> new ChannelStub(), new ChannelStub()); >>> assertEquals("Exactly 1 failure should have been logged.", >>> 1, expectedLogEntryCount.intValue()); >>> appender.clearAllFilters(); >>> } >>> >>> >>> Regards, >>> Claus Nielsen >> -- >> -- >> Ceki Gülcü >> QOS.ch is looking to hire talented developers located in Switzerland. >> If interested, please contact c e k i AT q o s . c h >> _______________________________________________ >> Logback-user mailing list >> Logback-user(a)qos.ch >> http://qos.ch/mailman/listinfo/logback-user >> >> > -- -- Ceki Gülcü QOS.ch is looking to hire talented developers located in Switzerland. If interested, please contact c e k i AT q o s . c h

1 0