[jira] [Commented] (LOG4NET-409) Generics added to the Logger
[
https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13832616#comment-13832616
]
Ben commented on LOG4NET-409:
-
I can see that no one is liking this idea, but I do still think it is important.
{quote}
... on the other hand we would gain the benefit of type safe parameters inside
the log4bet code.
{quote}
What about my code Michael? As a user of log4net, why can't I have type safety
too, or do you not care about me? When I explained my real-world example where
I lost a customer because I didn't get a critical Error log message, is this
not important to you? Is this not a valid reason? I don't want to loose
customers - they are the most important thing in my business.
To be quite honest I think that any method that accepts an object type as a
parameter is dangerous. Because anything can be passed to it - any crap - and
there is no error, no exception thrown, nothing to suggest anything is wrong.
The Console.WriteLine method is also dangerous. Any method that accepts a
parameter of type object has a code smell and rings alarm bells. One of the
biggest benefits of Generics was to fix exactly this problem.
Benefits of Generics
http://msdn.microsoft.com/en-us/library/vstudio/b5bx6xee.aspx
{quote}
Generics provide the solution to a limitation in earlier versions of the common
language runtime and the C# language in which generalization is accomplished by
casting types to and from the universal base type Object. By creating a generic
class, you can create a collection that is type-safe at compile-time.
{quote}
The *only* time that object should be used as a type is when you are dealing
with earlier versions of the CLR *and* you are dealing with objects that are so
diverse that you can't provide the user with an interface. To use, object just
because it has a useful ToString() method is just lazy.
To be quite blunt guys, your log4net logger methods smell bad.
Sure, perhaps most people don't care, and perhaps most people will just send
strings and exceptions to their loggers. Maybe I am using log4net in a very
eccentric way and so maybe I am a one-off special case that you don't need to
worry about. These are good arguments for not implementing this and just
leaving the API as it is. But please don't say that my reasoning is bad -
because it is not. There would be a very good reason for introducing Generics
to the logger API - because it would provide your users with type-safety in
_their_ code (which may be in very different ways - flexibility is an important
log4net feature right?).
I can accept that I am a one-off special case, so no worries, I have already
created my work-around and implemented something similar to Dominik's wrapper
suggestion (thanks by the way). As I said already, it works as a separate
add-on assembly and so the code is separate from the main log4net dll. As an
add-on, I still get to use the normal loggers which is great, but now I can
also use special generic loggers when I want type-safety. The API for the
generic logger and the normal logger is not mixed up and so it is kept separate
and clean from each other. It might be worth at least having a look at?
Perhaps there might be other users out there who might also like to use this
code?
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 ILogOrange myOrangeLogger =
LogManager.GetLoggerOrange(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.GetLoggerT(string name)
would return a logger of type ILogT.
The ILogT interface would have methods on it like:
ILogT.Warn(string message);
ILogT.Warn(T message);
ILogT.Warn(string message, Exception ex);
ILogT.Warn(T message, Exception ex);
but would NOT have the method:
ILogT.Warn(object message);
So now if I tried to pass it an Apple object I would get a compile error
rather than the default
[jira] [Comment Edited] (LOG4NET-409) Generics added to the Logger
[
https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13832616#comment-13832616
]
Ben edited comment on LOG4NET-409 at 11/26/13 2:28 PM:
---
I can see that no one is liking this idea, but I do still think it is important.
{quote}
... on the other hand we would gain the benefit of type safe parameters inside
the log4net code.
{quote}
What about my code Michael? As a user of log4net, why can't I have type safety
too, or do you not care about me? When I explained my real-world example where
I lost a customer because I didn't get a critical Error log message, is this
not important to you? Is this not a valid reason? I don't want to loose
customers - they are the most important thing in my business.
To be quite honest I think that any method that accepts an object type as a
parameter is dangerous. Because anything can be passed to it - any crap - and
there is no error, no exception thrown, nothing to suggest anything is wrong.
The Console.WriteLine method is also dangerous. Any method that accepts a
parameter of type object has a code smell and rings alarm bells. One of the
biggest benefits of Generics was to fix exactly this problem.
Benefits of Generics
http://msdn.microsoft.com/en-us/library/vstudio/b5bx6xee.aspx
{quote}
Generics provide the solution to a limitation in earlier versions of the common
language runtime and the C# language in which generalization is accomplished by
casting types to and from the universal base type Object. By creating a generic
class, you can create a collection that is type-safe at compile-time.
{quote}
The *only* time that object should be used as a type is when you are dealing
with earlier versions of the CLR *and* you are dealing with objects that are so
diverse that you can't provide the user with an interface. To use, object just
because it has a useful ToString() method is just lazy.
To be quite blunt guys, your log4net logger methods smell bad.
Sure, perhaps most people don't care, and perhaps most people will just send
strings and exceptions to their loggers. Maybe I am using log4net in a very
eccentric way and so maybe I am a one-off special case that you don't need to
worry about. These are good arguments for not implementing this and just
leaving the API as it is. But please don't say that my reasoning is bad -
because it is not. There would be a very good reason for introducing Generics
to the logger API - because it would provide your users with type-safety in
_their_ code (which may vary a lot from user to user - flexibility is an
important log4net feature right?).
I can accept that I am a one-off special case, so no worries, I have already
created my work-around and implemented something similar to Dominik's wrapper
suggestion (thanks by the way). As I said already, it works as a separate
add-on assembly and so the code is separate from the main log4net dll. As an
add-on, I still get to use the normal loggers which is great, but now I can
also use special generic loggers when I want type-safety. The API for the
generic logger and the normal logger is not mixed up and so it is kept separate
and clean from each other. It might be worth at least having a look at?
Perhaps there might be other users out there who might also like to use this
code?
was (Author: benixix):
I can see that no one is liking this idea, but I do still think it is important.
{quote}
... on the other hand we would gain the benefit of type safe parameters inside
the log4net code.
{quote}
What about my code Michael? As a user of log4net, why can't I have type safety
too, or do you not care about me? When I explained my real-world example where
I lost a customer because I didn't get a critical Error log message, is this
not important to you? Is this not a valid reason? I don't want to loose
customers - they are the most important thing in my business.
To be quite honest I think that any method that accepts an object type as a
parameter is dangerous. Because anything can be passed to it - any crap - and
there is no error, no exception thrown, nothing to suggest anything is wrong.
The Console.WriteLine method is also dangerous. Any method that accepts a
parameter of type object has a code smell and rings alarm bells. One of the
biggest benefits of Generics was to fix exactly this problem.
Benefits of Generics
http://msdn.microsoft.com/en-us/library/vstudio/b5bx6xee.aspx
{quote}
Generics provide the solution to a limitation in earlier versions of the common
language runtime and the C# language in which generalization is accomplished by
casting types to and from the universal base type Object. By creating a generic
class, you can create a collection that is type-safe at compile-time.
{quote}
The *only* time that object should be used as a type is when you are dealing
with
[jira] [Issue Comment Deleted] (LOG4NET-409) Generics added to the Logger
[ https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben updated LOG4NET-409: Comment: was deleted (was: This is just a quick example, not completely finished. (VS2010 solution).) 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 Attachments: log4net.Generics Library.zip 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 ILogOrange myOrangeLogger = LogManager.GetLoggerOrange(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.GetLoggerT(string name) would return a logger of type ILogT. The ILogT interface would have methods on it like: ILogT.Warn(string message); ILogT.Warn(T message); ILogT.Warn(string message, Exception ex); ILogT.Warn(T message, Exception ex); but would NOT have the method: ILogT.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)
[jira] [Updated] (LOG4NET-409) Generics added to the Logger
[ https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben updated LOG4NET-409: Attachment: log4net.Generics Library.zip This is just a quick example, not completely finished. (VS2010 solution). 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 Attachments: log4net.Generics Library.zip 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 ILogOrange myOrangeLogger = LogManager.GetLoggerOrange(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.GetLoggerT(string name) would return a logger of type ILogT. The ILogT interface would have methods on it like: ILogT.Warn(string message); ILogT.Warn(T message); ILogT.Warn(string message, Exception ex); ILogT.Warn(T message, Exception ex); but would NOT have the method: ILogT.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)
[jira] [Commented] (LOG4NET-409) Generics added to the Logger
[ https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13832671#comment-13832671 ] Ben commented on LOG4NET-409: - Yes your English is good enough and you make a good point. 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 Attachments: log4net.Generics Library.zip 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 ILogOrange myOrangeLogger = LogManager.GetLoggerOrange(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.GetLoggerT(string name) would return a logger of type ILogT. The ILogT interface would have methods on it like: ILogT.Warn(string message); ILogT.Warn(T message); ILogT.Warn(string message, Exception ex); ILogT.Warn(T message, Exception ex); but would NOT have the method: ILogT.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)
[jira] [Commented] (LOG4NET-409) Generics added to the Logger
[
https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831413#comment-13831413
]
Ben commented on LOG4NET-409:
-
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 ILogT 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
[jira] [Comment Edited] (LOG4NET-409) Generics added to the Logger
[
https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 ILogT 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
[jira] [Commented] (LOG4NET-409) Generics added to the Logger
[ https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831547#comment-13831547 ] Ben commented on LOG4NET-409: - If your interested, I have put together a log4net.Generics assembly and a console test app. It seems to be working well. I can email you the zipped up solution if you want. 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 ILogOrange myOrangeLogger = LogManager.GetLoggerOrange(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.GetLoggerT(string name) would return a logger of type ILogT. The ILogT interface would have methods on it like: ILogT.Warn(string message); ILogT.Warn(T message); ILogT.Warn(string message, Exception ex); ILogT.Warn(T message, Exception ex); but would NOT have the method: ILogT.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)
[jira] [Comment Edited] (LOG4NET-409) Generics added to the Logger
[ https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831547#comment-13831547 ] Ben edited comment on LOG4NET-409 at 11/25/13 3:35 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 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.GetLoggerT(string name); Instead I have just implemented a public constructor: ILogT myLogger = new GenericLoggerT(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. I can email you the zipped up solution if you want. 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 ILogOrange myOrangeLogger = LogManager.GetLoggerOrange(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.GetLoggerT(string name) would return a logger of type ILogT. The ILogT interface would have methods on it like: ILogT.Warn(string message); ILogT.Warn(T message); ILogT.Warn(string message, Exception ex); ILogT.Warn(T message, Exception ex); but would NOT have the method: ILogT.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)
[jira] [Comment Edited] (LOG4NET-409) Generics added to the Logger
[ https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831547#comment-13831547 ] Ben edited comment on LOG4NET-409 at 11/25/13 3:36 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 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.GetLoggerT(string name); Instead I have implemented a public constructor: ILogT myLogger = new GenericLoggerT(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.GetLoggerT(string name); Instead I have just implemented a public constructor: ILogT myLogger = new GenericLoggerT(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 ILogOrange myOrangeLogger = LogManager.GetLoggerOrange(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.GetLoggerT(string name) would return a logger of type ILogT. The ILogT interface would have methods on it like: ILogT.Warn(string message); ILogT.Warn(T message); ILogT.Warn(string message, Exception ex); ILogT.Warn(T message, Exception ex); but would NOT have the method: ILogT.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)
[jira] [Comment Edited] (LOG4NET-409) Generics added to the Logger
[ https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.GetLoggerT(string name); Instead I have implemented a public constructor: ILogT myLogger = new GenericLoggerT(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.GetLoggerT(string name); Instead I have implemented a public constructor: ILogT myLogger = new GenericLoggerT(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 ILogOrange myOrangeLogger = LogManager.GetLoggerOrange(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.GetLoggerT(string name) would return a logger of type ILogT. The ILogT interface would have methods on it like: ILogT.Warn(string message); ILogT.Warn(T message); ILogT.Warn(string message, Exception ex); ILogT.Warn(T message, Exception ex); but would NOT have the method: ILogT.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)
[jira] [Comment Edited] (LOG4NET-409) Generics added to the Logger
[ https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.GetLoggerT(string name); Instead I have implemented a public constructor: ILogT myLogger = new GenericLoggerT(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.GetLoggerT(string name); Instead I have implemented a public constructor: ILogT myLogger = new GenericLoggerT(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 ILogOrange myOrangeLogger = LogManager.GetLoggerOrange(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.GetLoggerT(string name) would return a logger of type ILogT. The ILogT interface would have methods on it like: ILogT.Warn(string message); ILogT.Warn(T message); ILogT.Warn(string message, Exception ex); ILogT.Warn(T message, Exception ex); but would NOT have the method: ILogT.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)
[jira] [Commented] (LOG4NET-406) Log4Net breaks the Microsoft naming rules for namespaces
[ https://issues.apache.org/jira/browse/LOG4NET-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13830995#comment-13830995 ] Ben commented on LOG4NET-406: - Yes, I understand that this is an API breaking change and yes Jonathan's comments about this being a guidance and not a hard-and-fast rule are also valid. However I do not agree that there is only negative value in this proposal. I am fairly new to log4net, and when I stated using it and found that the using directive was all lower case letters, I found this slightly confusing and disconcerting (did I install the right version; am I using a test version; did I mess something up). I would have considered a renaming of the namespace an important part of the port from log4j to .NET. If you are going to port to .NET then you should be taking the .NET Framework Guidelines seriously, which you probably are, but for your brand new users who aren't familiar with the 10 year namespace history, the lowercase using directive make log4net look like it has been built by amateurs and introduces uncertainty and worry. This was my experience. So I do not think that this proposal has only negative value. I would also like to point out that during a migration to a newer version there is a Find and Replace tool within Visual Studio that can be set to scan the entire Solution. It could be used to replace using log4net to using Log4Net and this would be fairly painless and quick. So its not necessarily an entirely manual operation. While I do not expect everyone to agree with me, I don't think I am the only one to feel this way and I do hope that my opinion is a valuable contribution to this debate. Log4Net breaks the Microsoft naming rules for namespaces Key: LOG4NET-406 URL: https://issues.apache.org/jira/browse/LOG4NET-406 Project: Log4net Issue Type: Improvement Components: Appenders, Core Affects Versions: 1.2.9, 1.2.10, 1.2.11, 1.2.12, 1.2.13, 1.3.0, 1.2 Maintenance Release, 3.5, 4.0 Environment: Windows 7, .Net 4.0 Reporter: Michael Goldfinger Priority: Trivial Fix For: 1.3.0 The log4net namespace violates the naming convention for namespaces in .Net. http://msdn.microsoft.com/en-us/library/vstudio/ms229026(v=vs.100).aspx As stated Pacal casing should be used: Do use Pascal casing, and separate namespace components with periods (for example, Microsoft.Office.PowerPoint) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (LOG4NET-409) Generics added to the Logger
Ben created LOG4NET-409: --- Summary: 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 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 myOrangeLogger = LogManager.GetLoggerOrange(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.GetLoggerT(string name) would return a logger of type ILogT. The ILogT interface would have methods on it like: ILogT.Warn(string message); ILogT.Warn(T message); ILogT.Warn(string message, Exception ex); ILogT.Warn(T message, Exception ex); but would NOT have the method: ILogT.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. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LOG4NET-409) Generics added to the Logger
[ 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 ILogOrange myOrangeLogger = LogManager.GetLoggerOrange(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.GetLoggerT(string name) would return a logger of type ILogT. The ILogT interface would have methods on it like: ILogT.Warn(string message); ILogT.Warn(T message); ILogT.Warn(string message, Exception ex); ILogT.Warn(T message, Exception ex); but would NOT have the method: ILogT.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. 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 myOrangeLogger = LogManager.GetLoggerOrange(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.GetLoggerT(string name) would return a logger of type ILogT. The ILogT interface would have methods on it like: ILogT.Warn(string message); ILogT.Warn(T message); ILogT.Warn(string message, Exception ex); ILogT.Warn(T message, Exception ex); but would NOT have the method: ILogT.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 ILogOrange myOrangeLogger = LogManager.GetLoggerOrange(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.GetLoggerT(string name) would return a logger of type ILogT. The ILogT interface would have methods on it like: ILogT.Warn(string message); ILogT.Warn(T message); ILogT.Warn(string message, Exception ex); ILogT.Warn(T message, Exception ex); but would NOT have the method: ILogT.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
[jira] [Updated] (LOG4NET-409) Generics added to the Logger
[ 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 ILogOrange myOrangeLogger = LogManager.GetLoggerOrange(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.GetLoggerT(string name) would return a logger of type ILogT. The ILogT interface would have methods on it like: ILogT.Warn(string message); ILogT.Warn(T message); ILogT.Warn(string message, Exception ex); ILogT.Warn(T message, Exception ex); but would NOT have the method: ILogT.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 ILogOrange myOrangeLogger = LogManager.GetLoggerOrange(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.GetLoggerT(string name) would return a logger of type ILogT. The ILogT interface would have methods on it like: ILogT.Warn(string message); ILogT.Warn(T message); ILogT.Warn(string message, Exception ex); ILogT.Warn(T message, Exception ex); but would NOT have the method: ILogT.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 ILogOrange myOrangeLogger = LogManager.GetLoggerOrange(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.GetLoggerT(string name) would return a logger of type ILogT. The ILogT interface would have methods on it like: ILogT.Warn(string message); ILogT.Warn(T message); ILogT.Warn(string message, Exception ex); ILogT.Warn(T message, Exception ex); but would NOT have the
[jira] [Commented] (LOG4NET-409) Generics added to the Logger
[
https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831119#comment-13831119
]
Ben commented on LOG4NET-409:
-
Maybe I miss-understood your documentation, which says:
log4net is built on a number of different frameworks. Each new version of the
frameworks add new features. To take advantage of these new features we must
build log4net using the appropriate framework.
(http://logging.apache.org/log4net/release/framework-support.html)
I was suggesting an **addition** to the existing API that would take advantage
of the Generics feature in the newer frameworks. So there would be no issue
with backward compatibility right? However, maybe what is being described is
only the internals of the log4net assemblies and not the API (although you do
have different appenders for different framework builds). Perhaps I didn't
understand this right. Sorry.
With regard to you asking about a usecase, I think the problem comes when you
have more than one logger declared in the same class and these loggers have
different jobs. I can describe my situation, but I am still in the development
phase of this project and so it is not live yet.
I have an ASP website that is communicating with the PayPal (via IPN) and I
would like to log all communications. I have designed my own helper class that
encapsulates an IPN message, lets call it IpnMessage. After inspecting an
incoming IpnMessage object I can decide if I want to log it as INFO, WARN or
ERROR. This then gets logged to a special PayPal log file. 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?
It is no doubt negligible but, I also wonder if the Object Renderer might help
with efficiency in some tiny way? For example:
if(PayPalLogger.IsWarnEnabled) {
PayPalLogger.Warn(myParserMethod(myIpnMessage)); }
This will check the logger 2 times for IsWarnEnabled, however
PayPalLogger.Warn(myIpnMessage);
is cleaner code and will only use the Object Renderer after it has checked
IsWarnEnabled just once right?
Anyway, the point is I also have a Transaction logger which is supposed to send
me emails after a transaction has taken place (e.g. money has been
transferred). Every time a new IpnMessage arrives from PayPal the code must
use it to find a pre-saved Transaction object in the website back-end database.
The transaction object contains details of what has been ordered and how much
should be paid. The code checks the IpnMessage to make sure that the full
amount has been paid (matches the transaction), then the Transaction logger
will log an INFO transaction (and send me an email). If the wrong amount has
been paid, then the Transaction logger should log an ERROR transaction (and
send me an email).
Imagine if there was some error in the currency conversion which meant that
sometimes the wrong price got paid by the customer. On top of that, there was
a mistake in the code which meant that the transaction errors were actually
being sent to the wrong logger.
PayPalLogger.Error(myTransaction); // oops
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.
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 ILogOrange myOrangeLogger =
LogManager.GetLoggerOrange(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.GetLoggerT(string name)
would return a logger of type ILogT.
The ILogT interface would have methods on it like:
ILogT.Warn(string message);
ILogT.Warn(T message);
ILogT.Warn(string message, Exception ex);
ILogT.Warn(T message, Exception ex);
but would NOT have the method:
ILogT.Warn(object message);
So now if I tried
[jira] [Comment Edited] (LOG4NET-409) Generics added to the Logger
[
https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831119#comment-13831119
]
Ben edited comment on LOG4NET-409 at 11/25/13 12:33 AM:
Maybe I miss-understood your documentation, which says:
log4net is built on a number of different frameworks. Each new version of the
frameworks add new features. To take advantage of these new features we must
build log4net using the appropriate framework.
(http://logging.apache.org/log4net/release/framework-support.html)
I was suggesting an *addition* to the existing API that would take advantage of
the Generics feature in the newer frameworks. So there would be no issue with
backward compatibility right? However, maybe what is being described is only
the internals of the log4net assemblies and not the API (although you do have
different appenders for different framework builds). Perhaps I didn't
understand this right. Sorry.
With regard to you asking about a usecase, I think the problem comes when you
have more than one logger declared in the same class and these loggers have
different jobs. I can describe my situation, but I am still in the development
phase of this project and so it is not live yet.
I have an ASP website that is communicating with the PayPal (via IPN) and I
would like to log all communications. I have designed my own helper class that
encapsulates an IPN message, lets call it IpnMessage. After inspecting an
incoming IpnMessage object I can decide if I want to log it as INFO, WARN or
ERROR. This then gets logged to a special PayPal log file. 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?
It is no doubt negligible but, I also wonder if the Object Renderer might help
with efficiency in some tiny way? For example:
if(PayPalLogger.IsWarnEnabled) {
PayPalLogger.Warn(myParserMethod(myIpnMessage)); }
This will check the logger 2 times for IsWarnEnabled, however
PayPalLogger.Warn(myIpnMessage);
is cleaner code and will only use the Object Renderer after it has checked
IsWarnEnabled just once right?
Anyway, the point is I also have a Transaction logger which is supposed to send
me emails after a transaction has taken place (e.g. money has been
transferred). Every time a new IpnMessage arrives from PayPal the code must
use it to find a pre-saved Transaction object in the website back-end database.
The transaction object contains details of what has been ordered and how much
should be paid. The code checks the IpnMessage to make sure that the full
amount has been paid (matches the transaction), then the Transaction logger
will log an INFO transaction (and send me an email). If the wrong amount has
been paid, then the Transaction logger should log an ERROR transaction (and
send me an email).
Imagine if there was some error in the currency conversion which meant that
*sometimes* the wrong price got paid by the customer. On top of that, there
was a mistake in the code which meant that the transaction errors were actually
being sent to the wrong logger.
PayPalLogger.Error(myTransaction); // oops
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.
was (Author: benixix):
Maybe I miss-understood your documentation, which says:
log4net is built on a number of different frameworks. Each new version of the
frameworks add new features. To take advantage of these new features we must
build log4net using the appropriate framework.
(http://logging.apache.org/log4net/release/framework-support.html)
I was suggesting an **addition** to the existing API that would take advantage
of the Generics feature in the newer frameworks. So there would be no issue
with backward compatibility right? However, maybe what is being described is
only the internals of the log4net assemblies and not the API (although you do
have different appenders for different framework builds). Perhaps I didn't
understand this right. Sorry.
With regard to you asking about a usecase, I think the problem comes when you
have more than one logger declared in the same class and these loggers have
different jobs. I can describe my situation, but I am still in the development
phase of this project and so it is not live yet.
I have an ASP website that is communicating with the PayPal (via IPN) and I
would like to log all communications. I have designed my own helper class that
encapsulates an IPN message, lets call it IpnMessage. After inspecting an
incoming IpnMessage object I can decide if I want to log it as INFO, WARN or
ERROR. This then gets logged to a special PayPal log file. Yea sure, I could
write a
[jira] [Comment Edited] (LOG4NET-409) Generics added to the Logger
[
https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831119#comment-13831119
]
Ben edited comment on LOG4NET-409 at 11/25/13 12:35 AM:
Maybe I miss-understood your documentation, which says:
log4net is built on a number of different frameworks. Each new version of the
frameworks add new features. To take advantage of these new features we must
build log4net using the appropriate framework.
(http://logging.apache.org/log4net/release/framework-support.html)
I was suggesting an *addition* to the existing API that would take advantage of
the Generics feature in the newer frameworks. So there would be no issue with
backward compatibility right? However, maybe what is being described is only
the internals of the log4net assemblies and not the API (although you do have
different appenders for different framework builds). Perhaps I didn't
understand this right. Sorry.
With regard to you asking about a usecase, I think the problem comes when you
have more than one logger declared in the same class and these loggers have
different jobs. I can describe my situation, but I am still in the development
phase of this project and so we still have some work to do on it.
I have an ASP website that is communicating with PayPal IPN and I would like to
log all communications. I have designed my own helper class that encapsulates
an IPN message, lets call it IpnMessage. After inspecting an incoming
IpnMessage object I can decide if I want to log it as INFO, WARN or ERROR.
This then gets logged to a special PayPal log file. 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?
It is no doubt negligible but, I also wonder if the Object Renderer might help
with efficiency in some tiny way? For example:
if(PayPalLogger.IsWarnEnabled) {
PayPalLogger.Warn(myParserMethod(myIpnMessage)); }
This will check the logger 2 times for IsWarnEnabled, however
PayPalLogger.Warn(myIpnMessage);
is cleaner code and will only use the Object Renderer after it has checked
IsWarnEnabled just once right?
Anyway, the point is I also have a Transaction logger which is supposed to send
me emails after a transaction has taken place (e.g. money has been
transferred). Every time a new IpnMessage arrives from PayPal the code must
use it to find a pre-saved Transaction object in the website back-end database.
The transaction object contains details of what has been ordered and how much
should be paid. The code checks the IpnMessage to make sure that the full
amount has been paid (matches the transaction), then the Transaction logger
will log an INFO transaction (and send me an email). If the wrong amount has
been paid, then the Transaction logger should log an ERROR transaction (and
send me an email).
Imagine if there was some error in the currency conversion which meant that
*sometimes* the wrong price got paid by the customer. On top of that, there
was a mistake in the code which meant that the transaction errors were actually
being sent to the wrong logger.
PayPalLogger.Error(myTransaction); // oops
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.
was (Author: benixix):
Maybe I miss-understood your documentation, which says:
log4net is built on a number of different frameworks. Each new version of the
frameworks add new features. To take advantage of these new features we must
build log4net using the appropriate framework.
(http://logging.apache.org/log4net/release/framework-support.html)
I was suggesting an *addition* to the existing API that would take advantage of
the Generics feature in the newer frameworks. So there would be no issue with
backward compatibility right? However, maybe what is being described is only
the internals of the log4net assemblies and not the API (although you do have
different appenders for different framework builds). Perhaps I didn't
understand this right. Sorry.
With regard to you asking about a usecase, I think the problem comes when you
have more than one logger declared in the same class and these loggers have
different jobs. I can describe my situation, but I am still in the development
phase of this project and so we still have some work to do on it.
I have an ASP website that is communicating with the PayPal (via IPN) and I
would like to log all communications. I have designed my own helper class that
encapsulates an IPN message, lets call it IpnMessage. After inspecting an
incoming IpnMessage object I can decide if I want to log it as INFO, WARN or
ERROR. This then gets logged to a special PayPal log file. Yea
[jira] [Comment Edited] (LOG4NET-409) Generics added to the Logger
[
https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831119#comment-13831119
]
Ben edited comment on LOG4NET-409 at 11/25/13 12:34 AM:
Maybe I miss-understood your documentation, which says:
log4net is built on a number of different frameworks. Each new version of the
frameworks add new features. To take advantage of these new features we must
build log4net using the appropriate framework.
(http://logging.apache.org/log4net/release/framework-support.html)
I was suggesting an *addition* to the existing API that would take advantage of
the Generics feature in the newer frameworks. So there would be no issue with
backward compatibility right? However, maybe what is being described is only
the internals of the log4net assemblies and not the API (although you do have
different appenders for different framework builds). Perhaps I didn't
understand this right. Sorry.
With regard to you asking about a usecase, I think the problem comes when you
have more than one logger declared in the same class and these loggers have
different jobs. I can describe my situation, but I am still in the development
phase of this project and so we still have some work to do on it.
I have an ASP website that is communicating with the PayPal (via IPN) and I
would like to log all communications. I have designed my own helper class that
encapsulates an IPN message, lets call it IpnMessage. After inspecting an
incoming IpnMessage object I can decide if I want to log it as INFO, WARN or
ERROR. This then gets logged to a special PayPal log file. 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?
It is no doubt negligible but, I also wonder if the Object Renderer might help
with efficiency in some tiny way? For example:
if(PayPalLogger.IsWarnEnabled) {
PayPalLogger.Warn(myParserMethod(myIpnMessage)); }
This will check the logger 2 times for IsWarnEnabled, however
PayPalLogger.Warn(myIpnMessage);
is cleaner code and will only use the Object Renderer after it has checked
IsWarnEnabled just once right?
Anyway, the point is I also have a Transaction logger which is supposed to send
me emails after a transaction has taken place (e.g. money has been
transferred). Every time a new IpnMessage arrives from PayPal the code must
use it to find a pre-saved Transaction object in the website back-end database.
The transaction object contains details of what has been ordered and how much
should be paid. The code checks the IpnMessage to make sure that the full
amount has been paid (matches the transaction), then the Transaction logger
will log an INFO transaction (and send me an email). If the wrong amount has
been paid, then the Transaction logger should log an ERROR transaction (and
send me an email).
Imagine if there was some error in the currency conversion which meant that
*sometimes* the wrong price got paid by the customer. On top of that, there
was a mistake in the code which meant that the transaction errors were actually
being sent to the wrong logger.
PayPalLogger.Error(myTransaction); // oops
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.
was (Author: benixix):
Maybe I miss-understood your documentation, which says:
log4net is built on a number of different frameworks. Each new version of the
frameworks add new features. To take advantage of these new features we must
build log4net using the appropriate framework.
(http://logging.apache.org/log4net/release/framework-support.html)
I was suggesting an *addition* to the existing API that would take advantage of
the Generics feature in the newer frameworks. So there would be no issue with
backward compatibility right? However, maybe what is being described is only
the internals of the log4net assemblies and not the API (although you do have
different appenders for different framework builds). Perhaps I didn't
understand this right. Sorry.
With regard to you asking about a usecase, I think the problem comes when you
have more than one logger declared in the same class and these loggers have
different jobs. I can describe my situation, but I am still in the development
phase of this project and so it is not live yet.
I have an ASP website that is communicating with the PayPal (via IPN) and I
would like to log all communications. I have designed my own helper class that
encapsulates an IPN message, lets call it IpnMessage. After inspecting an
incoming IpnMessage object I can decide if I want to log it as INFO, WARN or
ERROR. This then gets logged to a special PayPal log file. Yea sure, I
[jira] [Comment Edited] (LOG4NET-409) Generics added to the Logger
[
https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831119#comment-13831119
]
Ben edited comment on LOG4NET-409 at 11/25/13 12:35 AM:
Maybe I miss-understood your documentation, which says:
log4net is built on a number of different frameworks. Each new version of the
frameworks add new features. To take advantage of these new features we must
build log4net using the appropriate framework.
(http://logging.apache.org/log4net/release/framework-support.html)
I was suggesting an *addition* to the existing API that would take advantage of
the Generics feature in the newer frameworks. So there would be no issue with
backward compatibility right? However, maybe what is being described is only
the internals of the log4net assemblies and not the API (although you do have
different appenders for different framework builds). Perhaps I didn't
understand this right. Sorry.
With regard to you asking about a usecase, I think the problem comes when you
have more than one logger declared in the same class and these loggers have
different jobs. I can describe my situation, but I am still in the development
phase of this project and so we still have some work to do on it.
I have an ASP.NET website that is communicating with PayPal IPN and I would
like to log all communications. I have designed my own helper class that
encapsulates an IPN message, lets call it IpnMessage. After inspecting an
incoming IpnMessage object I can decide if I want to log it as INFO, WARN or
ERROR. This then gets logged to a special PayPal log file. 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?
It is no doubt negligible but, I also wonder if the Object Renderer might help
with efficiency in some tiny way? For example:
if(PayPalLogger.IsWarnEnabled) {
PayPalLogger.Warn(myParserMethod(myIpnMessage)); }
This will check the logger 2 times for IsWarnEnabled, however
PayPalLogger.Warn(myIpnMessage);
is cleaner code and will only use the Object Renderer after it has checked
IsWarnEnabled just once right?
Anyway, the point is I also have a Transaction logger which is supposed to send
me emails after a transaction has taken place (e.g. money has been
transferred). Every time a new IpnMessage arrives from PayPal the code must
use it to find a pre-saved Transaction object in the website back-end database.
The transaction object contains details of what has been ordered and how much
should be paid. The code checks the IpnMessage to make sure that the full
amount has been paid (matches the transaction), then the Transaction logger
will log an INFO transaction (and send me an email). If the wrong amount has
been paid, then the Transaction logger should log an ERROR transaction (and
send me an email).
Imagine if there was some error in the currency conversion which meant that
*sometimes* the wrong price got paid by the customer. On top of that, there
was a mistake in the code which meant that the transaction errors were actually
being sent to the wrong logger.
PayPalLogger.Error(myTransaction); // oops
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.
was (Author: benixix):
Maybe I miss-understood your documentation, which says:
log4net is built on a number of different frameworks. Each new version of the
frameworks add new features. To take advantage of these new features we must
build log4net using the appropriate framework.
(http://logging.apache.org/log4net/release/framework-support.html)
I was suggesting an *addition* to the existing API that would take advantage of
the Generics feature in the newer frameworks. So there would be no issue with
backward compatibility right? However, maybe what is being described is only
the internals of the log4net assemblies and not the API (although you do have
different appenders for different framework builds). Perhaps I didn't
understand this right. Sorry.
With regard to you asking about a usecase, I think the problem comes when you
have more than one logger declared in the same class and these loggers have
different jobs. I can describe my situation, but I am still in the development
phase of this project and so we still have some work to do on it.
I have an ASP website that is communicating with PayPal IPN and I would like to
log all communications. I have designed my own helper class that encapsulates
an IPN message, lets call it IpnMessage. After inspecting an incoming
IpnMessage object I can decide if I want to log it as INFO, WARN or ERROR.
This then gets logged to a special PayPal log file. Yea sure, I
[jira] [Comment Edited] (LOG4NET-409) Generics added to the Logger
[
https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831119#comment-13831119
]
Ben edited comment on LOG4NET-409 at 11/25/13 12:39 AM:
Maybe I miss-understood your documentation, which says:
log4net is built on a number of different frameworks. Each new version of the
frameworks add new features. To take advantage of these new features we must
build log4net using the appropriate framework.
(http://logging.apache.org/log4net/release/framework-support.html)
I was suggesting an *addition* to the existing API that would take advantage of
the Generics feature in the newer frameworks. So there would be no issue with
backward compatibility right? However, maybe what is being described is only
the internals of the log4net assemblies and not the API (although you do have
different appenders for different framework builds). Perhaps I didn't
understand this right. Sorry.
With regard to you asking about a usecase, I think the problem comes when you
have more than one logger declared in the same class and these loggers have
different jobs. I can describe my situation, but I am still in the development
phase of this project and so we still have some work to do on it.
I have an ASP.NET website that is communicating with PayPal IPN and I would
like to log all communications. I have designed my own helper class that
encapsulates an IPN message, lets call it IpnMessage. After inspecting an
incoming IpnMessage object I can decide if I want to log it as INFO, WARN or
ERROR. This then gets logged to a special PayPal log file. 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?
It is no doubt negligible but, I also wonder if the Object Renderer might help
with efficiency in some tiny way? For example:
if(PayPalLogger.IsWarnEnabled) {
PayPalLogger.Warn(myParserMethod(myIpnMessage)); }
This will check the logger 2 times for IsWarnEnabled, however
PayPalLogger.Warn(myIpnMessage);
is cleaner code and will only use the Object Renderer after it has checked
IsWarnEnabled just once right?
Anyway, the point is I also have a Transaction logger which is supposed to send
me emails after a transaction has taken place (e.g. money has been
transferred). Every time a new IpnMessage arrives from PayPal the code must
use it to find a pre-saved Transaction object in the website back-end database.
The transaction object contains details of what has been ordered and how much
should be paid. The code checks the IpnMessage to make sure that the full
amount has been paid (matches the transaction), then the Transaction logger
will log an INFO transaction (and send me an email). If the wrong amount has
been paid, then the Transaction logger should log an ERROR transaction (and
send me an email).
Imagine if there was some error in the currency conversion which meant that
*sometimes* the wrong price got paid by the customer. On top of that, there
was a mistake in the code which meant that the transaction errors were actually
being sent to the wrong logger.
PayPalLogger.Error(myTransaction); // oops
should of been:
TransactionLogger.Error(myTransaction);
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.
was (Author: benixix):
Maybe I miss-understood your documentation, which says:
log4net is built on a number of different frameworks. Each new version of the
frameworks add new features. To take advantage of these new features we must
build log4net using the appropriate framework.
(http://logging.apache.org/log4net/release/framework-support.html)
I was suggesting an *addition* to the existing API that would take advantage of
the Generics feature in the newer frameworks. So there would be no issue with
backward compatibility right? However, maybe what is being described is only
the internals of the log4net assemblies and not the API (although you do have
different appenders for different framework builds). Perhaps I didn't
understand this right. Sorry.
With regard to you asking about a usecase, I think the problem comes when you
have more than one logger declared in the same class and these loggers have
different jobs. I can describe my situation, but I am still in the development
phase of this project and so we still have some work to do on it.
I have an ASP.NET website that is communicating with PayPal IPN and I would
like to log all communications. I have designed my own helper class that
encapsulates an IPN message, lets call it IpnMessage. After inspecting an
incoming IpnMessage object I can decide if I want to log it as INFO, WARN or
ERROR. This
[jira] [Commented] (LOG4NET-406) Log4Net breaks the Microsoft naming rules for namespaces
[ https://issues.apache.org/jira/browse/LOG4NET-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831129#comment-13831129 ] Ben commented on LOG4NET-406: - I guess this would make sense since you want people to recognise that they have the right brand and not a counterfeit. Log4Net breaks the Microsoft naming rules for namespaces Key: LOG4NET-406 URL: https://issues.apache.org/jira/browse/LOG4NET-406 Project: Log4net Issue Type: Improvement Components: Appenders, Core Affects Versions: 1.2.9, 1.2.10, 1.2.11, 1.2.12, 1.2.13, 1.3.0, 1.2 Maintenance Release, 3.5, 4.0 Environment: Windows 7, .Net 4.0 Reporter: Michael Goldfinger Priority: Trivial Fix For: 1.3.0 The log4net namespace violates the naming convention for namespaces in .Net. http://msdn.microsoft.com/en-us/library/vstudio/ms229026(v=vs.100).aspx As stated Pacal casing should be used: Do use Pascal casing, and separate namespace components with periods (for example, Microsoft.Office.PowerPoint) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Issue Comment Deleted] (LOG4NET-406) Log4Net breaks the Microsoft naming rules for namespaces
[ https://issues.apache.org/jira/browse/LOG4NET-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben updated LOG4NET-406: Comment: was deleted (was: I guess this would make sense since you want people to recognise that they have the right brand and not a counterfeit.) Log4Net breaks the Microsoft naming rules for namespaces Key: LOG4NET-406 URL: https://issues.apache.org/jira/browse/LOG4NET-406 Project: Log4net Issue Type: Improvement Components: Appenders, Core Affects Versions: 1.2.9, 1.2.10, 1.2.11, 1.2.12, 1.2.13, 1.3.0, 1.2 Maintenance Release, 3.5, 4.0 Environment: Windows 7, .Net 4.0 Reporter: Michael Goldfinger Priority: Trivial Fix For: 1.3.0 The log4net namespace violates the naming convention for namespaces in .Net. http://msdn.microsoft.com/en-us/library/vstudio/ms229026(v=vs.100).aspx As stated Pacal casing should be used: Do use Pascal casing, and separate namespace components with periods (for example, Microsoft.Office.PowerPoint) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (LOG4NET-409) Generics added to the Logger
[
https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831119#comment-13831119
]
Ben edited comment on LOG4NET-409 at 11/25/13 1:36 AM:
---
Maybe I miss-understood your documentation, which says:
log4net is built on a number of different frameworks. Each new version of the
frameworks add new features. To take advantage of these new features we must
build log4net using the appropriate framework.
(http://logging.apache.org/log4net/release/framework-support.html)
I was suggesting an *addition* to the existing API that would take advantage of
the Generics feature in the newer frameworks. So there would be no issue with
backward compatibility right? However, maybe what is being described is only
the internals of the log4net assemblies and not the API (although you do have
different appenders for different framework builds). Perhaps I didn't
understand this right. Sorry.
With regard to you asking about a usecase, I think the problem comes when you
have more than one logger declared in the same class and these loggers have
different jobs. I can describe my situation, but I am still in the development
phase of this project and so we still have some work to do on it.
I have an ASP.NET website that is communicating with PayPal IPN and I would
like to log all communications. I have designed my own helper class that
encapsulates an IPN message, lets call it IpnMessage. After inspecting an
incoming IpnMessage object I can decide if I want to log it as INFO, WARN or
ERROR. This then gets logged to a special PayPal log file. 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?
It is no doubt negligible but, I also wonder if the Object Renderer might help
with efficiency in some tiny way? For example:
if(PayPalLogger.IsWarnEnabled) {
PayPalLogger.Warn(myParserMethod(myIpnMessage)); }
This will check the logger 2 times for IsWarnEnabled, however
PayPalLogger.Warn(myIpnMessage);
is cleaner code and will only use the Object Renderer after it has checked
IsWarnEnabled just once right?
Anyway, the point is I also have a Transaction logger which is supposed to send
me emails after a transaction has taken place (e.g. money has been
transferred). Every time a new IpnMessage arrives from PayPal the code must
use it to find a pre-saved Transaction object in the website back-end database.
The transaction object contains details of what has been ordered and how much
should be paid. The code checks the IpnMessage to make sure that the full
amount has been paid (matches the transaction), then the Transaction logger
will log an INFO transaction (and send me an email). If the wrong amount has
been paid, then the Transaction logger should log an ERROR transaction (and
send me an email).
Imagine if there was some error in the currency conversion which meant that
*sometimes* the wrong price got paid by the customer. On top of that, there
was a mistake in the code which meant that the transaction errors were actually
being sent to the wrong logger.
PayPalLogger.Error(myTransaction); // oops
should of been:
TransactionLogger.Error(myTransaction);
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.
However, if I could use Generics to setup my loggers as follows:
ILogIpnMessage PayPalLogger =
LogManager.GetLoggerIpnMessage(PayPalLogger);
ILogTransaction TransactionLogger =
LogManager.GetLoggerTransaction(TransactionLogger);
Then the above mistake would have be flagged up before I publish the website.
was (Author: benixix):
Maybe I miss-understood your documentation, which says:
log4net is built on a number of different frameworks. Each new version of the
frameworks add new features. To take advantage of these new features we must
build log4net using the appropriate framework.
(http://logging.apache.org/log4net/release/framework-support.html)
I was suggesting an *addition* to the existing API that would take advantage of
the Generics feature in the newer frameworks. So there would be no issue with
backward compatibility right? However, maybe what is being described is only
the internals of the log4net assemblies and not the API (although you do have
different appenders for different framework builds). Perhaps I didn't
understand this right. Sorry.
With regard to you asking about a usecase, I think the problem comes when you
have more than one logger declared in the same class and these loggers have
different jobs. I can describe my situation, but I am still in the development
phase of this project and so we still have some work to do on it.
I
[jira] [Comment Edited] (LOG4NET-406) Log4Net breaks the Microsoft naming rules for namespaces
[ https://issues.apache.org/jira/browse/LOG4NET-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13830995#comment-13830995 ] Ben edited comment on LOG4NET-406 at 11/25/13 1:47 AM: --- Yes, I understand that this is an API breaking change and yes Jonathan's comments about this being a guidance and not a hard-and-fast rule are also valid. However I do not agree that there is only negative value in this proposal. I am fairly new to log4net, and when I stated using it and found that the using directive was all lower case letters, I found this slightly confusing and disconcerting (did I install the right version; am I using a test version; did I mess something up). I would have considered a renaming of the namespace an important part of the port from log4j to .NET. If you are going to port to .NET then you should be taking the .NET Framework Guidelines seriously, which you probably are, but for your brand new users who aren't familiar with the 10 year namespace history, the lowercase using directive introduces uncertainty and worry. This was my experience. So I do not think that this proposal has only negative value. I would also like to point out that during a migration to a newer version there is a Find and Replace tool within Visual Studio that can be set to scan the entire Solution. It could be used to replace using log4net to using Log4Net and this would be fairly painless and quick. So its not necessarily an entirely manual operation. While I do not expect everyone to agree with me, I don't think I am the only one to feel this way and I do hope that my opinion is a valuable contribution to this debate. was (Author: benixix): Yes, I understand that this is an API breaking change and yes Jonathan's comments about this being a guidance and not a hard-and-fast rule are also valid. However I do not agree that there is only negative value in this proposal. I am fairly new to log4net, and when I stated using it and found that the using directive was all lower case letters, I found this slightly confusing and disconcerting (did I install the right version; am I using a test version; did I mess something up). I would have considered a renaming of the namespace an important part of the port from log4j to .NET. If you are going to port to .NET then you should be taking the .NET Framework Guidelines seriously, which you probably are, but for your brand new users who aren't familiar with the 10 year namespace history, the lowercase using directive make log4net look like it has been built by amateurs and introduces uncertainty and worry. This was my experience. So I do not think that this proposal has only negative value. I would also like to point out that during a migration to a newer version there is a Find and Replace tool within Visual Studio that can be set to scan the entire Solution. It could be used to replace using log4net to using Log4Net and this would be fairly painless and quick. So its not necessarily an entirely manual operation. While I do not expect everyone to agree with me, I don't think I am the only one to feel this way and I do hope that my opinion is a valuable contribution to this debate. Log4Net breaks the Microsoft naming rules for namespaces Key: LOG4NET-406 URL: https://issues.apache.org/jira/browse/LOG4NET-406 Project: Log4net Issue Type: Improvement Components: Appenders, Core Affects Versions: 1.2.9, 1.2.10, 1.2.11, 1.2.12, 1.2.13, 1.3.0, 1.2 Maintenance Release, 3.5, 4.0 Environment: Windows 7, .Net 4.0 Reporter: Michael Goldfinger Priority: Trivial Fix For: 1.3.0 The log4net namespace violates the naming convention for namespaces in .Net. http://msdn.microsoft.com/en-us/library/vstudio/ms229026(v=vs.100).aspx As stated Pacal casing should be used: Do use Pascal casing, and separate namespace components with periods (for example, Microsoft.Office.PowerPoint) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LOG4NET-329) Allow creation of UTF-8 logs without a BOM.
[ https://issues.apache.org/jira/browse/LOG4NET-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13289099#comment-13289099 ] Ben commented on LOG4NET-329: - Thank you. I can confirm that this works. I was only familiar with the value attribute and was not aware that a type attribute was available. The existing functionality is sufficient, so I will mark this as resolved. Allow creation of UTF-8 logs without a BOM. --- Key: LOG4NET-329 URL: https://issues.apache.org/jira/browse/LOG4NET-329 Project: Log4net Issue Type: Wish Components: Appenders Affects Versions: 1.2.11 Environment: Windows 7. Reporter: Ben Priority: Minor Labels: appender, encodings, unicode When an appender uses the utf-8 encoding, output logs will append a BOM to the start of a file. This is problematic when the log file is only supposed to output errors. Explorer reports the file size as non-0, so the only way to know if an error actually occurred is to open the log every time and check. This is not desirable. Further, from the Unicode FAQ (http://unicode.org/faq/utf_bom.html), a BOM is unnecessary for UTF-8 since it is already a sequence of bytes, so there are no endian problems to solve in the first place. Removal of the BOM is not necessary, but should also provide a means to use UTF-8 without a BOM. That could be a new encoding name such as utf-8_nobom or as a separate attribute such as bom=false or something else. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOG4NET-329) Allow creation of UTF-8 logs without a BOM.
[ https://issues.apache.org/jira/browse/LOG4NET-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben resolved LOG4NET-329. - Resolution: Not A Problem As per the comments, this feature is already available via the type attribute. Allow creation of UTF-8 logs without a BOM. --- Key: LOG4NET-329 URL: https://issues.apache.org/jira/browse/LOG4NET-329 Project: Log4net Issue Type: Wish Components: Appenders Affects Versions: 1.2.11 Environment: Windows 7. Reporter: Ben Priority: Minor Labels: appender, encodings, unicode When an appender uses the utf-8 encoding, output logs will append a BOM to the start of a file. This is problematic when the log file is only supposed to output errors. Explorer reports the file size as non-0, so the only way to know if an error actually occurred is to open the log every time and check. This is not desirable. Further, from the Unicode FAQ (http://unicode.org/faq/utf_bom.html), a BOM is unnecessary for UTF-8 since it is already a sequence of bytes, so there are no endian problems to solve in the first place. Removal of the BOM is not necessary, but should also provide a means to use UTF-8 without a BOM. That could be a new encoding name such as utf-8_nobom or as a separate attribute such as bom=false or something else. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
