[TYPO3-core] Strategy for deprecation log

[Steffen Müller]

Hi,

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 [1] 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

Better solution:
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
GeneralUtility::deprecationLog() with:

  $logger =
self::makeInstance('TYPO3\\CMS\\Core\\Log\\LogManager')->getLogger('deprecation');
  $logger->warning($msg);

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. [2]

If you have ideas for more fancy stuff in step 2) - then go ahead and
share.

Questions I have:
* How to flush the registry from the backend?
* Should we filter duplicates be default?
* How to migrate the old configuration from
$TYPO3_CONF_VARS['SYS']['enableDeprecationLog']?
* What is your workflow with deprecation log? (when working on core or
extensions)



[1] https://review.typo3.org/#/c/19251/
[2] https://gist.github.com/t3node/5282732

-- 
cheers,
Steffen

TYPO3 Blog: http://www.t3node.com/
Twitter: @t3node - http://twitter.com/t3node