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

Tue Jan 11 20:09:55 UTC 2011

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.

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).

michael

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]