[Cartoweb-dev] Wrong log4php in cartoweb-withdemo-3.5.0.tar.gz download

[Alexandre Saunier]

Hello Bruno,

> Log4php present in include is wrong it's the old php4 incompatible
version with php5
> ( you are using 0.90 )

OK, thanks for the link. CartoWeb uses Log4php 0.9 since it was the only
version available when CartoWeb was created. Maybe we'll consider using
the PHP5 port for the next CW release. In the meantime it should be no
big deal to use version 0.9 since it has worked quite nicely until now.

> To remove some strict standard error :
>  "Only variables should be assigned by reference"
> You have to replace :
> $this->log =& LoggerManager::getLogger(__CLASS__);
> by
> $this->log = LoggerManager::getLogger(__CLASS__);
> along the code

You are right. The reference operator & is indeed not necessary since
objects are always assigned by reference with PHP5.

> Did I need to enter a bug for each of this 2 points ?

Sure. Please do.

Thank you!
Alexandre

Bruno Friedmann wrote:
> Just try a fresh install of 3.5.0
> 
> Log4php present in include is wrong it's the old php4 incompatible version with php5
> ( you are using 0.90 )
> 
> But inside the code of cw3.5.0 you are calling log4php like using the svn snapshot of the new log4php version
> http://svn.apache.org/viewcvs.cgi/incubator/log4php
> 
> like for example
> PHP Strict standards:  Non-static method LoggerLog::internalDebugging() should not be called statically, assuming $this from
> incompatible context in /home/bruno/workspace/cw3dev/include/log4php/LoggerLog.php on line 49
> 
> The big trouble of that if you try to run php scripts or tests whatever
> in PHP Strict Standard mode (Normal mode for developper)
> you get pages and pages of warnings & errors.
> Making more difficult to found a real error or an important warnings.
> 
> To remove some strict standard error :
>  "Only variables should be assigned by reference"
> 
> You have to replace :
> 
> $this->log =& LoggerManager::getLogger(__CLASS__);
> by
> $this->log = LoggerManager::getLogger(__CLASS__);
> along the code
> (Could provide a patch but a search & replace is more efficient I suppose)
> 
> Did I need to enter a bug for each of this 2 points ?
> 
>