Closed (duplicate)
Project:
Drupal core
Version:
8.0.x-dev
Component:
other
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
19 Apr 2013 at 08:55 UTC
Updated:
29 Jul 2014 at 22:12 UTC
Jump to comment: Most recent file
Comments
Comment #1
fabsor commentedThere are two ways I can think of to solve this issue:
1. Set the service container in the BOOTSTRAP_CONFIGURATION phase.
2. Modify watchdog and other possible places to check if the container is set where appropriate.
It seems to me that the first choice makes the most sense.
Comment #2
fabsor commentedComment #3
fabsor commentedThe minimal effort is to move the error handler code to the boot phase, after initializing the service container. This not ideal, since we probably want to use our error handler as early in the process as possible, but it would be hard to refactor it to work, but I'm setting this to needs review anyway to get some eyes on it =)
watchdog() uses the service container for getting the ip_address(), but it also calls hook_watchdog through module_implements, which requires the service container as well.
Comment #5
clemens.tolboomSee #1987262: [Installation Error] Symfony: "The service definition 'request' does not exist." calling watchdog.
Comment #6
clemens.tolboomThe definition of class Drupal states it's a
and Drupal::request has even
Should we patch all calls to Drupal::request() or even calls to Drupal::* by using a try-catch construct?
By using #3 we are putting stuff 'under the carpet' I guess.
(my 2 cents)
Comment #7
ParisLiakos commentedrelated
#1289536: Switch Watchdog to a PSR-3 logging framework
Comment #8
Blooniverse commented... priority change? For the reason see #1987262: [Installation Error] Symfony: "The service definition 'request' does not exist.".
Comment #9
catchThis looks like a duplicate of #1845646: error_displayable() cannot be converted from variable system safely.