[TYPO3-core] Strategy for deprecation log

[Michael Stucki]

Hi!

I agree that something needs to be done about the deprecation log, but
yet I'm undecided about Steffens approach. It requires a database
connection and it will be slower than writing to the filesystem.

How about a different approach:
- Keep using the file
- Add a scheduler job which cleans up the file once per day

With this approach, no dependencies are added and the performance
remains the same. It would allow us to implement the best possible
solution: either use the DB for unique filtering, or create a nicely
formatted text report, which is what I currently prefer...

Greetings, Michael

Am 01.04.2013 03:28, schrieb 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
>