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ü _______________________________________________ Logback-user mailing list [email protected] http://qos.ch/mailman/listinfo/logback-user
