[TYPO3-core] Strategy for deprecation log
Steffen Müller
typo3 at t3node.com
Tue Apr 2 16:23:02 CEST 2013
Hi.
On 01.04.2013 15:57 Markus Klein wrote:
> It MIGHT lead to serious troubles in the (unknown) future, especially when it comes to database functions being deprecated. Somewhat a chicken - egg problem.
This is a valid argument.
There are already some places where the Logging API runs in endless
recursions when used: Autoloader, GeneralUtility::makeInstance() and
parts of the Logging API itself.
ATM the deprecation functions depend on t3lib_lock and
t3lib_utility_Debug::debugTrail() where we already would have a
chicken/egg situation.
Alternatively we could deliver a lightweight and independent solution
for deprecation log:
trigger_error($msg, E_USER_DEPRECATED);
ATM this is catched by error/exception handler and would need to be
excluded.
This could cure the pain of superfluous deprecation log files. I expect
php error_log being logrotated by default on 99.9% of all hosting
environments.
--
cheers,
Steffen
TYPO3 Blog: http://www.t3node.com/
Twitter: @t3node - http://twitter.com/t3node
More information about the TYPO3-team-core
mailing list