Hello Anthony, your contribution is valuable, and I understand your frustration from the lack of clear answer.
I'm not a commiter to the project so I can't warrant that your contribution will be integrated in the trunk within the 2 weeks timeframe but it seems rather doable if your implementation plan is well put. The constraint for the feature being integrated would be to have decent coverage and source code formatting / namingscheme complying to the rules, having the bit documented would be great but I think a draft (few §) would do so the community can work together to clean it up. The best you have to do is: - create an issue in donjon - contact Ernst Naezer which is the responsible of the logging component to ensure that your contribution will be accepted and if it can be done within required timeframe - work on the tests and the features All design choose you exposed before seems to be good/effective from the usability standpoint. I hope this contribution will make it to the trunk :) On Dec 2, 10:47 pm, vdhant <[EMAIL PROTECTED]> wrote: > 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 > > ... > > 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 -~----------~----~----~----~------~----~------~--~---
