I think it's a little confusing - I believe Ernst Naezer has logging services (i.e. the logging components) and I have the Logging facility, along with the batch registration and factory support facilities.
I personally have been swamped with client work so I'm not going to be able to catch up with open source commitments till christmas where I'll aim to get all the documentation up to date, try and provide patches for any unresolved bugs against those facilities etc. As a non-committer my Avenue is much the same as yours Anthony - so if you have to develop these changes anyway I would suggest doing it against a copy of trunk and submitting a patch reflecting the previously discussed approach, as long as the existing ILogger interface does not change and it has good test coverage I don't think it should take long to be applied by one of the committers. Sorry I can't be more helpful at this time! Cheers, - Alex On Wed, Dec 3, 2008 at 1:59 PM, vdhant <[EMAIL PROTECTED]> wrote: > > Thanks for the reply: > - For the record I have created the following issue over a month ago - > > http://support.castleproject.org/projects/FACILITIES/issues/view/FACILITIES-ISSUE-105 > - Please let me know if this is what you where referring to > - I will endeavour to get in contact with Ernst Naezer > - Previously I have been in contact with Alex Henderson who I > though was responsible of the logging but I must have been wrong > - As for working on the tests and features that's the one thing that I > can control and if I get the go ahead will put into the logging > facility rather than the abstraction layer previously mentioned. > > Cheers > Anthony > > On Dec 3, 9:19 am, Gauthier Segay <[EMAIL PROTECTED]> wrote: > > 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 > > > > ... > > > > 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 -~----------~----~----~----~------~----~------~--~---
