So I guess we could summarise what we have got so far as follows:
1) Event based context logging properties is something that people are
interested
1a) The best place to implement the support would be in
IExtendedLogger as originally discussed
- As for what come next seems to be a bit hazy...
- We could add another set of methods to IExtendedLogger which
allows for event based context logging properties to be passed in as a
parameter,
- We could go a little more advanced and create a stackable/
scopeable event based context logging properties construct which gets
passed in to relevant log method being used
- We could make no changes to IExtendedLogger and make it so the
only way that you could use event based context logging properties is
to use the new LoggingEvent. But if this did occur the first think i
would be doing is creating a set of extension methods myself which
would given me the appearance of a new set of methods added to
IExtendedLogger which allow me to add in the event logging properties.
Personally I think others would to this as well, hence an embedded
solution may be cleaner.
2) A core "Log" method should be implemented in ILog
2a) All current log methods (i.e. Debug, Error, etc) would be
changed to call this log method
2b) The log method would be implemented within base class and would
be overridden by implementations such as Log4Net
2c) To state the obvious this Log method would be public and could
be called directly in situation where the log level is determined at
run time
3) LoggingEvent object could be introduced
- I think more details would need to be worked out as to what the
posible interface for ILoggingEvent would be
- Reason being that the LoggingEvent class in Log4Net is rather
vobes (i am guess the others are too) and have large composition
chains (note sure if that is really a term but i think you will get
the picute)
- In saying this I think that we could state the below, let me know
what you think
3a) Before LoggingEvent can be created we need an ILoggingEvent
interface (again sorry for what maybe stating the obvious)
3b) This interface will force the implementation of arguments that
can be currently passed into the current log methods (i.e. Debug,
Error, etc) and any additional items that come out of this unit of
work
3c) A version of the new Log method in ILog will be provided which
allows for an ILoggingEvent to be passed in
If i have missed anything so far let me know.
Outstanding issues are the:
- Event based context logging properties
- An interface for LoggingEvent
Cheers
Anthony
On Nov 5, 9:44 am, "Alex Henderson" <[EMAIL PROTECTED]> wrote:
> I think it will play just fine with the underlying implementations - if you
> take a look at log4net you'll find the various logging methods implemented
> on the log4net.Core.LogImpl class (ILog interface) all end up being
> directed to one of two methods on the underlying ILogger class:
>
> void Log(Type callerStackBoundaryDeclaringType, Level level, object
> message, Exception exception);
> void Log(LoggingEvent logEvent);
>
> I certainly was not proposing dropping the existing Debug etc. methods - 99%
> of the time it's all you need for most logging requirements - just that
> providing a more dynamic/flexible Log method would suit both user extensions
> such as event-level properties and simplify the current implementation a
> bit, especially if targeting other logging frameworks which may not
> implement a similar interface. I guess we have to decide where opinions lie
> around other possibilites if going down this path (i.e. do we stick with the
> existing set of logging levels, or support additional logging levels through
> some kind of mechanism, like most logging frameworks support in way or
> another).
>
> A single underlying Log method would also make it easy to implement support
> for say capturing log4net logging events and redirecting them to the logging
> facilities implementation too, if for example you wanted to support a
> logging framework other then log4net when using NHibernate.
>
> As you say extension methods aren't accessible to all consumers (or easily
> discoverable) and IExtendedLogger already encapsulates other contextual
> properties - so it seems logical to bundle that functionality into the
> existing interface rather then tack on some extension methods.
>
> Cheers,
>
> - Alex
>
> On Wed, Nov 5, 2008 at 12:12 PM, Gauthier Segay <[EMAIL PROTECTED]>wrote:
>
>
>
> > @ 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
>
> ...
>
> 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
-~----------~----~----~----~------~----~------~--~---
