----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/16316/#review30539 -----------------------------------------------------------
/trunk/qpid/cpp/include/qpid/messaging/Logger.h <https://reviews.apache.org/r/16316/#comment58502> Oops, Good point. /trunk/qpid/cpp/include/qpid/messaging/Logger.h <https://reviews.apache.org/r/16316/#comment58503> Hmm, this is an interesting question. I don't think this is any worse than registering a callback function and probably slightly more flexible under future change. You can't change the vtable order or the signature of the callback function in order to allow old code to receive callbacks from a newer library. But you could add a whole new registration call which causes a new virtual function to be called. As long as the new callback is defined after the previous one in the class, which will cause it to be later in the vtable (at least for gcc although this is not guaranteed). - Andrew Stitcher On Dec. 17, 2013, 8:04 a.m., Andrew Stitcher wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/16316/ > ----------------------------------------------------------- > > (Updated Dec. 17, 2013, 8:04 a.m.) > > > Review request for qpid, Chug Rolke and Gordon Sim. > > > Bugs: QPID-5415 > https://issues.apache.org/jira/browse/QPID-5415 > > > Repository: qpid > > > Description > ------- > > Currently there is one major omission from the qpid::messaging API: That is > control of the internal logging used by qpid itself. > > This was previously present in the qpid::client API albeit not really > supported or documented. Now that we have completely removed the qpid::client > and associated APIs from being exported for use beyond qpid itself there is > no way to control the logging internal to the qpid messaging libraries. > > This review introduces some simple APIs which give back control of the qpid's > internal logging. I think there is now as much control as virtually all qpid > user applications are likely to need. > > Please give the proposed API some consideration and let me know if there is > anything that an application needs that I haven't considered here. > > > Diffs > ----- > > /trunk/qpid/cpp/include/qpid/messaging/Logger.h PRE-CREATION > /trunk/qpid/cpp/src/CMakeLists.txt 1551330 > /trunk/qpid/cpp/src/qpid/log/Logger.cpp 1551330 > /trunk/qpid/cpp/src/qpid/log/Options.h 1551330 > /trunk/qpid/cpp/src/qpid/log/Options.cpp 1551330 > /trunk/qpid/cpp/src/qpid/log/Selector.cpp 1551330 > /trunk/qpid/cpp/src/qpid/log/Statement.cpp 1551330 > /trunk/qpid/cpp/src/qpid/messaging/Logger.cpp PRE-CREATION > /trunk/qpid/cpp/src/tests/CMakeLists.txt 1551330 > /trunk/qpid/cpp/src/tests/MessagingLogger.cpp PRE-CREATION > > Diff: https://reviews.apache.org/r/16316/diff/ > > > Testing > ------- > > Added in unit tests which pass* > > *They currently also assume a bug fix which is included in the code in this > review which prevents critical log messages ever being turned off (I think > this the correct behaviour - in the current code under some circumstances > they can actually be turned off) > > > Thanks, > > Andrew Stitcher > >
