Yes, the change to stop and asyncCompress would get things done. ;) Thanks, -- TJ
Sent from mobile. On Nov 6, 2011 2:27 PM, "ceki" <[email protected]> wrote: > > > 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 > [email protected] > http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user> >
_______________________________________________ Logback-user mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/logback-user
