|
Boost : |
Subject: Re: [boost] Custom logging backend difficulty
From: Kenneth Adam Miller (kennethadammiller_at_[hidden])
Date: 2014-10-27 15:48:28
Reading some more at the top of this:
http://boost-log.sourceforge.net/libs/log/doc/html/log/tutorial/formatters.html
I found that:
Even if you added attributes to the logging core or a logger, the attribute
values will not reach the output unless you specify a formatter that will
use these values.
is what is holding me up. How can I specify a formatter that just gives the
attribute name and then it's value, each separable by some delimiter? I
want to make certain that all attributes are consumed. Really, the reason
why I want this is, I don't know what the actual types are in the attr<
some_type > format, as demonstrated in several examples. This is kind of a
work around, but really I just want all the data that I enable at the
consumer level to make it by some default formatting method.
On Mon, Oct 27, 2014 at 3:03 PM, Kenneth Adam Miller <
kennethadammiller_at_[hidden]> wrote:
> Ah ok that clarifies somewhat; I thought it was the formatter that I was
> having trouble with. I tried setting one, and then saw that the text was
> added to the console to test. But I'm doing
> boost::log::add_common_attributes(), and I print the string to std out just
> to make sure that I will get what I expect. As it turns out, I think that
> the backend is supposed to visit the record_view, and the record view has
> the default attributes and any others added.
>
> I'm trying to get those extra attributes; if I do BOOST_LOG(lg) << " blah"
> << endl; I get "blah" on my screen which I swap out the backend from the
> default. My backend just prints to the console.
>
> How do I had the record_view items to the string to be sent?
>
> On Mon, Oct 27, 2014 at 2:56 PM, Andrey Semashev <
> andrey.semashev_at_[hidden]> wrote:
>
>> On Monday 27 October 2014 14:40:22 Kenneth Adam Miller wrote:
>> > So, I need malleable logging facilities, and so far I've identified
>> boost's
>> > logging facilities as useful. I've read the docs on logging, and right
>> now
>> > I'm having difficulty achieving what I want-basically, I have a custom
>> > backend, in order that when logging is done, it gets routed to an
>> > alternative destination - over the network namely.
>> >
>> > I extended from text_ostream_backend, and basically I'm having the
>> > following trouble:
>> >
>> > I don't understand the record_view visitation API. I'd like the ability
>> to
>> > set formatters and what not to remain untouched, but have the final
>> > formatted result sent off else where. I can change this by sending the
>> > string received in the consume function that has to be overrode, but the
>> > values are lost in the record_view.
>> >
>> > void consume (const record_view & rec, std::string s);
>> >
>> > where I do { send(s); } for the body.
>> >
>> >
>> > What I think is necessary is just to retain the default behavior of
>> > accepting whatever formatter was specified...
>> >
>> > What is the best way to go about achieving what I want?
>>
>> I'm sorry, I don't understand what you mean.
>>
>> The first argument of consume() is the record view, which contains all
>> attribute values that were passed to the library when the log record was
>> created. This includes the message text. Whether or not you apply a
>> formatter
>> to it, the view remains intact and can be used in your sink backend if
>> needed.
>> Accessing attribute values is summarized here:
>>
>>
>> http://www.boost.org/doc/libs/1_56_0/libs/log/doc/html/log/detailed.html#log.detailed.core.record
>>
>> The second argument is the result of formatting, i.e. the format of the
>> string
>> is defined by the formatter. If you send log records as strings over the
>> network then this string is probably what you need, provided that you set
>> the
>> appropriate formatter.
>>
>>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
>
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk