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