You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-dev@logging.apache.org by Tasos Vogiatzoglou <tv...@gmail.com> on 2011/07/20 12:13:17 UTC
Is log4net in a cul-de-sac ?
Hello all,
It seems that there is very little activity on the log4net dev side.
Bugs remain unfixed, no release schedules, sparse activity on the
repository.
E.g. the official release has a long standing bug with IPv6 and having
an unofficial build (that is one that is not signed with apache key)
is not working for lots of people that use other libraries that have
dependencies on the strong named log4net assembly (.NET does not
permit assembly redirection among different public tokens).
If there is no plan, could we, somehow, help to make a release for
log4net having these fixes so we can benefit from an official log4net
release?
Regards
Tasos Vogiatzoglou
Re: Is log4net in a cul-de-sac ?
Posted by Tasos Vogiatzoglou <tv...@gmail.com>.
Ron, Roy
My major pain with log4net is the misbehaving network appenders in
presence of IPv6.
I am using the udp appender in a pretty big setup and I have to make
special configurations in each maching regarding the ips/target
hostnames.
Recently I had an SL project and tried to use log4net, thus the need
for an SL build.
I believe a new release is long overdue
Regards
Tasos Vogiatzoglou
On Sun, Jul 24, 2011 at 7:10 PM, Roy Chastain <Ro...@roychastain.org> wrote:
> I see no need to get 1.0 and 1.1 around.
> I have been using log4Net against 4.0 framework (full not client of
> Silverlight) and have yet to see any issues. I am using the simpler
> appenders (text based file and console ones only).
>
> My vote would be
> 1) - Remove the 1.0 and 1.1 support
> 2) - Convert to VS 2010 with the basic 2.0 -> 3.5 (2.0 CLR) in place and
> make that a 2.0 Release
> 3) - Refactor into multiple DLL etc as needed to support the various
> incarnations of 4.0 framework (full, client, Silverlight) and make that
> a 3.0 release.
> 4) - Start any internal rewrites as needed/desired for generics etc.
>
>
> ----------------------------------------------------------------------
> Roy Chastain
>
>
>
>
> -----Original Message-----
> From: Ron Grabowski [mailto:rongrabowski@yahoo.com]
> Sent: Sunday, July 24, 2011 12:03
> To: Log4NET Dev
> Subject: Re: Is log4net in a cul-de-sac ?
>
> I still use log4net every day across several large projects and check
> the mailing lists several times a week. All my stuff is still on 3.5
> still so I haven't been hit by any of the 4.0 issues. I don't know how
> much a new release targeting just 1.1, 2.0, and 3.5 would benefit people
> right considering 4.0 has been out for a while.
>
>
> What probably needs to happen is support for 1.0 and 1.1 needs dropped,
> support for 4.0 (including Client Profile) needs added, and we need to
> start to migrate things over to use generics.
>
>
> I'm not sure how to handle things like Compact Framework and
> Silverlight. I don't use those technologies and don't have a large
> interest in writing code for those frameworks. Would removing support
> for those two things, upgrading to VS2010 and .NET 4.0, then re-adding
> them later be a huge headache?
>
>
> ________________________________
>
> From: Tasos Vogiatzoglou <tv...@gmail.com>
> To: log4net-dev@logging.apache.org
> Sent: Wednesday, July 20, 2011 6:13 AM
> Subject: Is log4net in a cul-de-sac ?
>
> Hello all,
>
> It seems that there is very little activity on the log4net dev side.
> Bugs remain unfixed, no release schedules, sparse activity on the
> repository.
>
> E.g. the official release has a long standing bug with IPv6 and having
> an unofficial build (that is one that is not signed with apache key) is
> not working for lots of people that use other libraries that have
> dependencies on the strong named log4net assembly (.NET does not permit
> assembly redirection among different public tokens).
>
> If there is no plan, could we, somehow, help to make a release for
> log4net having these fixes so we can benefit from an official log4net
> release?
>
>
> Regards
> Tasos Vogiatzoglou
>
>
>
>
RE: Is log4net in a cul-de-sac ?
Posted by Roy Chastain <Ro...@roychastain.org>.
I see no need to get 1.0 and 1.1 around.
I have been using log4Net against 4.0 framework (full not client of
Silverlight) and have yet to see any issues. I am using the simpler
appenders (text based file and console ones only).
My vote would be
1) - Remove the 1.0 and 1.1 support
2) - Convert to VS 2010 with the basic 2.0 -> 3.5 (2.0 CLR) in place and
make that a 2.0 Release
3) - Refactor into multiple DLL etc as needed to support the various
incarnations of 4.0 framework (full, client, Silverlight) and make that
a 3.0 release.
4) - Start any internal rewrites as needed/desired for generics etc.
----------------------------------------------------------------------
Roy Chastain
-----Original Message-----
From: Ron Grabowski [mailto:rongrabowski@yahoo.com]
Sent: Sunday, July 24, 2011 12:03
To: Log4NET Dev
Subject: Re: Is log4net in a cul-de-sac ?
I still use log4net every day across several large projects and check
the mailing lists several times a week. All my stuff is still on 3.5
still so I haven't been hit by any of the 4.0 issues. I don't know how
much a new release targeting just 1.1, 2.0, and 3.5 would benefit people
right considering 4.0 has been out for a while.
What probably needs to happen is support for 1.0 and 1.1 needs dropped,
support for 4.0 (including Client Profile) needs added, and we need to
start to migrate things over to use generics.
I'm not sure how to handle things like Compact Framework and
Silverlight. I don't use those technologies and don't have a large
interest in writing code for those frameworks. Would removing support
for those two things, upgrading to VS2010 and .NET 4.0, then re-adding
them later be a huge headache?
________________________________
From: Tasos Vogiatzoglou <tv...@gmail.com>
To: log4net-dev@logging.apache.org
Sent: Wednesday, July 20, 2011 6:13 AM
Subject: Is log4net in a cul-de-sac ?
Hello all,
It seems that there is very little activity on the log4net dev side.
Bugs remain unfixed, no release schedules, sparse activity on the
repository.
E.g. the official release has a long standing bug with IPv6 and having
an unofficial build (that is one that is not signed with apache key) is
not working for lots of people that use other libraries that have
dependencies on the strong named log4net assembly (.NET does not permit
assembly redirection among different public tokens).
If there is no plan, could we, somehow, help to make a release for
log4net having these fixes so we can benefit from an official log4net
release?
Regards
Tasos Vogiatzoglou
Re: Is log4net in a cul-de-sac ?
Posted by Ron Grabowski <ro...@yahoo.com>.
I still use log4net every day across several large projects and check the mailing lists several times a week. All my stuff is still on 3.5 still so I haven't been hit by any of the 4.0 issues. I don't know how much a new release targeting just 1.1, 2.0, and 3.5 would benefit people right considering 4.0 has been out for a while.
What probably needs to happen is support for 1.0 and 1.1 needs dropped, support for 4.0 (including Client Profile) needs added, and we need to start to migrate things over to use generics.
I'm not sure how to handle things like Compact Framework and Silverlight. I don't use those technologies and don't have a large interest in writing code for those frameworks. Would removing support for those two things, upgrading to VS2010 and .NET 4.0, then re-adding them later be a huge headache?
________________________________
From: Tasos Vogiatzoglou <tv...@gmail.com>
To: log4net-dev@logging.apache.org
Sent: Wednesday, July 20, 2011 6:13 AM
Subject: Is log4net in a cul-de-sac ?
Hello all,
It seems that there is very little activity on the log4net dev side.
Bugs remain unfixed, no release schedules, sparse activity on the
repository.
E.g. the official release has a long standing bug with IPv6 and having
an unofficial build (that is one that is not signed with apache key)
is not working for lots of people that use other libraries that have
dependencies on the strong named log4net assembly (.NET does not
permit assembly redirection among different public tokens).
If there is no plan, could we, somehow, help to make a release for
log4net having these fixes so we can benefit from an official log4net
release?
Regards
Tasos Vogiatzoglou