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