[logback-user] Compression in SiftingAppender

[ceki]

There is a rollover method in RollingFileAppender [1] and another one
in the RollingPolicy interface. So the term rollover maybe ambiguous.

I am under the impression that if the stop() method was modified to read:

   public void stop() {
       super.stop();
       rollingPolicy.stop();
       if(rollingPolicy != triggeringPolicy)
         triggeringPolicy.stop();
     }

and if the access modifier for the asyncCompress method in
TimeBasedRollingPolicy was changed to "protected", then the stop()
method in your custom rolling policy could simply do the compression
and the problem would be solved in just a few lines of code.

Am I misreading an aspect of the problem?

More below.
--
Ceki

[1] http://goo.gl/ya7XK

On 11/6/2011 7:20 PM, TJ Rothwell wrote:
> Ceki,
>
> The compression is the goal. However a feature like rollover on close
> would make it easier to implement. The problem is that it adds
> complexity by modifying an interface that 3rd parties are using. With
> the base class, it reduces incompatibilities with those impls.
>
> Correct me if I'm wrong, but rollover does processing on the activefile
> inorder to prepare for the next activefile. The rollover process started
> from the appender doesn't create the next activefile. Its after rollever
> that the next activefile is created.

It depends on what you by rollover. As mentioned above there are two 
rollover methods. Were you aware of http://goo.gl/ya7XK ?