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 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...

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

On Monday 27 October 2014 15:48:28 Kenneth Adam Miller wrote:

On Mon, Oct 27, 2014 at 3:03 PM, Kenneth Adam Miller <

kennethadammiller@gmail.com> 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.

The formatter just composes a string from the attribute values attached to the record, it's the sink backend that is supposed to do something with that string, like output to the console or send over the network. Text-based backends typically don't need to access the record view (although they're still able to) because the formatter already did all the job.

...

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?

With formatter, you just have to use it in the formatting expression. A few examples are here: http://www.boost.org/doc/libs/1_56_0/libs/log/doc/html/log/tutorial/formatte... Basically, you need the attribute value name and type to do that.

Reading some more at the top of this: http://boost-log.sourceforge.net/libs/log/doc/html/log/tutorial/formatters.h tml

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.

There is no built-in formatter in the library that just iterates through the values in the record, you have to write your own. It's simple, just write a function like described here: http://www.boost.org/doc/libs/1_56_0/libs/log/doc/html/log/tutorial/formatte... The record view has attribute_values() member, which returns an associative container of all attached values in pairs (name; value). Each value is an object of attribute_value class, from which you can extract the actual contained value through one of the approaches listed in the link I posted earlier. In particular, you can use visitation and something similar to a print_visitor class in the example here: http://www.boost.org/doc/libs/1_56_0/libs/log/doc/html/log/detailed/attribut... Of course, the formatter should insert its output into the provided stream, not std::cout.

On Mon, Oct 27, 2014 at 4:30 PM, Andrey Semashev wrote:

...

On Monday 27 October 2014 15:48:28 Kenneth Adam Miller wrote:

...

On Mon, Oct 27, 2014 at 3:03 PM, Kenneth Adam Miller <

kennethadammiller@gmail.com> 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.

The formatter just composes a string from the attribute values attached to the record, it's the sink backend that is supposed to do something with that string, like output to the console or send over the network. Text-based backends typically don't need to access the record view (although they're still able to) because the formatter already did all

...

job.

...

...

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

On Monday 27 October 2014 23:30:09 you wrote: the the

...

...

...

default. My backend just prints to the console.

How do I had the record_view items to the string to be sent?

With formatter, you just have to use it in the formatting expression. A few examples are here:

...

rs.html

Basically, you need the attribute value name and type to do that.

...

Reading some more at the top of this:

http://boost-log.sourceforge.net/libs/log/doc/html/log/tutorial/formatters

...

.h tml

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.

There is no built-in formatter in the library that just iterates through

http://www.boost.org/doc/libs/1_56_0/libs/log/doc/html/log/tutorial/formatte the

...

values in the record, you have to write your own. It's simple, just write a function like described here:

http://www.boost.org/doc/libs/1_56_0/libs/log/doc/html/log/tutorial/formatte

...

rs.html#log.tutorial.formatters.custom_formatting_functions

The record view has attribute_values() member, which returns an associative container of all attached values in pairs (name; value). Each value is an object of attribute_value class, from which you can extract the actual contained value through one of the approaches listed in the link I posted earlier. In particular, you can use visitation and something similar to a print_visitor class in the example here:

http://www.boost.org/doc/libs/1_56_0/libs/log/doc/html/log/detailed/attribut

...

es.html#log.detailed.attributes.related_components.value_processing.visitati

...

on

Of course, the formatter should insert its output into the provided stream, not std::cout.

PS: Please, don't top post.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Ah ok, I got it now, it's mostly working. But I'm getting an error when I set up my formatter... I followed the example exactly for the format_date_time to get a timestamp, and I'm getting a compile error. sink->set_formatter( stream << format_date_time ("TimeStamp", "%Y-%m-%d %H:%M:%S") << message); blows up pretty bad. Also, adding a line for severity << "[" << boost::log::trivial::severity << "] " just yields [] in the output lines.

On 10/27/14, Kenneth Adam Miller wrote:

On Mon, Oct 27, 2014 at 5:02 PM, Kenneth Adam Miller < kennethadammiller@gmail.com> wrote:

...

On Mon, Oct 27, 2014 at 4:30 PM, Andrey Semashev < andrey.semashev@gmail.com> wrote:

...

...

On Monday 27 October 2014 15:48:28 Kenneth Adam Miller wrote:

...

On Mon, Oct 27, 2014 at 3:03 PM, Kenneth Adam Miller <

kennethadammiller@gmail.com> 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.

The formatter just composes a string from the attribute values attached to the record, it's the sink backend that is supposed to do something with that string, like output to the console or send over the network. Text-based backends typically don't need to access the record view (although they're still able to) because the formatter already did all

On Monday 27 October 2014 23:30:09 you wrote: the

...

job.

...

...

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?

With formatter, you just have to use it in the formatting expression. A few examples are here:

...

rs.html

Basically, you need the attribute value name and type to do that.

...

Reading some more at the top of this:

http://boost-log.sourceforge.net/libs/log/doc/html/log/tutorial/formatters

...

.h tml

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.

There is no built-in formatter in the library that just iterates

http://www.boost.org/doc/libs/1_56_0/libs/log/doc/html/log/tutorial/formatte through the

...

values in the record, you have to write your own. It's simple, just write a function like described here:

...

rs.html#log.tutorial.formatters.custom_formatting_functions

The record view has attribute_values() member, which returns an associative container of all attached values in pairs (name; value). Each value is an object of attribute_value class, from which you can extract the actual contained value through one of the approaches listed in the link I

http://www.boost.org/doc/libs/1_56_0/libs/log/doc/html/log/tutorial/formatte posted

...

earlier. In particular, you can use visitation and something similar to a print_visitor class in the example here:

http://www.boost.org/doc/libs/1_56_0/libs/log/doc/html/log/detailed/attribut

...

es.html#log.detailed.attributes.related_components.value_processing.visitati

...

on

Of course, the formatter should insert its output into the provided stream, not std::cout.

PS: Please, don't top post.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Ah ok, I got it now, it's mostly working.

But I'm getting an error when I set up my formatter... I followed the example exactly for the format_date_time to get a timestamp, and I'm getting a compile error.

sink->set_formatter( stream << format_date_time

...

("TimeStamp", "%Y-%m-%d %H:%M:%S") << message);

blows up pretty bad.

Also, adding a line for severity

<< "[" << boost::log::trivial::severity << "] "

just yields [] in the output lines.

I got everything to work, and I'm doing ok. Thanks! :)

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- www.maidsafe.net