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.
|
