Log files generated by the AccessLogValve and the JULI FileHandler could be automatically compressed after the rotation to save space. Some thoughts on a possible implementation: - the compression is optional and configured by new valve/handler parameters. - the actual compression could occur a few days after the rotation to keep the recent log files easily readable. - configuring the compression format would be nice but not essential, the files can simply be gziped.
Be careful; sometimes log files can be large and compressing them can take a while. I would recommend against adding more code to Tomcat that solves a problem already solved by better logging frameworks. Tomcat can be configured to use a logging framework for access-logs, so why not use e.g. log4j or the myriad other frameworks which already support rotation, compression, etc.?
I will take this feature and work on it . I will add the patch here in the attachment and share the GitHub
Thanks for your interest. A PR from GitHub will be fine. No need to attach it to this bug, but please do provide a reference to this bug in your PR and a reference to your PR in this bug.
Is it possible to assign it to me ?
Please leave the Bugzilla "Assigned" field alone so that the dev list continues to get notifications of bug status updates. (Yes, I know this is possible via other means, but this is how the Tomcat team usually handles BZ issues.) I don't believe anyone else is working on this, so you shouldn't have any problems with coordination.
Note: The ASF bugzilla instance has been modified so the assignee field is hard-coded to the relevant dev@ list.
Hello , I had pulled the changes to the under Log compression #223 to the tomcat githup repository , but there was no review. any Idea .
Can you post a link to your GitHub fork and/or the PR itself?
hi all, Can I continue with this task based on PR#223?
The quality of this patch/PR is low. Several unresolved comments have been made on the PR already. There isn't any proper resource-management. The CompressFileUtils class appears to be added twice under two separate packages (why the duplication?). I have to ask again why this is being added as a feature of the AccessLogValve and not just sending access logs to a proper logging framework which already supports compression, rotation, etc.?
(In reply to Christopher Schultz from comment #10) Hi Christopher, > The quality of this patch/PR is low. Several unresolved comments have been > made on the PR already. > > There isn't any proper resource-management. I mean that i will fix this unresovled comments based on some advices. > > The CompressFileUtils class appears to be added twice under two separate > packages (why the duplication?). I found this too,and i think the reason for this is only known to the author himself,and i will keep just one. > > I have to ask again why this is being added as a feature of the > AccessLogValve and not just sending access logs to a proper logging > framework which already supports compression, rotation, etc.? I aggree with you that using a logging framework that support these festures is the better way. But i have a question that this feature is not supported by AccessLogValve, it need user to implement AbstractAccessLogValve to support the function of sending logs to other logging frameworks，right?