logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LOG4NET-409) Generics added to the Logger
Date Mon, 25 Nov 2013 00:35:35 GMT

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

Ben edited comment on LOG4NET-409 at 11/25/13 12:34 AM:
--------------------------------------------------------

Maybe I miss-understood your documentation, which says:

"log4net is built on a number of different frameworks. Each new version of the frameworks
add new features. To take advantage of these new features we must build log4net using the
appropriate framework."

(http://logging.apache.org/log4net/release/framework-support.html)

I was suggesting an *addition* to the existing API that would take advantage of the Generics
feature in the newer frameworks.  So there would be no issue with backward compatibility right?
 However, maybe what is being described is only the internals of the log4net assemblies and
not the API (although you do have different appenders for different framework builds).  Perhaps
I didn't understand this right.  Sorry.

With regard to you asking about a usecase, I think the problem comes when you have more than
one logger declared in the same class and these loggers have different jobs.  I can describe
my situation, but I am still in the development phase of this project and so we still have
some work to do on it.

I have an ASP website that is communicating with the PayPal (via IPN) and I would like to
log all communications.  I have designed my own helper class that encapsulates an IPN message,
lets call it IpnMessage.  After inspecting an incoming IpnMessage object I can decide if I
want to log it as INFO, WARN or ERROR.  This then gets logged to a special PayPal log file.
 Yea sure, I could write a special parser method to turn the IpnMessage object into a string
and then I could send that to the logger.  But isn't that what the Object Renderer is for?

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)); }

This will check the logger 2 times for IsWarnEnabled, however

PayPalLogger.Warn(myIpnMessage);

is cleaner code and will only use the Object Renderer after it has checked IsWarnEnabled just
once right?

Anyway, the point is I also have a Transaction logger which is supposed to send me emails
after a transaction has taken place (e.g. money has been transferred).  Every time a new IpnMessage
arrives from PayPal the code must use it to find a pre-saved Transaction object in the website
back-end database.  The transaction object contains details of what has been ordered and how
much should be paid.  The code checks the IpnMessage to make sure that the full amount has
been paid (matches the transaction), then the Transaction logger will log an INFO transaction
(and send me an email).  If the wrong amount has been paid, then the Transaction logger should
log an ERROR transaction (and send me an email).

Imagine if there was some error in the currency conversion which meant that *sometimes* the
wrong price got paid by the customer.  On top of that, there was a mistake in the code which
meant that the transaction errors were actually being sent to the wrong logger.

PayPalLogger.Error(myTransaction); // oops

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.


was (Author: benixix):
Maybe I miss-understood your documentation, which says:

"log4net is built on a number of different frameworks. Each new version of the frameworks
add new features. To take advantage of these new features we must build log4net using the
appropriate framework."

(http://logging.apache.org/log4net/release/framework-support.html)

I was suggesting an *addition* to the existing API that would take advantage of the Generics
feature in the newer frameworks.  So there would be no issue with backward compatibility right?
 However, maybe what is being described is only the internals of the log4net assemblies and
not the API (although you do have different appenders for different framework builds).  Perhaps
I didn't understand this right.  Sorry.

With regard to you asking about a usecase, I think the problem comes when you have more than
one logger declared in the same class and these loggers have different jobs.  I can describe
my situation, but I am still in the development phase of this project and so it is not live
yet.

I have an ASP website that is communicating with the PayPal (via IPN) and I would like to
log all communications.  I have designed my own helper class that encapsulates an IPN message,
lets call it IpnMessage.  After inspecting an incoming IpnMessage object I can decide if I
want to log it as INFO, WARN or ERROR.  This then gets logged to a special PayPal log file.
 Yea sure, I could write a special parser method to turn the IpnMessage object into a string
and then I could send that to the logger.  But isn't that what the Object Renderer is for?

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)); }

This will check the logger 2 times for IsWarnEnabled, however

PayPalLogger.Warn(myIpnMessage);

is cleaner code and will only use the Object Renderer after it has checked IsWarnEnabled just
once right?

Anyway, the point is I also have a Transaction logger which is supposed to send me emails
after a transaction has taken place (e.g. money has been transferred).  Every time a new IpnMessage
arrives from PayPal the code must use it to find a pre-saved Transaction object in the website
back-end database.  The transaction object contains details of what has been ordered and how
much should be paid.  The code checks the IpnMessage to make sure that the full amount has
been paid (matches the transaction), then the Transaction logger will log an INFO transaction
(and send me an email).  If the wrong amount has been paid, then the Transaction logger should
log an ERROR transaction (and send me an email).

Imagine if there was some error in the currency conversion which meant that *sometimes* the
wrong price got paid by the customer.  On top of that, there was a mistake in the code which
meant that the transaction errors were actually being sent to the wrong logger.

PayPalLogger.Error(myTransaction); // oops

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.

> 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)

Mime
View raw message