Some months ago we deprecated (and removed) all the qpid::client and
associated code from the header files exposed for application use.
One capability we removed was that of being able to control the internal
logging that qpid does. Since qpid is being embedded in some other
application ultimately it must have some way to control this logging to
aid in debugging the application (or qpid!).
I've just posted a review with a proposed qpid::messaging API that will
allow applications to control qpid's internal logging:
It allows control of which log levels are enabled; gives some control
over where the messages get logged (either stdout, stderr, a file, or
the applications own logging infrastructure); it also allows the
application to inject it's own log messages if that should prove useful.
Please take a look at the review over on reviewboard [1] and comment if
you find anything lacking, or seemingly more difficult than you'd
expect.
Thanks
Andrew
[1] https://reviews.apache.org/r/16316/
associated code from the header files exposed for application use.
One capability we removed was that of being able to control the internal
logging that qpid does. Since qpid is being embedded in some other
application ultimately it must have some way to control this logging to
aid in debugging the application (or qpid!).
I've just posted a review with a proposed qpid::messaging API that will
allow applications to control qpid's internal logging:
It allows control of which log levels are enabled; gives some control
over where the messages get logged (either stdout, stderr, a file, or
the applications own logging infrastructure); it also allows the
application to inject it's own log messages if that should prove useful.
Please take a look at the review over on reviewboard [1] and comment if
you find anything lacking, or seemingly more difficult than you'd
expect.
Thanks
Andrew
[1] https://reviews.apache.org/r/16316/