Revision number 308702 changed the way the LOG4CXX_INFO...etc macros
behave. This has broken a substantial portion of code for me, and I think
the change was a "downgrade" of sorts.
For instance:
#define LOG4CXX_WARN(logger, message) { \
- if (logger->isWarnEnabled()) {\
- ::log4cxx::StringBuffer oss; \
- oss << message; \
- logger->forcedLog(::log4cxx::Level::WARN, oss.str(), __FILE__,
__LINE__); }}
+ if (logger->isWarnEnabled()) {\
+ logger->forcedLog(::log4cxx::Level::WARN, message,
LOG4CXX_LOCATION); }}
The net effect is that previously, you were able to do:
LOG4CXX_WARN(myLogger, "Dropped" << numPacketsDropped << " of " <<
totalNumPackets << " packets.");
whereas this no longer works. It is true that you could create a string
buffer yourself outside of the logging call. However, then you pay the
creation cost of the string buffer regardless of whether logging for that
level is enabled or not. OK - one could wrap the whole thing in an
if(logger->isWarnEnabled()) call as before. To that effect, I could just
create new macros that do just what the old ones did.
What I'm getting at is that I think the old macros were much more useful,
and it would be better to revert to them (keeping the change to use
LOG4CXX_LOCATION of course). Changing back to the macro version that
created its own string buffer would not break any existing code. On the
other hand, if/when a .98 release does come it, this change WILL break any
other .97 users who were using the macros as my codebase does.
I realize this revision is around 2.5 years old. We are only noticing the
effects of it here because we have been using version .97 up until now. We
only recently upgraded to the head revision of log4cxx during the process
of moving our code to Visual Studio 2005(8).
Sean Hermany
Software Engineer
FactSet Research Systems Inc.
[EMAIL PROTECTED] | 650.286.4942
http://www.factset.com
