Project

General

Profile

Actions

Bug #23495

closed

Remove logging when class loading failed in t3lib_autoloader

Added by Helmut Hummel about 14 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Should have
Category:
-
Target version:
-
Start date:
2010-09-02
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.5
PHP Version:
5.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

Branches: trunk (also 4.4 and 4.3 if RM agree)

Problem:
The t3lib_autoloader logs to syslog and devlog if it fails to autoload
the given classname.

This is wrong on so many levels:

1. It logs with severity "critical", which is wrong because it may be
that another registered autoloader may correctly handle the loading
of the class. So it could be a "notice", but I doubt this is usefull.
2. t3lib_autoloader is registered at a very early stage, so it will
always be the first in queue to try including the class file and
it cannot know if other autoloaders may be registered later on.
3. If you have a class_exists() in your code gracefully continuing if
the class is not there, the autoloader is triggered and logs a
failure which is not present.
4. If there is indeed a problem and the class cannot be required, PHP
will throw an fatal error anyway.
5. Since even extbase comes with an own autoloader, it's not only a
problem with third party extensions but with shipped components as
well.
6. When using getMock('foobar') for a unit test (which is quite common
to do) this makes a class_exists which triggers the autoloader,
which logs the "failure". So basically running the current core unit
tests result in a flooded log.

Solution:
Remove the logging from the autoloader

(issue imported from #M15628)

Actions #1

Updated by Steffen Gebert about 14 years ago

Committed to
- trunk rev. 8804
- 4-4 rev. 8803
- 4-3 rev. 8802

Will be released with 4.3.6, 4.4.3 and 4.5.0

Actions #2

Updated by Benni Mack about 6 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF