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)
> > > > {
> > > > LoggingEvent loggingEvent = new LoggingEvent(declaringType,
> > > > Logger.Repository, Logger.Name, Level.Error, message, null);
>
> > > > foreach (….)
> > > > loggingEvent.Properties[eventProperty.Key] =
> > > > eventProperty.Value;
>
> > > > Logger.Log(loggingEvent);
>
> > > > }
>
> > > > As you can see from the above, log4net implements event based looking
> > > > through the use of LoggingEvent. Also look at the above we may need to
> > > > use a interface that implements IEnumerable so we can loop through the
> > > > EventContextProperties pairs.
>
> > > > Lastly, as for where we get an instance of EventContextProperties
> > > > from, I was thinking that it could be something like the below. If
> > > > this is done, it helps abstract way the creation of
> > > > EventContextProperties and means that for extensibility reasons,
> > > > different loggers could implement different versions if required
> > > > (although I couldn’t see why this would occur).
>
> > > > ….
> > > > Logger.Error("Test error"); //Normal log entry
> > > > ….
> > > > IContextProperties tempProperties =
> > > > Logger.GetEventContextProperties();
> > > > tempProperties[“CustomProperty1”] = “Custom Value 1”;
> > > > …
>
> > > > Logger.Error("Test error", tempProperties); //Need to set some
> > > > custom properties
> > > > ….
>
> > > > Hope that helps clear up what I was thinking.
> > > > Cheers
> > > > Anthony
>
> > > > On Oct 31, 2:14 am, "Shawn Hinsey" <[EMAIL PROTECTED]> wrote:
>
> > > > > This sounds really interesting but the documentation isn't very clear
> > > > > on exactly how it works. Do you have an example somewhere?
>
> > > > > On Wed, Oct 29, 2008 at 6:06 PM, vdhant <[EMAIL PROTECTED]> wrote:
>
> > > > > > Hi guys
> > > > > > I have a need to utilise event based logging within log4net (see
> > > > > >http://logging.apache.org/log4net/release/manual/contexts.html).
>
> > > > > > The problem is that as far as I can tell, the Logging Facility in
> > > > > > Castle doesn't allow one to define properties at this level of
> > > > > > scope.
> > > > > > Please let me know if this is not the case.
>
> > > > > > I have been looking through the implementation details of Logging
> > > > > > Facility and I think that it wouldn't be that difficult to add the
> > > > > > functionality in. I think that the functionality would go really
> > > > > > well
> > > > > > in Castle.Core.Logging.IExtendedLogger. And it shouldn't be a
> > > > > > breaking
> > > > > > change (unless someone has implemented their own IExtendedLogger -
> > > > > > in
> > > > > > which case they would need to implement the additional event based
> > > > > > context properties on the interface).
>
> > > > > > Now what I was wondering is if anyone would be interested in myself
> > > > > > (or if someone can do it in a timely fashion as I have a need for it
> > > > > > directly) adding this functionality into Castle itself.
>
> > > > > > The alternative is that I just create a class which inherits from
> > > > > > ExtendedXYZFactory. But this implementation isn't as clean and it
> > > > > > doesn't help Castle move forward if this functionality is wanted in
> > > > > > Castle itself.
>
> > > > > > Let me know
> > > > > > Anthony
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
