[
https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831547#comment-13831547
]
Ben edited comment on LOG4NET-409 at 11/25/13 3:51 PM:
-------------------------------------------------------
If your interested, I have put together a log4net.Generics assembly and a
console test app.
It seems to be working well, and it's completely separate from the rest of the
log4net code.
I can email you the zipped up solution if you want.
I really don't think it is a lot of code. The new interface has 8 methods (4
methods and 4 overloads), I am still confused why you think there should be
more than this? The only thing that is missing is the ability to create a new
generic logger using the LogManager (since I can't add static extension
methods). Would be nice to be able to do:
LogManager.GetLogger<T>(string name);
Instead I have implemented a public constructor:
ILog<T> myLogger = new GenericLogger<T>(string name);
But this is the only thing missing.
was (Author: benixix):
If your interested, I have put together a log4net.Generics assembly and a
console test app.
It seems to be working well, and it's completely separate from the rest of the
log4net code.
I can email you the zipped up solution if you want.
I really don't think it is a lot of code. The only thing that is missing is
the ability to create a new generic logger using the LogManager (since I can't
add static extension methods). Would be nice to be able to do:
LogManager.GetLogger<T>(string name);
Instead I have implemented a public constructor:
ILog<T> myLogger = new GenericLogger<T>(string name);
But this is the only thing missing.
> 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)
