[
https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben updated LOG4NET-409:
------------------------
Description:
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.
was:
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 a run-time error. This would be much better and 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.
> 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)
