[log4net] RollingFileAppender extension that backs up only a last specified period (days, hours, etc.)

[Farhan Nasim <f....@gmail.com>]

Hi,

Have encountered a scenario in many projects where log files covering only
a last user specified period is needed (e.g. last 5 days, last 3 hours,
etc.) So far, Log4net doesn't provide any such appender out of the box; the
RollingFileAppender only supports backing up a number of last files
(maxSizeRollBackups).


1. I am writing an appender (made some progress in fact) that derives
from *RollingFileAppender
*and serves the purpose. It takes a string denoting a TimeSpan as parameter
and keeps files falling only in this period. It follows Log4net conventions
and it is tested for minutes to days periods. Is Log4net willing to include
any similar appender?


2. I need some critical feedbacks on naming and conventions. Am I supposed
to submit my changes as a pull request or have them discussed here?

Regards.

Farhan Nasim
http://fnasimbd.github.io

Re: [log4net] RollingFileAppender extension that backs up only a last specified period (days, hours, etc.)

[Dominik Psenner <dp...@apache.org>]

On 2018-12-19 20:55, Farhan Nasim wrote:
> 1. Thanks for informing about the 'next generation' RollingFileAppender. I
> have been going through your feature branch and it seems to be the right
> futuristic path. I'd like to contribute to it.

Awesome! Let me know if I can help you in any way.

> 2. However, I have queries regarding the faster way to make my appender to
> productio. Putting together the subset of RollingFileAppender
> functionalities in its NG counterpart will take some time and the NG
> appender will take some time to be popular too.
The NG counterpart should explicitly provide only a very small subset of 
the original functionality. Less is more. To provide people a migration 
path, it should support custom rolling strategies. The coupling between 
the rolling strategy and the appender should be as small as possible.
>
> On the other hand, the appender I am proposing (derived from
> RollingFileAppender) is nearly complete. RollingFileAppender has many
> issues, but still it is the most popular I think and is quite acceptable in
> low-strain conditions. How about reusing RollingFileAppender for now and
> working on the NG at the same time, for future releases? Or is it the
> resolution across log4net that "no more extensions to RollingFileAppender"?
> :D

The RollingFileAppender has a long history and survived several futile 
attempts to improve it. Some of those attempts even caused collateral 
damage for the many use cases that it has grown to be used for. It 
should be touched with outermost care.

> 3. In order to contribute, shall I create a new branch from the NG feature
> branch, make changes, and send pull requests into the NG branch? Or can I
> commit directly to NG branch?

That's up to you.

1. If you want to help writing the next generation RFA, the branch to 
base your contribution on is probably feature/RollingFileAppender-NG. 
You should merge develop into that branch to avoid these branches drift 
apart.

2. If you are going to contribute to the existing RollingFileAppender, 
the branch feature/rfa-configurable-rolling-mutex is probably the right 
place. That branch however needs proper testing to be merged into 
develop. It would be great if you could help us with testing, too. :-)

3. You probably also noticed that there's a release branch, tracking 
what changes are going to be part of the next release 2.1.0. That branch 
also needs proper testing, possibly by using the binaries that jenkins 
builds for us. The plan is to use those binaries in the release process 
but the lack of testing is a blocker for the release process of 2.1.0. I 
feel uncomfortable with publishing binaries built by jenkins for the 
first time without a basic test for every published binary. I thought of 
pushing several sample projects to github that both serve as templates 
but also as testing sandboxes of more realistic environments. Help from 
the community is of course greatly appreciated.

Cheers,
Dominik

Re: [log4net] RollingFileAppender extension that backs up only a last specified period (days, hours, etc.)

[Farhan Nasim <f....@gmail.com>]

Hi Dominik,

Thanks for your reply.

1. Thanks for informing about the 'next generation' RollingFileAppender. I
have been going through your feature branch and it seems to be the right
futuristic path. I'd like to contribute to it.

2. However, I have queries regarding the faster way to make my appender to
productio. Putting together the subset of RollingFileAppender
functionalities in its NG counterpart will take some time and the NG
appender will take some time to be popular too.

On the other hand, the appender I am proposing (derived from
RollingFileAppender) is nearly complete. RollingFileAppender has many
issues, but still it is the most popular I think and is quite acceptable in
low-strain conditions. How about reusing RollingFileAppender for now and
working on the NG at the same time, for future releases? Or is it the
resolution across log4net that "no more extensions to RollingFileAppender"?
:D

3. In order to contribute, shall I create a new branch from the NG feature
branch, make changes, and send pull requests into the NG branch? Or can I
commit directly to NG branch?

Regards.

Farhan Nasim
http://fnasimbd.github.io

On Tue, Dec 18, 2018, 4:43 PM Dominik Psenner <dp...@gmail.com> wrote:

> Hi Farhan,
>
> it's great to see your interest in the logging framework log4net. I'm
> commenting inline below ..
>
> On 2018-12-13 23:31, Farhan Nasim wrote:
> > Have encountered a scenario in many projects where log files covering
> only
> > a last user specified period is needed (e.g. last 5 days, last 3 hours,
> > etc.) So far, Log4net doesn't provide any such appender out of the box;
> the
> > RollingFileAppender only supports backing up a number of last files
> > (maxSizeRollBackups).
>
> This is a valid usecase.
>
> > 1. I am writing an appender (made some progress in fact) that derives
> > from *RollingFileAppender
> > *and serves the purpose. It takes a string denoting a TimeSpan as
> parameter
> > and keeps files falling only in this period. It follows Log4net
> conventions
> > and it is tested for minutes to days periods. Is Log4net willing to
> include
> > any similar appender?
>
> The RollingFileAppender is probably not the ideal base to start off your
> work. I already put
> effort into re-writing the RollingFileAppender where the rolling
> strategy is pluggable. Would
> you like to continue or derive from that work? The branch is
> feature/RollingFileAppender-NG [1].
> Unfortunately I had so far not the time to complete this. We do observe
> that a major part of
> reported issues is related to the current implementation of the
> RollingFileAppender and would like
> to improve this situation. The next generation rolling file appender
> should probably only provide
> a subset of the functionality that its predecessor offered but should
> become more stable.
>
> > 2. I need some critical feedbacks on naming and conventions. Am I
> supposed
> > to submit my changes as a pull request or have them discussed here?
>
> A good place to discuss source code contributions is github in the form
> of a pull request. You'll
> also benefit from the continuous integration. Jenkins builds each pull
> requests and you can examine
> the build outputs etc. Please try to keep your pull requests short and
> concise to allow easy reviews.
>
> [1]
>
> https://github.com/apache/logging-log4net/tree/feature/RollingFileAppender-NG
>
>

Re: [log4net] RollingFileAppender extension that backs up only a last specified period (days, hours, etc.)

[Dominik Psenner <dp...@gmail.com>]

Hi Farhan,

it's great to see your interest in the logging framework log4net. I'm 
commenting inline below ..

On 2018-12-13 23:31, Farhan Nasim wrote:
> Have encountered a scenario in many projects where log files covering only
> a last user specified period is needed (e.g. last 5 days, last 3 hours,
> etc.) So far, Log4net doesn't provide any such appender out of the box; the
> RollingFileAppender only supports backing up a number of last files
> (maxSizeRollBackups).

This is a valid usecase.

> 1. I am writing an appender (made some progress in fact) that derives
> from *RollingFileAppender
> *and serves the purpose. It takes a string denoting a TimeSpan as parameter
> and keeps files falling only in this period. It follows Log4net conventions
> and it is tested for minutes to days periods. Is Log4net willing to include
> any similar appender?

The RollingFileAppender is probably not the ideal base to start off your 
work. I already put
effort into re-writing the RollingFileAppender where the rolling 
strategy is pluggable. Would
you like to continue or derive from that work? The branch is 
feature/RollingFileAppender-NG [1].
Unfortunately I had so far not the time to complete this. We do observe 
that a major part of
reported issues is related to the current implementation of the 
RollingFileAppender and would like
to improve this situation. The next generation rolling file appender 
should probably only provide
a subset of the functionality that its predecessor offered but should 
become more stable.

> 2. I need some critical feedbacks on naming and conventions. Am I supposed
> to submit my changes as a pull request or have them discussed here?

A good place to discuss source code contributions is github in the form 
of a pull request. You'll
also benefit from the continuous integration. Jenkins builds each pull 
requests and you can examine
the build outputs etc. Please try to keep your pull requests short and 
concise to allow easy reviews.

[1] 
https://github.com/apache/logging-log4net/tree/feature/RollingFileAppender-NG