From: Jeremy C. R. <re...@re...> - 2012-06-01 13:21:40
|
The BIND 10 team discussed this some. We posted some feedback at https://lists.isc.org/pipermail/bind10-dev/2012-May/003470.html and https://lists.isc.org/pipermail/bind10-dev/2012-May/003473.html I will repost that same feedback here: From: Shane Kerr > 1. What version of log4cplus are you using in what product/library of > your own? We work with 1.0.4 certainly. It was already out when we started using log4cplus, so I don't know about support for earlier versions. > 2. What lead you to choose log4cplus over other competing (log4cpp, > log4cxx, Pantheios, etc.) libraries? We always have license concerns (has to be BSD-compatible, so GPL code is out) limiting our options. We had problems with incompatible APIs in versions of log4cxx (IIRC), so we switched to log4cplus. > 3. What do you miss in log4cplus? Our main problems have to do with concurrent logging from multiple processes. If log4cplus used only a single write() statement, and O_APPEND, when writing to files then we would not have problems with files. We would still have issues when writing to the console or other slow devices (serial ports, etc.) since there is no guarantee that you will get your entire buffer output. To work around this in a general way we use advisory locks via fcntl() to prevent concurrent logging. This seems to be the best solution, and it would be nice to have this capability in log4cplus itself. > 4. More comments? We've found people who helped us get log4cplus into Debian and Ubuntu, as well as some BSD variants. We'll be trying Fedora (and hopefully RHEL) next. I'm happy if the log4cplus team wants to take up this effort. :) And thanks! From: JINMEI Tatuya / ???? > > 3. What do you miss in log4cplus? IIRC, log4cplus dumps its own warning messages to stdout or stderr, and they leak in an awkward way. It would be nice if the application can control whether/how these messages are dumped. |