[logback-user] Just started playing with logback
ceki at qos.ch
Wed Aug 6 17:11:58 CEST 2008
Rob Ross wrote:
> 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.
Stop it, I am blushing.
> 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.
This warrants a bug report. I've created LBGENERAL-22. It would be helpful if
you could add the log4j.properties file that needs converting, assuming you
still have it.
> 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.
Duly noted in http://jira.qos.ch/browse/LBSITE-17
> 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?
This is a feature many people ask for as attested by isssue LBCORE-42. It'll be
added in the near future.
> 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
More information about the Logback-user