[
https://issues.apache.org/jira/browse/QPID-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway resolved QPID-154.
------------------------------
Resolution: Fixed
------------------------------------------------------------------------
r542855 | aconway | 2007-05-30 12:13:58 -0400 (Wed, 30 May 2007) | 14 lines
Logging infrastructure: See qpidd --long-help for details.
* src/qpid/log/*: Logging infrastructure, QPID_LOG macro.
* src/*: changed output to cout/cerr to logging.
* src/qpidd.cpp: logging options.
* src/tests/Makefile.am: fixed issues with valgrind
* src/tests/kill|start_broker: use broker daemon options.
* src/tests/run_test: run tests in valgrind. Disabled till leaks in
client_test are fixed.
* src/test/unit/logging.cpp: Logging unit test using boost test framework.
Eventually we should move all unit tests to boost & drop CppUnit.
* src/test/unit/test_tools.h: useful extensions to boost framework:
Regular expression check, ostream << for vectors.
------------------------------------------------------------------------
> Logging/tracing for C++.
> ------------------------
>
> Key: QPID-154
> URL: https://issues.apache.org/jira/browse/QPID-154
> Project: Qpid
> Issue Type: New Feature
> Components: C++ Broker, C++ Client
> Affects Versions: M2
> Reporter: Alan Conway
> Assignee: Alan Conway
>
> Qpid needs logging infrastructure for user logging and debug tracing.
> Performance is critical, in particular the descision *not* to log a disabled
> messages must be extremely cheap so that disabled logging statements have no
> significant performance impact.
> Ideally a single system for both user logging and debug tracing so that debug
> tracing can be left in release builds and enabled to diagnose problems in
> the users's environment.
> Only if we can't get acceptable performance should we consider a separate
> debug tracing facility that is compiled out of release builds for tracing
> critical code.
> Highly desirable to use an existing open source solution rather than reinvent
> the wheel provided we can find one that is acceptable, need some research &
> discussion on dev list before selecting and implementing.
> Having the file/line in exception messages (as qpid does currently) is
> valuable, qpid::Exception should take a srcline parameter.
> Low-level tracing should provide function entry-exit logging via a
> macro+guard object that logs in constructor/destructor. (note
> BOOST_FUNCTION_NAME gives the current function name in a macro)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
