Hi Rob, Thanks for sharing. However, as with all open source projects, the biggest chance of getting issues fixed is to file a bug report. There might even be a bug report for the problem you've run into (as there is for the FileAppender thing you describe, see enhancement LBCORE-42). You find the link to logback Jira on the home page. /Anders, logback user

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 _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user

Hello Rob, Commetns inline. Rob Ross wrote:

Hello.

I finally got around to downloading logback and playing with it. So far, it's been very easy to substitute it for log4j.

Cool.

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. See http://jira.qos.ch/browse/LBGENERAL-22

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!

Thank you.

Rob Ross, Lead Software Engineer E! Networks

-- Ceki Gülcü