{quote}
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?
{/quote}
As far as I understand an ObjectRenderer is used when the default
ToString() implementation is not good enough as a log message. This means
that the ObjectRenderer is not responsible for the level of the log message
which was set when the log method was invoked. I think you can look at it
as a way to provide a custom ToString method. Nothing else. So if that's
what you need then yes, thats what the ObjectRenderer is for.
{quote}
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.
{/qupte}
Sounds like you are using log4net to implement business rules and that's a
bad idea. Yes, log4net is reliable but its still wrong to implement
business rules with your logging framework.
The reason I think that log4net shouldn't have generics in the way you
suggest is because usually when someone logs they are logging strings. and
if they want to log an object in a special way they can override its
ToString method or create an ObjectRenderer.
If you are dividing your loggers by the classes they log and they are data
object with no logic to put the logger into then you can solve it easily
with a few extension methods to the ILog interface.
On Mon, Nov 25, 2013 at 5:55 PM, Ben (JIRA) <j...@apache.org> wrote:
>
> [
> 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:54 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 (I can only see 2 overloads on the Info() method for a
> normal logger - not sure why you are saying there are 10)?
>
> 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 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.
>
>
>
> > 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)
>
