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 12:33:35 GMT

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

Ben edited comment on LOG4NET-409 at 11/25/13 12:32 PM:
--------------------------------------------------------

Sorry Dominik, I do not agree with you.

To be quite honest I am feeling quite a bit of hostility in your comment Dominik.  Please,
this is just a suggestion - a wish from me.  I have taken the time to come here, to register
and log in, so that I can help to offer suggestions for the future of log4net.  I have taken
even more time to answer Stephan's question regarding a real-world example.  It would be nice
if you at least acknowledged that I am _trying_ to help, even if you don't want to implement
what I have suggested.  And please be kind in the way you give your criticism.

{quote}
But introducing generics increases the impact of logging logic in the codebase. On top it
pollutes the API with yet another thousands overloads ...
{quote}

This seems to me to be an exaggeration and I don't understand why there would be any impact
on the logging logic - it would work exactly the same as it did before.  The logic would be
the same.  (What do you mean by logging logic?).  As you pointed out, this could be implemented
using a simple wrapper, the logic underneath would be the same.

I don't think that it would *pollute* the API at all.  In fact I think it would _enhance_
it, hence the reason that I took the time to come here and suggest it.  Why do you expect
that there will be thousands of overloads?  I was suggesting only a new interface ILog<T>
and one new logger.  This interface could have as little as 2 methods on it.  So this is not
thousands of overloads.

If you really are worried about this polluting the API and contaminating the codebase, then
why not do a similar thing as the author of LOG4NET-290 suggests and implement this as an
extension method and put this code in a separate assembly?  I do not think it would be very
much code at all.  Perhaps I could have a look at doing this? (Although I am a fairly new
user of log4net).

{quote}
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.
{quote}

Not sure what this has to do with my problem - that I accidentally sent the wrong object to
the wrong logger.  Lambda expressions won't help here.

{quote}
There's no need to introduce a thousandfold of different loggers.
{quote}

I am not introducing a thousandfold of different loggers.  Why do you keep exaggerating? 
In my real-world example, I have 2 loggers.  Just 2.  What I am suggesting (as a _wish_, a
hopeful idea that maybe others might vote for) is that 1 new type of logger is provided. 
*Just one new logger* - not thousands.

{quote}
Think of the logging framework being a mixer.
{quote}

Why should I think of it like this?  Logging is done for many reasons, for development and
bug reporting but also for legal reasons and to keep important archives, to prove that messages
were sent, or not sent.  Why can't a logger also be used as a core part of a business website
(e.g. sending emails after a customer has paid to let the factory know to start building the
product)?  In this latter case, it becomes more important that mistakes are not made.

>From the log4net FAQ (http://logging.apache.org/log4net/release/faq.html):
{quote}
log4net is a tool to help the programmer output log statements to a variety of output targets.
... log4net is designed with two distinct goals in mind: speed and flexibility.
{quote}

It is designed to help the programmer output to a variety of targets, which is very useful
especially since logging is done for a variety of reasons.  log4net is very flexible! It can
do much more that just stick everything in a big mixing pot.

Look - At the end of the day, log4net is your project and you must run it the way you see
fit, so if you don't like this idea then that is fine.


was (Author: benixix):
Sorry Dominik, I do not agree with you.

To be quite honest I am feeling quite a bit of hostility in your comment Dominik.  Please,
this is just a suggestion - a wish from me.  I have taken the time to come here, to register
and log in, so that I can help to offer suggestions for the future of log4net.  I have taken
even more time to answer Stephan's question regarding a real-world example.  It would be nice
if you at least acknowledged that I am _trying_ to help, even if you don't want to implement
what I have suggested.  And please be kind in the way you give your criticism.

{quote}
But introducing generics increases the impact of logging logic in the codebase. On top it
pollutes the API with yet another thousands overloads ...
{quote}

This seems to me to be an exaggeration and I don't understand why there would be any impact
on the logging logic - it would work exactly the same as it did before.  The logic would be
the same.  (What do you mean by logging logic?).  As you pointed out, this could be implemented
using a simple wrapper, the logic underneath would be the same.

I don't think that it would *pollute* the API at all.  In fact I think it would _enhance_
it, hence the reason that I took the time to come here and suggest it.  Why do you expect
that there will be thousands of overloads?  I was suggesting only a new interface ILog<T>
and one new logger.  This interface could have as little as 2 methods on it.  So this is not
thousands of overloads.

If you really are worried about this polluting the API and contaminating the codebase, then
why not do a similar thing as the author of LOG4NET-290 suggests and implement this as an
extension method and put this code in a separate assembly?  I do not think it would be very
much code at all.  Perhaps I could have a look at doing this? (Although I am a fairly new
user of log4net).

{quote}
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.
{quote}

Not sure what this has to do with my problem - that I accidentally sent the wrong object to
the wrong logger.  Lambda expressions won't help here.

{quote}
There's no need to introduce a thousandfold of different loggers.
{quote}

I am not introducing a thousandfold of different loggers.  Why do you keep exaggerating? 
In my real-world example, I have 2 loggers.  Just 2.  What I am suggesting (as a _wish_, a
hopeful idea that maybe others might vote for) is that 1 new type of logger is provided. 
*Just one new logger* - not thousands.

{quote}
Think of the logging framework being a mixer.
{quote}

Why should I think of it like this?  Logging is done for many reasons, for development and
bug reporting but also for legal reasons and to keep important archives, to prove that messages
were sent, or not sent.  Why can't a logger also be used as a core part of a business website
(e.g. sending emails after a customer has paid to let the factory know to start building the
product)?  In this latter case, it becomes more important that mistakes are not made.

>From the log4net FAQ (http://logging.apache.org/log4net/release/faq.html):
{quote}
log4net is a tool to help the programmer output log statements to a variety of output targets.
... log4net is designed with two distinct goals in mind: speed and flexibility.
{quote}

It is designed to help the programmer output to a variety of targets, which is very useful
especially since logging is done for a variety of reasons.  log4net is very flexible! It can
do much more that just stick everything in a big mixing pot.

At the end of the day, log4net is your project and you must run it the way you see fit, so
if you don't like this idea then that is fine.  I must accept that.

> 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