Just bumping this as I was wondering if anyone is still interested in this.
The reason for asking is that I am coming very close to needing to use these features. I am happy to do most of the work I am just wanting to know if people want it feed back into the open source project and how long a process it is to feed it back in. If there is no interest in moving this forward in the short term, I will create my own set of classes that inherit from the classes discussed, which add the additional functionality. Otherwise if people are interested I will add the code directly to the base classes (as discussed) and feed to back. Also this is something that I need to have done and dusted in the next 2 weeks. Hence if there is no chance of getting it into the main project within that time frame or there is no interest I will simple go with my own set of classes solution. I have been pushing very hard to try and avoid this as I would like the work to go back into the main project, but if I don't get some sort of feedback I don't have much choice. Cheers Anthony On Nov 12, 7:50 am, vdhant <[EMAIL PROTECTED]> wrote: > Cheers > And just so you know I created this a little while ago. > Not sure if its what you mean by creating an issue but this is what I > have done so far. > > http://support.castleproject.org/projects/FACILITIES/issues/view/FACI... > > Cheers > Anthony > > On Nov 11, 10:05 pm, Gauthier Segay <[EMAIL PROTECTED]> wrote: > > > 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 > > ... > > 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 -~----------~----~----~----~------~----~------~--~---
