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 ?
_______________________________________________
Logback-user mailing list
Logback-user@qos.ch
http://mailman.qos.ch/mailman/listinfo/logback-user
