[TYPO3-core] RFC: #15628: Remove logging when class loading failed in t3lib_autoloader

[Helmut Hummel]

Hi,

this is a SVN patch request.

Bugtracker reference: http://bugs.typo3.org/view.php?id=15628

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

Steps to reproduce:
Execute the unit tests and watch the TYPO3 syslog/ php error log.

Note:
I think the XCLASS definition could also be removed from the static
t3lib_autoloader class, it makes no sense there, but this should be done
in a different commit and has nothing to do with this RFC.

Regards Helmut
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 15628.diff
Type: text/x-patch
Size: 947 bytes
Desc: not available
URL: <http://lists.typo3.org/pipermail/typo3-team-core/attachments/20100902/92d2e71e/attachment.bin>