Hi Anthony,
I suppose, the best now is to create an issue to attach patches with
each basic features of your extensive summary, this way we could have
the feature and discuss further more advanced option that are still
"hazy"
- add overrides to logging methods to accept extended properties
- refactor with Log statement
- make the patch applied
then go further.
what do you think?, also what does Ernst Naezer (which is ultimately
managing this component) think?
On Nov 10, 10:16 pm, vdhant <[EMAIL PROTECTED]> wrote:
> 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";
> > > > > >
>
> ...
>
> 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
-~----------~----~----~----~------~----~------~--~---
