On 26 Aug 2015 5:22 pm, "Walden H. Leverich" <wald...@techsoftinc.com>
wrote:
>
> > … 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);
>
>
Thats an interesting but rare usecase, isnt it? Mileage may vary, but to me
this favorizes mixing production with logging code which would not pass my
code review until it was refactored. Anyway, good that we can discuss about
these kind of things.
Log4j2 has a compatibility api which allows users to glue old code with the
new api while at the same time the new api was refactored and cleaned up.
Maybe we will need something like that, too? I.e. a log4net2 namespace and
a legacy log4net namespace that wires transparently to the new api in
log4net2.
> --
> Walden H Leverich III
> (516) 627-3800 x3051
> wald...@techsoftinc.com
>
>
>
> From: jerem...@gowdy.me [mailto:jerem...@gowdy.me]
> Sent: Wednesday, August 19, 2015 10:50 AM
> To: Log4NET Dev <log4net-dev@logging.apache.org>
> 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 <zippy1...@gmail.com> 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 <ilbol...@gmail.com> wrote:
>>>
>>> Agree.
>>>
>>> Will the code be compatible with the current version?
>>>
>>>
>>>
>>> On Wed, Aug 19, 2015 at 8:03 AM, Miroslav Vanický <
miroslav.vani...@vande.cz> wrote:
>>>>
>>>> Logging to MSSQL would be nice!
>>>>
>>>>
>>>>
>>>> On 19.8.2015 12:56, Javier Sanchez wrote:
>>>>>
>>>>> Agree!
>>>>>
>>>>> El ago. 19, 2015 3:21 AM, <dpsen...@apache.org> 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.
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
