Hi Chris,
You shouldn't need a custom ILog object to do what you want as your second
possibility could be done with MDC/NDC calls.. Yes, you'd have to
pre-populate them before calling log.Info and such.. But that's the only
way I can see of passing along multiple distinct values to the appender with
each message without altering the plumbing of log4net to support it more
directly.
-Peter
On Thu, May 8, 2008 at 8:49 PM, Chris Jerdonek <[EMAIL PROTECTED]>
wrote:
> Hi, we've been using log4net for a few months now, and I've been on this
> list for about the same. I have a design question.
>
> What would be the "correct" way to do the following?
>
> We'd like to log to a database using the AdoNetAppender. From our code,
> when we call things like log.Debug, log.Info, log.Warn, etc. we'd like to be
> able to pass not just a "message" but also things like a local message code,
> message details, etc and then have those show up in separate columns in the
> database. Also, the list of things we pass may change over time.
>
> To implement this, it seems natural to store these additional values in
> ThreadContext.Properties, and then access them in the Web.config via (for
> example) %property{msgcode}.
>
> Would we, for example, want to wrap the LogManager class with our own class
> whose GetLogger method returns an ILog with overloaded Debug, Info, Warn,
> etc. methods?
>
> One problem with this approach is that if every one of these methods had
> message code, message details, etc in the signature, then it would probably
> be hard to maintain: there may be lots of overloads, and changing the
> signatures over time would probably break things.
>
> Another possibility is to have the custom ILog object expose setters for
> things like message code, message details, etc (which would wrap writes to
> ThreadContext.Properties); but this would make calling log.Info, log.Warn,
> etc. a bit more verbose -- you would have to set everything prior to calling
> the log method instead of just including them as parameters in the method
> call. Also, you would probably want to delete those particular
> ThreadContext.Properties values so they don't persist to the next log
> message.
>
> Any thoughts?
>
> Okay, thanks,
> --Chris
>
>
>
> --
> Chris Jerdonek
> Software Developer
> P: (415) 357-3618 Ext. 1357
> Granicus, Inc.
>
>
--
Peter's Photography
www.PeterDrier.com
