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
-~----------~----~----~----~------~----~------~--~---
