[
https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831247#comment-13831247
]
Dominik Psenner edited comment on LOG4NET-409 at 11/25/13 8:03 AM:
-------------------------------------------------------------------
{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:
if(PayPalLogger.IsWarnEnabled)
\{ PayPalLogger.Warn(myParserMethod(myIpnMessage)); }{quote}
Using LOG4NET-290 this could be shortened to:
{code}
PayPayLogger.WarnExt(() => myParserMethod(myIpnMessage));
{code}
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:
TransactionLogger.Error(myTransaction);
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:
{code}
class LogWrapper<T>
{
public LogWrapper<T>(ILog logger) {}
}
{code}
{code}
class Logic {
static ILog logger = ..
static LogWrapper<IpnMessage> ipnMessageLogger = new
LogWrapper<IpnMessage>(logger);
...
}
{code}
was (Author: nachbarslumpi):
{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:
if(PayPalLogger.IsWarnEnabled)
\{ PayPalLogger.Warn(myParserMethod(myIpnMessage)); }{quote}
Using LOG4NET-290 this could be shorteded to:
{code}
PayPayLogger.WarnExt(() => myParserMethod(myIpnMessage));
{code}
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:
TransactionLogger.Error(myTransaction);
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:
{code}
class LogWrapper<T>
{
public LogWrapper<T>(ILog logger) {}
}
{code}
{code}
class Logic {
static ILog logger = ..
static LogWrapper<IpnMessage> ipnMessageLogger = new
LogWrapper<IpnMessage>(logger);
...
}
{code}
> 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 customers.
> 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
(v6.1#6144)
