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

Tue Jan 11 21:15:01 UTC 2011

Zitat von 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.
>
> We could do something like re-initalizing the Log object (if it  
> exists) when the config file is eventually read.  Better yet, we  
> could implement log queuing so that log messages thrown during the  
> initial Horde setup will eventually be displayed when/if a "real"  
> Log object is setup.
>
>> 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.

Is this really a limitation linked to the Injector? I am by no means  
an expert when it comes to the PHP __destruct() method but as far as I  
know you can't reference one object from another's destructor. PHP  
makes no promises about the order it'll destroy your objects during  
shutdown. As the logger is its own instance it should always be  
problematic to use it within __destruct(). It might be gone already. I  
assume this would be independent of whether a reference is held in a  
DI container or not.

Is the problem here really caused by a __destruct() call? Which one? I  
wasn't able to determine the exact source here. The reason why the log  
handler was called at all was a "Headers already sent" error from PHP.  
Our Horde specific error handler gets called in that case and tries to  
log the error. I wonder if it wouldn't be sufficient to deregister the  
error handler before script shutdown.

>
> It seems the only option would be to re-initialize a Log object if  
> it doesn't exist to log these kind of errors - this would result in  
> all sorts of duplicate initializations, however (which may be  
> unavoidable).

Sounds way to complex for a destructor. I'd much rather avoid any  
logic in destructors that might even lead to logging.

Cheers,

Gunnar

>
> michael
>
> -- 
> ___________________________________
> Michael Slusarz [slusarz at horde.org]
>
>
> -- 
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de