Hmm... just thinking about this...
Currently event logging in general is missing from the logging
implementation in Castle - both log4net and nlog support logging
events (LoggingEvent in log4net and LogEventInfo in nlog) and it would
be pretty easy to create an abstraction to fit our needs (i.e.
message, arguments, exception, context properties etc.) - it seems to
me we could introduce a Log method to the base ILogger interface,
taking an LoggerEvent, introduce a common base class shared by both
logging implementations for the various Debug/DebugFormat etc.
overloads - all which just construct logger events and pass them to a
single Log method that needs to be implemented for either logging
framework - and gives us a single place to apply changes to any
information being logged.
As for event context properties support - if we had a single Log
method that means we could then introduce either additional methods to
IExtendedLogger or just use extension methods (which just make calls
to ILogger's Log method) to achieve what your originally proposed
(i.e. being able to pass in the context properties to the various
Debug/Info etc. logging overloads and have them used for that single
event).
Thoughts?
Cheers,
- Alex
On Nov 3, 10:26 am, vdhant <[EMAIL PROTECTED]> wrote:
> Just as a side note, none of the changes that i have suggested would
> require a change to ILogger, it would only require a change to
> IExtendedLogger. Can you please confirm that you believe that this
> would be the case, as from what you have said it sounds like you think
> that we would be changing ILogger, only IExtendedLogger would a
> change.
>
> Any changes would integrate very nicely with IExtendedLogger, as
> IExtendedLogger defines the global and thread properties, so to me it
> would make sense that event based properties would go here as well.
>
> Also, with what you have suggested makes sense and i can see that you
> are trying to keep the context properties separate. But i still think
> that the logger (through IExtendedLogger) would need a reference to
> the event based context properties somehow. Otherwise how and where do
> you get an instance of LoggingContextStack from and how does the
> logger end up knowing about it?
>
> The last thing that I would want is to have to have another property
> on my class that has to do with logging. Also, i don’t think having
> LoggingContextStack as a static property so anyone could reference it
> is a very good solution (i.e. the logger and my classes). If it comes
> of IExtendedLogger like the below, the logger is responsible for
> creating the instance and would have a reference to the stack and it’s
> still instance based:
>
> IContextProperties tempProperties =
> Logger.LoggingContextStack.GetEventContextProperties();
> tempProperties[“CustomProperty1”] = “Custom Value 1”;
>
> using (Logger.LoggingContextStack.Current.Push(tempProperties))
> {
> Logger.Error("Test error");
>
> IContextProperties tempInnerProperties =
> Logger.LoggingContextStack.GetEventContextProperties();
> tempInnerProperties[“CustomProperty1”] = “Override Custom Value
> 1”;
> tempInnerProperties[“CustomProperty2”] = “New Custom Value 2”;
>
> using
> (Logger.LoggingContextStack.Current.Push(tempInnerProperties))
> {
> Logger.Error("Test error");
> }
>
> }
>
> Let me know what you think.
> Cheers
> Anthony
>
> On Nov 3, 1:18 am, Gauthier Segay <[EMAIL PROTECTED]> wrote:
>
> > What you show would be nice, but I have still a concern to add new
> > members to the ILogger.
>
> > Does the context properties bellongs to a particular logger instance
> > (or name)? If not it would be more meaningfull (imho) to have :
>
> > using(LoggingContextStack.Current.Push(...)){
> > // mess with log
>
> > }
>
> > public interface ILoggingContextStack {
> > ILoggingContextStackPusher Push(params KeyValuePair<string,object>
> > properties);
>
> > }
>
> > public interface ILoggingContextStackPusher {
> > ILoggingContextStackPusher Set(string propertyName, object
> > propertyValue); // need better name than Set
>
> > }
>
> > Does it make sense?
>
> > On Nov 1, 1:50 pm, vdhant <[EMAIL PROTECTED]> wrote:
>
> > > Hi Gauthier
> > > When you say stack based approach do you mean like the way
> > > TransactionScope stacks?
>
> > > So would you think that it would work something like the following:
>
> > > IContextProperties tempProperties =
> > > Logger.GetEventContextProperties();
> > > tempProperties[“CustomProperty1”] = “Custom Value 1”;
>
> > > using (..... = Logger.AddLocalContextProperties(tempProperties))
> > > {
> > > Logger.Error("Test error");
>
> > > IContextProperties tempInnerProperties =
> > > Logger.GetEventContextProperties();
> > > tempInnerProperties[“CustomProperty1”] = “Override Custom Value
> > > 1”;
> > > tempInnerProperties[“CustomProperty2”] = “New Custom Value 2”;
>
> > > using (..... =
> > > Logger.AddLocalContextProperties(tempInnerProperties))
> > > {
> > > Logger.Error("Test error");
> > > }
>
> > > }
>
> > > With the above internally within Logger, a stack of IContextProperties
> > > is maintained via AddLocalContextProperties. Next when Logger.Error is
> > > called if it detects that the stack is not null it switches over and
> > > calls the following:
>
> > > private void LogWithContextProperties(.....)
> > > {
> > > LoggingEvent loggingEvent = new LoggingEvent(declaringType,
> > > Logger.Repository, Logger.Name, Level.Error, message, null);
>
> > > foreach (….) //Note here it there are 2 options see below
> > > loggingEvent.Properties[eventProperty.Key] =
> > > eventProperty.Value;
>
> > > Logger.Log(loggingEvent);
>
> > > }
>
> > > 2 posible options for setting the properties, 1 it would only read the
> > > item on the top of the stack, or 2 it would walk through the stack
> > > starting at the bottom and walk back up so that in the situation where
> > > the same property was being set by two different items on the stack
> > > that top most one would win out. The latter allows for some
> > > interesting scenarios but is less performant.
>
> > > Is this along the lines of what you where thinking??
> > > Cheers
> > > Anthony
>
> > > On Nov 1, 9:32 pm, Gauthier Segay <[EMAIL PROTECTED]> wrote:
>
> > > > Hi Anthony,
>
> > > > I've never used the feature for log4net, but it seems very usefull.
>
> > > > As for it's integration in Castle.Core.Logging, I would say that I
> > > > prefer to avoid additional overrides for actual logging statements and
> > > > would like more the stack based approach from log4net (where you don't
> > > > give the context properties instance).
>
> > > > The first step would be to propose an interface to manipulate context
> > > > properties scope, taking use of using(IDisposable) idiom
>
> > > > On Nov 1, 7:49 am, vdhant <[EMAIL PROTECTED]> wrote:
>
> > > > > Just bumbing this as i was wondering what people think...
> > > > > Cheers
> > > > > Anthony
>
> > > > > On Oct 31, 10:54 am, vdhant <[EMAIL PROTECTED]> wrote:
>
> > > > > > Ok guys here is what I was thinking.
>
> > > > > > The concept of “event based context logging properties” is that here
> > > > > > are a set of custom properties that are only applicable for this
> > > > > > individual log entry.
>
> > > > > > For instance if I had the below scenario I would only want the
> > > > > > custom
> > > > > > properties being set for the middle log entry:
> > > > > > ….
> > > > > > Logger.Error("Test error"); //Normal log entry
> > > > > > ….
> > > > > > Logger.Error("Test error", ….); //Need to set some custom
> > > > > > properties
> > > > > > ….
> > > > > > Logger.Error("Test error"); //Normal log entry
> > > > > > ….
>
> > > > > > These custom properties may be the state of given object or a custom
> > > > > > log type id that means something to us or custom details of the user
> > > > > > who is currently logged in (not just their user name).
>
> > > > > > Now a fair amount of the pluming required to do this currently
> > > > > > already
> > > > > > exists, for instance IContextProperties is what one would use as the
> > > > > > interface for the new event properties class.
>
> > > > > > Next, because the way in which the event based properties would
> > > > > > “normal” work, there is no difference between event properties from
> > > > > > one logger to the next. Specifically, GlobalContextProperties needs
> > > > > > to
> > > > > > be implemented differently for each logger because when a property
> > > > > > is
> > > > > > set it goes directly into what ever global cache the logging
> > > > > > implementation uses – meaning it is actioned on as soon as the
> > > > > > property is added to GlobalContextProperties. Where as, event based
> > > > > > properties are only actioned on when a log entry is made, not when
> > > > > > the
> > > > > > are added to the new EventContextProperties object. Hence I was
> > > > > > thinking that there would only be the 1 event based property class
> > > > > > (EventContextProperties) which could be used by all implementations
> > > > > > and EventContextProperties would be very simple and only implement a
> > > > > > basic key/value structure of some sort.
>
> > > > > > Hence the way in which I was thinking one would actually use event
> > > > > > based properties is like this:
>
> > > > > > ….
> > > > > > Logger.Error("Test error"); //Normal log entry
> > > > > > ….
> > > > > > IContextProperties tempProperties = ….; //Where you get the instance
> > > > > > of EventContextProperties for the moment is not that important
>
> > > > > > tempProperties[“CustomProperty1”] = “Custom Value 1”;
> > > > > > tempProperties[“CustomProperty2”] = “Custom Value 2”;
> > > > > > tempProperties[“CustomProperty3”] = “Custom Value 3”;
>
> > > > > > Logger.Error("Test error", tempProperties); //Need to set some
> > > > > > custom properties
> > > > > > ….
> > > > > > Logger.Error("Test error"); //Normal log entry
> > > > > > ….
>
> > > > > > From the above you can see that my initial thoughts is to make a
> > > > > > slight modification to the IExtendedLogger interface to include the
> > > > > > ability for users to pass in IContextProperties (which is what
> > > > > > EventContextProperties inherits from) as a parameter.
>
> > > > > > Now the methods that allow for IContextProperties to be passed in
> > > > > > would need to be different from logging implementation to looking
> > > > > > implementation. If the logger doesn’t have the ability to implement
> > > > > > event based properties, then either they throw an exception if that
> > > > > > overload is used or they only throw an exception for those
> > > > > > situations
> > > > > > where IContextProperties contains values (I think the former would
> > > > > > be
> > > > > > the better more reliable scenario). Or maybe it could just ignore
> > > > > > the
> > > > > > properties all together if a setting in the config is set but by
> > > > > > default it would throw an exception. In situations where it is
> > > > > > possible to implement event based properties something like the
> > > > > > following would occur (note this is what would be in the log4net
> > > > > > implementation):
>
> > > > > > public void Error(string message, IContextProperties
> > > > > > eventProperties)
> > > > > > {
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Castle Project Development List" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/castle-project-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
