beat me, I already know the issue exists :) however the rest should
apply
On Dec 3, 12: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
-~----------~----~----~----~------~----~------~--~---
