Project: datamanagement
Issue DM-195: log4cxx-based logging prototype - v2 
This is continuation of DMTF-16570-16. Initial work (v1) was done in branch u/bchick/protolog. V2 will include comments sent by K-T and issues discussed at the Qserv meeting March 13 + Free functions vs. a log object need to be discussed more. In particular, when metadata key/value pairs need to be attached, an object might make more sense. Avoiding the getLogger() call when no logging is needed (due to threshold) can be significant. + It's a security breach to use vsprintf() with any user-provided arguments. Use vsnprintf() instead so that you can check for overflow. (Or use stringstream or boost::format.) + In my prototype, I used a combination of a set of static log4cxx::LevelPtr variables with isEnabledFor(level) and a set of cpp macros to avoid the switch. + The return value from getLogger() shouldn't need to be cast. ---- + play with hierarchical names + don't execute code for formatting if debug level is off + use shorter threadId + experiment with defining special python handler, intercept and redirect to our log4cxx-based logging
Story points: 15