Re: [Log4cpp-devel] How does one "destroy" a category?

[<log...@li...>]

Hi Scott and Alexander,
On 16/03/15 09:39, log...@li... wrote:
> On 3/15/15, 7:25 PM, "log...@li..." <log...@li...> wrote:
> 
>> It appears it would make sense for each transaction state machine to
>> have its own log category, as the log messages can then be grepped for
>> and it ensures *every* log message from that log instance will have the
>> ID prepended.
> 
> I think you want to use a diagnostic context, not a category. Just push and pop the ID with the NDC routines.
> 
> (And you can't really destroy a category, so that's why it's a bad choice to use that.)

On 16/03/15 15:57, log...@li... wrote:
> The categories in current design are seen as purposed for kind of static
> matters, those which do not actively come into the processing and leave
> it. There is static helper method to make their creation convenient and
> controlled. However, there is no destroy method since the pointer given
> out might still be kept somewhere else, out of log4cpp internals.
> If you'd like to have an unique id coming along with your log messages,
> you could take advantage of the NDC feature. It is exactly purposed for
> attaching kind of context to the log messages. It can be turned on and
> off from properties file without rebuilding, but note that is linked
> with a thread, and not with the particular category.
> If your processing is not thread-based, won't it be easier to log the id
> just as a part of the message itself?

I'm doing some further research into this, NDC sounds closer to what I'm
after, however one things that concerns me is that it appears I need to
manually push my context onto it each time I enter a context rather than
just writing to an object that does this for me.

Basically what I'm after, is an object that I can hold either by
reference or pointer, that when I write to it, it applies the necessary
tagging to identify that line in the log and know where it came from.

Categories aren't ideal, but it does achieve this in a structured
manner.  I don't have to remember to tell it that I'm in a transaction
state machine context (which may be in a separate thread) or have to
remember to remove it at the end.

I'll do some more digging and see what I can uncover, but this looks
like it gets at least part-way there.
-- 
     _ ___             Stuart Longland - Systems Engineer
\  /|_) |                           T: +61 7 3535 9619
 \/ | \ |     38b Douglas Street    F: +61 7 3535 9699
   SYSTEMS    Milton QLD 4064       http://www.vrt.com.au