anamikabir / solr-php-client

solr-php-client
Other
0 stars 0 forks source link

crashes in Turkish locale #67

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. setlocale(LC_ALL, 'tr_TR.utf8');
2. require_once('classes/Apache/Solr/Service.php');
3.

What is the expected output? What do you see instead?

expected: continue processing

reality: crash without error message in the http logs

What version of the product are you using? On what operating system?
r_22 and r_60
CentOS 5.6

Please provide any additional information below.
in r_60 not only the include of the class crashes, but also creating new 
instances

Original issue reported on code.google.com by patrick%...@gtempaccount.com on 25 May 2011 at 7:48

GoogleCodeExporter commented 8 years ago
I did a simple test script, and I do see an unexplained Fatal Error:

Fatal error: Interface 'IteratorAggregate' not found in 
/mnt/home/djimenez/public_html/Apache/Solr/Document.php on line 59

My script looked like this:

<?php

error_reporting(E_ALL);
ini_set('display_errors', 'On');

setlocale(LC_ALL, 'tr_TR.utf8');
require_once('Apache/Solr/Service.php');
?>

At first I had no idea why the current PHP locale would effect an internal SPL 
interface like that. I was able to reproduce with a simpler script:

<?php

error_reporting(E_ALL);
ini_set('display_errors', 'On');

setlocale(LC_ALL, 'tr_TR.utf8');

class Test implements IteratorAggregate
{
        private $iterator = array();

        public function getIterator()
        {
                return ArrayIterator($this->iterator);
        }
}
?>

When it gets really weird is that, if you put two class definitions that 
implement IteratorAggregate - one before the setlocale and one after - it only 
causes an error on the second one.

So I searched around bugs.php.net and found this nice explanation, specific to 
the Turkish locale - the problem has existed for several years:

http://www.topolis.lt/php/#35050
http://bugs.php.net/bug.php?id=35050

Pretty awful bug, that the PHP core team doesn't want to fix at the moment. 
Additionally, I don't think the json_decode function would have played nicely 
with the Turkish locale if you had float fields unless your Solr server was 
also in that locale since it will use the locale for formatting / parsing 
requests and responses (someone brought this up on the mailing list recently).

I probably need to put a big note about locale issues with this client.

Sorry I couldn't solve your problem.

Original comment by donovan....@gmail.com on 25 May 2011 at 3:26