logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominik Psenner (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4NET-409) Generics added to the Logger
Date Mon, 25 Nov 2013 08:04:36 GMT

    [ https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831247#comment-13831247

Dominik Psenner commented on LOG4NET-409:

{quote}I was suggesting an addition to the existing API that would take advantage of the Generics
feature in the newer frameworks.{quote}

It does, see LOG4NET-290. But introducing generics increases the impact of logging logic in
the codebase. On top it pollutes the API with yet another thousands overloads for something
that the logging framework does neither care of, nore does it need it to do its job.

{quote}It is no doubt negligible but, I also wonder if the Object Renderer might help with
efficiency in some tiny way? For example:
\{ PayPalLogger.Warn(myParserMethod(myIpnMessage)); }{quote}

Using LOG4NET-290 this could be shorteded to:

PayPayLogger.WarnExt(() => myParserMethod(myIpnMessage));

ObjectRenderes are there to render objects - nothing fancy there. Lambda expressions on the
other hand can cover the gap where objects need to be rendered differently based on some state
that is not known to the ObjectRenderer.

There's no need to introduce a thousandfold of different loggers just to achieve that. I would
never let a mere logging framework logic use up more than one static attribute in every class.
It complicates code, replicates logic and does not really produce a value because there are
other ways to achieve this.

{quote}PayPalLogger.Error(myTransaction); // oops
should of been:
These errors are not getting emailed to me, and the first I hear of it is 28 days later when
the customer is asking why their order has not turned up yet within the 28 day delivery period.{quote}

Think of the logging framework being a mixer. You can put in an apple, an orange or a cat
- it will mix up everything you ask it to. If you need type safety around it wrap it up:

class LogWrapper<T>
   public LogWrapper<T>(ILog logger) {}

class Logic {
  static ILog logger = ..
  static LogWrapper<IpnMessage> ipnMessageLogger = new LogWrapper<IpnMessage>(logger);

> Generics added to the Logger
> ----------------------------
>                 Key: LOG4NET-409
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-409
>             Project: Log4net
>          Issue Type: Wish
>          Components: Core
>    Affects Versions: 1.3.0
>            Reporter: Ben
>              Labels: features
> Maybe this has been suggested before - if so sorry (I did do a search for it).
> I am fairly new to log4net and when I am using it, I was surprised to see that the log
methods take an object as a parameter.  Of course this made sense after I found out that Object
Renderers can be made to parse any type of object.  I did wonder why Generics was not used.
> If I have an Object Renderer that knows how to log Orange objects then I don't want to
accidentally pass it an Apple object (or any other type of object).
> So using Generics I would set up my logger as follows:
> private ILog<Orange> myOrangeLogger = LogManager.GetLogger<Orange>("OrangeLogger");
> I have just made a special type of logger that can log oranges.  Instead of accepting
parameters of type object it accepts only strings and Oranges.  Behind the scenes the method
> LogManager.GetLogger<T>(string name) 
> would return a logger of type ILog<T>.
> The ILog<T> interface would have methods on it like:
> ILog<T>.Warn(string message);
> ILog<T>.Warn(T message);
> ILog<T>.Warn(string message, Exception ex);
> ILog<T>.Warn(T message, Exception ex);
> but would NOT have the method:
> ILog<T>.Warn(object message);
> So now if I tried to pass it an Apple object I would get a compile error rather than
the default behaviour for a logger which has been given an object that has no special renderer
(in fact I probably wouldn't even realise until I went to look at the log files right?). 
This would be much better and would help to save me from embarrassing myself in front of my
> This could be added in addition to the standard loggers which would still be returned
in the normal way using:
> LogManager.GetLogger(string name);
> If this has not already been suggested then I hope you like this idea.

This message was sent by Atlassian JIRA

View raw message