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)
> > > > > {
> > > > > 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
>
> ...
>
> 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
-~----------~----~----~----~------~----~------~--~---
