[boost] Re: Re: Re: logging lib, v1.3

From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2004-11-02 09:19:56

"John Torjo" <john.lists_at_[hidden]> wrote in message
news:41868F4A.1030406_at_torjo.com...
>

[snip side-note]

> >
> >
> >>That's an interesting idea.
> >>
> >>One problem that I see with the above taking place in another thread is
> >>that you don't know when it'll happen. This does not play well with:
> >>- pre-pending time
> >>- pre-pending thread ID
> >
> >
> > I basically was thinking about log "messages" as data structures,
> consisting of least one message id (possibly consisting of facility,
> severity and the id itself, similar to COM hresults and VMS status codes)
> + insertion data. Logging a message would include creating an instance of
> a log item and storing it in the TSS buffer for later retrieval,
> formatting and writing by the worker thread. Data such as timestamps,
> thread id, etc is added at this point and can be selected for
> inclusion/exclusion in the actual writing on the back-end instead.
>
> So basically, after a message is added, a log_item is created, and
> different modifiers can fill different things of this log_item itself.
> Then, the appender(s) will decide which information to write to the real
> destination(s). This is an interesting idea.
> You could then pass a format string to the appender - kind of like log4j.
> This will complicate the design - but it seems to worth it.
>
> Is this what you're talking about, or am I totally on the wrong track?
>

You are definitely closing in ;-)

I don't have so much spare time exactly right now, sorry. I'll try to
elaborate ASAP.

>
> >
> > Using message id's would also facilitate localization,
> which would be a good thing for end-user visible logging.
>
> How do you envision this?

Use message id's instead of literal strings in the interface. Postpone id ->
text transformation until "append-time". Once you've got a formatted message
it's much harder to translate it. Note that I'm only talking about the
"human-readable" part of the log item - not including the modifier stuff
(time, thread id, etc).

>
> >
> >
> >>Whenever you add an appender/modifier, you don't specify which log it
> >>will be added to - you specify a logs_specification, where you can use
> >>the * wildcard (same goes for enabling/disabling).
> >
> >
> > Maybe it's the word "log" that confuses me. For me a log is more the
final destination; e.g.
> the event log, a file, etc ... In this case it is more like a channel
> for log messages, or?
>
> "log" seems to mean different things to different people ;)
> However, having the BOOST_LOG macro seems to be quite straightforward to
> people.

Yes, I've got no objections to the name of the macro. Perhaps
BOOST_LOG_MESSAGE would be even better, but you'd quickly get fed up writing
that.

> For example, having BOOST_CHANNEL to do logging - it seems kind of
> misleading.
>

That would definitely be a bad and misleading name.

> Any better name out there?
>

The macro name is fine with me at least.

> >>
> >>>- This opinion is probably not shared with others, but I'd prefer the
library to be independent
> >>
> >>from the Boost Thread library. The dependency feels kind of the wrong
> >>way around.
> >>
> >>This dependency is only if you use threads yourself.
> >
> >
> > Naturally, but that alone might be enough to make some people
> refrain from using it. I'd prefer not having to add the
> boost thread library to my dependencies simply because
> I want to log message in the background. Also, there might be special
> circumstances when you'd like to log messages from system invoked
routines,
> e.g. Win32 completion routines/APCs/console control handlers,
> Unix signal handlers, VMS ASTs, system thread pool callbacks etc...
>
> True. Well, it's not that complex to remove the dependency on
> boost.thread (that is, have a certain directive, which if turned on, to
> ignore threads).

Ignore Boost.Thread, that is?

>
> The problem I have now is how to update the jamfile, so that it will
> generate the following:
> - static lib + multi-thread runtime + using thread (already done)
> - static lib + multi-thread runtime + not using thread (problem here)
> - static lib + single-thread runtime + not using thread (already done)
> (not sure if this is just an MSVC issue)

"thread" above refers to Boost.Thread?

>
> >
> > Clearly needs Boost.Thread or thread support in general?
>
> thread support. You can override it - with your own mutex and lock
classes.

And thread classes/functions (as used for e.g. the ts_appender thread)?

>
> However, I do need to refine the log-manager concept. Also, if you
> provide your own mutex/lock classes, you might need to include the log
> source files within your project.

I'd prefer not to (of course). How about a light-weight implementation for
Win32 and Posix threads?

>
>
> >>
> >
> >
> > I believe that it's not so simple to integrate with the
> > NT event log as the current Boost.log is entirely based on pre-formatted
strings.
> > The event log is more based on message id's, insertions strings and
> > message resource dlls, IIRC (long time since I used NT event logging).
>
> unique IDs are not hard to generate. Anyway, I haven't used NT event
> log, but I don't think it should be very difficult to use.
>

It's actually pretty complex. From the top of my head (as I said, it's been
a while since) you basically need to:

- Create a message resource from a message definition file (using mc.exe)
- Create a dll to hold the resource
- Register an event source in the registry where you define where your
message resource dll is located.
- When you log a message, use the source and message id, add any insertion
strings as an array of strings.

Regards // Johan