Looks like there's already an issue open for this: http://issues.apache.org/jira/browse/LOG4NET-38
--- Ron Grabowski <[EMAIL PROTECTED]> wrote: > --- Billy Barnum <[EMAIL PROTECTED]> wrote: > > > Right. Log4Net error msgs all have the same eventId. This is > exactly > > what I > > want to change. > > The documentation for the EventLogAppender says: > > " > If the event has an EventID property set then this integer will be > used > as the event log event id. > " > > which means if you set an EventID property: > > log4net.ThreadContext.Properties["EventID"] = 5; > > That value will be sent to the Event Log. I may have used incorrect > casing on EventID in one of my earlier posts. > > > I'm certainly no EventLog guru, but what I know is this: EventId is > > not a PK > > at all. It is, however, meant to be unique within an EventSource > and > > optionally an EventCategory; usage is up to the application. The > idea > > is > > EventSource and EventCategory provide context, while EventId > > identfies the > > particular problem. 2 side notes: > > The EventSource property for an event log entry is set via the > EventLogAppender's ApplicatioName property. The default value is: > > System.Threading.Thread.GetDomain().FriendlyName > > I don't think this is a value that needs to be settable on a per > message basis. > > > 1. Log4Net already provides built-in context with the logger > property > > that > > you can put in your logging message. IMHO it would be a great > log4net > > enhancement if this was passed through to the EventCategory field > in > > the > > EventLog for EventLogAppender in addition to or instead of putting > it > > in the > > There's currently no way to pass in or set an Event Category value > for > an event log entry. EventLogAppender uses this overload when logging > which doesn't pass in a value for event category: > > EventLog.WriteEntry(string, string, EventLogEntryType, int) > > I agree that it would be nice if it were possible to specify an Event > Category for each message logged or a default value for Event > Category. > Since we're already looking for EventID in the logging event's > properties we may want to also look for EventCategory and use that > value to call this overload: > > EventLog.WriteEntry(string, string, EventLogEntryType, int, short) > > Do you think it would be useful to allow default values for these > properties to be specified inside the config file and used if the > EventID or EventCategory property keys aren't present? > > <eventId value="5" /> > <eventCategory value="10" /> > > > msg. If I get some time here I'll dig in and do it myself. I > haven't > > actually built log4net yet; I've only been using the executable > > having just > > been using log4net for a week. > > If you're going to use TortoiseCVS to checkout the files this post > may > be helpful: > > http://www.mail-archive.com/log4net-user@logging.apache.org/msg02060.html > > Apache is going to be moving everything to SVN before the end of > year. > I thought the Logging Servics projects had a date set a few weeks ago > to make their move. I don't think has happened yet. > > > Back to issue at hand ... Ron, I tried your example code there, > with > > the > > threadcontext/setting EventId property to 5, and all. Quick > questions > > if you > > have time ... no hurry ... > > I must not have read the documentation correctly...try EventID. > > > 1. What's the diff between this threadcontext and MDC/NDC? > > This is what the release notes have to say about it: > > > http://logging.apache.org/log4net/release/release-notes.html#1.2.9-new > > MDC is now implemented using the ThreadContext. > > > 2. I still don't see how that eventid 5 gets to the eventid field > in > > EventLogAppender without going the extension route (your 2nd > > example). What > > do you put in your xml file? How does that go anywhere other than > the > > message text? > > log4net.ThreadContext.Properties["EventID"] = 5; > log.Debug("Hello World"); > > I don't think writting your own ILog is as terrible an idea as people > sometimes think it is. Log4net as we know it is really ILogger. The > default implementation of ILogger is itself abstracted through the > ILog > interface. If you know your company or project is going to be logging > a > lot of additional information other than the just messages and > exceptions, I would write a LogManager that returns a custom ILog: > > Company.Project.Logging.ILog > > You could write your implementation in such a way that you can load > up > either log4net 1.2.0 beta 8, log4net 1.2.9 beta, NLog, or MS's > Logging > Block at runtime without having to reference those assemblies > directly > from your project. > > > 3. When I used that threadcontext code, asp rebooted itself with > err > > msgs - > > which is sometimes a sign of stack overflow. Was there some cleanup > > and/or > > stack popping I needed to do? > > Posting the code you used and the error messages generated is always > helpful :) >