[TYPO3-core] Strategy for deprecation log
typo3 at t3node.com
Mon Apr 1 03:28:47 CEST 2013
a lot of people complain about huge deprecation log files with a high
percentage of duplicate entries.
ATM there's a patch pending in gerrit which filters duplicates in the
deprecation log  to reduce size of these files.
What the patch does:
* create a unique token for the incoming deprecation log message
* load the complete log file,
* test line by line if token already exists
* append new line if not existing
Drawbacks of this approach:
* bad performance
* permanently monitoring the deprecation log by running "tail -f" on the
cli won't work for duplicates
IMO we should use the Logging API for writing deprecation log messages.
This would give users more control over deprecation log strategy.
The general approach would be to replace the implementation of
In the most simple case, we'd have a FileWriter configured which simply
writes to typo3temp/logs/deprecation.log This would be a plain
replacement for the 'file' part in GeneralUtility::deprecationLog()
To filter duplicates we could add a dedicated DeprecationWriter, which
1) receives all deprecation messages,
2) optionally checks for duplicates using the sys_registry
3) writes the log record to the configured target writers.
I already have a prove of concept for this. 
If you have ideas for more fancy stuff in step 2) - then go ahead and
Questions I have:
* How to flush the registry from the backend?
* Should we filter duplicates be default?
* How to migrate the old configuration from
* What is your workflow with deprecation log? (when working on core or
TYPO3 Blog: http://www.t3node.com/
Twitter: @t3node - http://twitter.com/t3node
More information about the TYPO3-team-core