Hey guys
I havn't heard anything on this in a while. Just checking in to see if
this is going to move forward.
Cheers
Anthony
On Nov 5, 1:34 pm, vdhant <[EMAIL PROTECTED]> wrote:
> 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
>
> ...
>
> 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
-~----------~----~----~----~------~----~------~--~---
