[dev] [commits] Horde branch master updated. a8e51349c3fdc229031b6adc0d9427cddb74f58a

Sat Jan 15 04:31:33 UTC 2011

Quoting Michael M Slusarz <slusarz at horde.org>:

> Quoting Gunnar Wrobel <wrobel at horde.org>:
>
>> Zitat von Chuck Hagenbuch <chuck at horde.org>:
>>
>>> The branch "master" has been updated.
>>> The following is a summary of the commits.
>>>
>>> from: 4be9708dce08631e20adfd1a5422b694afbe503d
>>>
>>> a8e5134 What does this flush() do? With it, DIMP whitescreens for  
>>> me; without it, it seems to work fine.
>>
>> I don't think the flush() is the problem. But I ran into exactly  
>> the same problem here. I did commit this
>>
>> http://git.horde.org/diff.php/framework/Core/lib/Horde.php?r1=9210c133af8982e6336e20dc9e5bd70a24086b3e&r2=f22195496067ce9bc640408429db8b2b7e65b9cf
>>
>> to get rid of the problem.
>>
>> The recent
>>
>> http://git.horde.org/horde-git/-/commit/28890c80698713fefcbdd0e78cbe7176cec21ead
>>
>> kills me again.
>
> We need the $GLOBALS['conf'] check - it is possible that an  
> exception is thrown between the time we create the injector object  
> and when logging first becomes available in  
> Horde_Registry::__construct().  If this check isn't in place, a Null  
> logger object will be created and used for all future logging calls.

How about what I just pushed, checking for both $conf and $injector?

>> My statement made with my commit still holds true:
>>
>> "I currently get a fatal error whithin dynamic Imp (WSOD). Apparently
>> Horde::errorHandler() gets called during shutdown. The stack trace I
>> get from the error that Horde::errorHandler() tries to log looks like
>> this:
>>
>> Stack trace:
>> #0 [internal function]: Horde::errorHandler('<!DOCTYPE html ...', 5)
>> #1 [internal function]: ob_gzhandler()
>> #2 {main}
>>
>> While I still need to identify the source of this error I believe the
>> logMessage() method should always ensure it can actually log
>> something."
>
> This seems like an ugly limitation of the injector model.  The  
> logger will be available for any methods called via  
> register_shutdown_function().  But __destruct() calls may not have  
> the logger (or any other injector instance) available, since the  
> injector instance may have already been destroyed.  However, having  
> these errors being not at all seems very inappropriate so existence  
> checking for the Log object as a check would be incorrect.

I agree with Gunnar that this isn't an injector issue, just a general  
__destruct issue...

-chuck