> … the syslog appender is also a very useful appender for mixed shops.
I agree wholeheartedly. The syslog appender is an integral part of our
production environment.
I also think you need to reconsider massive breaking changes to the API. If
you’re going to force me to visit lots of code points to “fix” log4net calls
then I’m also going to evaluate solutions other than log4net, if I’ve got to
change code I might as well just change code. I am in favor of some
simplification though, and eliminating, or at least moving to a secondary
assembly, some of the less-used appenders.
There was a comment about eliminating the IsDebugEnabled (and similar)
properties, please don’t! The assumption that it can be handled with late
evaluation is a poor one. Yes, I can use a lambda to get stuff at the point of
the log.debug() call but it’s a bad assumption that the only place I gather
stuff is at the point of the call. This is not an uncommon use case for us, and
cannot be handled in a lambda:
If (IsDebugEnabled)
{ gather some stuff}
Do some stuff
If (IsDebugEnabled)
{gather some more stuff we only have access to here}
Do some more stuff
If (IsDebugEnabled)
{gather yet more low-level stuff we can only get at this point}
Do more stuff
if (IsDebugEnabled)
{
Gather yet more stuff;
Assemble stuff from prior points
log.debug(combined stuff);
}
--
Walden H Leverich III
(516) 627-3800 x3051
[email protected]<mailto:[email protected]>
From: [email protected] [mailto:[email protected]]
Sent: Wednesday, August 19, 2015 10:50 AM
To: Log4NET Dev <[email protected]>
Subject: Re: Log4net 2.0
I would throw out there that the syslog appender is also a very useful appender
for mixed shops.
A couple things though. I don't see any need to break any appenders that work
fine. I'm not sure what the current appender skeleton interface lacks that we'd
want to make breaking changes for. I would approve of dropping high
complexity, low reward appenders like outdated .NET remoting.
I'm very pro-async/ await but I'm not sure that I'd want or need to await
logging. Every log4net deployment I've ever done has used a non-blocking
appender to queue logs. I would never introduce waiting for whatever appenders
are configured as a blocking operation before my code continued. We currently
have a ConcurrentQueueAppender that we use to buffer all logging out of the
active thread.
Requiring .NET 4.5 is fine, if it serves a purpose. However, I am of the
opinion that .NET 2.0 or .NET 4.0 easily encompasses the actual usage needed
for log4net. We should use the lowest version that works so as to have the
broadest support. Many enterprise shops can't just jump to .NET 4.5.1 or 4.6.
We don't need any more user exodus.
I'm all for an unused/complex/poor appender clean up, and dropping support for
.NET 1.1, but at the point where you're going back to console and file
appenders only, and .NET 4.5, you might as well start a new project.
One of the points raised is very valid. We need build automation. There's VSO
Build, MyGet Build Services, AppVeyor among other things. I'm willing to wager
one of them would support the project with a free build setup. Artifacts of
official build versions get published to nuget.
We also need to take ownership of nuget packaging log4net. This current "that's
not us, that's up to the package maintainer" comes off as silly in a world
where every commonly used library is consumed via nuget. The strong naming key
change fiasco and the lack of official nuget packaging and the nuget package
having differing version numbers have all damaged the credibility of the
project and promoted the idea that .NET's open source community doesn't amount
to much. If we aren't going to take the steps to make log4net appealing to
use, we may as well attic the project.
On Aug 19, 2015, at 5:44 AM, Justin Dearing
<[email protected]<mailto:[email protected]>> wrote:
I'd be willing to lend a hand. Some ideas:
* Just be bold and embrace .NET 4.5, CoreCLR and the current version of Mono
(must build on Centos7 with the official mono yum repo). Anyone with an XP
requirement will either stick to the old log4net for now, or we've already lost
them to NLog or whatever. Let's make a great modern piece of software, and not
worry about abandoning legacy users that have plenty of options.
* Why .NET 4.5? async/await mainly.
* Forget supporting the current appenders. Its not hard to write an {obscure
RDBMS appender} from scratch, and someone from that community is always willing
to do that.
* Console and text file should be all that we need to ship, but anything that
will run on a stock windows OS (or with official MSFT updates like newer SQL
drivers) should be considered for 1.0 release if someone will write them.
* What we do need with the appender interface is install/uninstall hooks. There
should be a pipeline for appending install and uninstall Func<>()s so the users
can hook into them. This way a program can have an "install appender target" or
"uninstall appender target" mode. This is important for databases (creating the
table), or an eventlog appender where you need to install an event source as
admin but your program runs unprivileged.
Justin
On Wed, Aug 19, 2015 at 7:48 AM Ílson Bolzan
<[email protected]<mailto:[email protected]>> wrote:
Agree.
Will the code be compatible with the current version?
On Wed, Aug 19, 2015 at 8:03 AM, Miroslav Vanický
<[email protected]<mailto:[email protected]>> wrote:
Logging to MSSQL would be nice!
On 19.8.2015 12:56, Javier Sanchez wrote:
Agree!
El ago. 19, 2015 3:21 AM, <[email protected]<mailto:[email protected]>>
escribió:
Hi,
Last night I’ve dreamed a dream and in that dream the release process of
log4net happened on a flick of a switch. Now that I’m awake again I find the
idea most pleasing and thus I’m bringing this idea to the dev list [1].
My idea was that we should start off log4net2 “from scratch” that targets only
.NET 4.0 [2] and does only what the largest part of people want from it:
1. Log to console
2. Log to file [3]
What can also be discussed is if log4net2 should get an interface to the
existing appenders.
Please discuss!
Cheers,
Dominik
[1] To make this come true there will be the need for a few helping hands and
therefore this message goes to people that use log4net and want log4net to be
revived.
[2] With .NET 4.0 we would still support good old WinXP and that should really
be enough for today’s technology.
[3] Yes, with rolling and there shouldn’t be a thousand possible combinations
of configuration options. Stability and speed goes over functionality.
--
[https://www.linuxcounter.net/cert/391268.png]
________________________________
