@ Anthony
you are right, I mistaken your proposition to be applied to ILogger.
Indeed, IExtendedLogger seems the right place to put proposed
extensions; managing the event stack should belong to the extended
logger as you state it.
@ Alex
Having Log method with at least loglevel is really usefull (as well as
IsLogLevelEnabled) when you do not want to set the log level in stone,
I've worked arround this with extension methods myself but an embeded
solution is better.
However, few things to keep in mind:
- extension methods are nicely consumed in C# (it seems to me that not
every "consumer" languages support them)
- Needing to instanciate a LogEvent in client code sucks 99% of the
time, logging should be oneliner as much as possible (anyone ever saw
first occurence of MSENTLIB logging statements?)
as for the idea of having only one base Log statement that all other
methods use seems good on the maintenance standpoint, it means all
theses methods can be set in a base logger class, but I'm unsure if it
plays well with underlying logging frameworks.
On Nov 4, 9:11 am, bittercoder <[EMAIL PROTECTED]> wrote:
> 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
>
> ...
>
> 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
-~----------~----~----~----~------~----~------~--~---
