|Anonymous | Login | Signup for a new account||2019-01-20 21:04 GMT|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000518||Xdebug||Feature/Change request||public||2010-01-10 21:20||2011-02-24 12:00|
|Target Version||Fixed in Version|
|Summary||0000518: make CLASSNAME pseudo-property optional, not necessary.|
|Description||XDebug 2.1 appends CLASSNAME property to list object's members, which is supposed to display class name in IDEs that doesn't handle "classname" property in response's XML data.|
However for IDEs which handle it properly it is kind of duplicate which is completely unnecessary. Thus, there should be an option to disable it via php.ini, or via DBGp protocol.
Personally I'd advise the second way, so that the IDE which connects can inform engine that is aware of the problem and will handle displaying classnames on it's own, using xml data only.
On the other hand, most major implementations I've seen handle it properly...
|Tags||No tags attached.|
Don't know the functionality of "CLASSNAME".
It easy to handle: ATM is the only property not encoded.
protected $classname = "bibit";
protected $CLASSNAME = "BIBIT";
$first = new BiBiT;
<response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" [^] command="context_get" transaction_id="16" context="0"><property name="first" fullname="$first" address="167032516" type="object" children="1" classname="BiBiT" numchildren="2"><property name="CLASSNAME" type="string"><![CDATA[BiBiT]]></property><property name="classname" fullname="$first->classname" facet="protected" address="167030180" type="string" size="5" encoding="base64"><![CDATA[YmliaXQ=]]></property><property name="CLASSNAME" fullname="$first->CLASSNAME" facet="protected" address="167030372" type="string" size="5" encoding="base64"><![CDATA[QklCSVQ=]]></property></property></response>
|incastrix, good point indeed. Anyway It's kind of trick to eliminate "classname" prop which is not encoded, and that is what I'd like to avoid as it depends on XDebug version, not the protocol specification.|
edited on: 2010-03-12 11:16
This seems related to bug 0000421 and bug 0000458 (which has been closed, but as far as I can see has not been resolved):
According to derick, bug 0000458 is due to an error in Eclipse PDT, but the eclipse developers say the cause is, quote:
"It seems that in the xdebug version listed as 2.1-dev, there appears to be some temporary code which creates a non existant variable called CLASSNAME. The data is a string but not base64 encoded and PDT doesn't know how to handle a string from xdebug that is not base64 encoded as xdebug should never send a string variable in any other format except base64 encoded."
See the following eclipse bug reports for more information:
For development I now use Eclipse galileo, PHP 5.3 and xdebug v2.0.6, and since all my code is made up of classes and functions and that version of xdebug doesn't seem to support variable tracing within functions this is a big issue for me...
Update 2010-03-12: By "downgrading" PHP to 5.2.9 i was able to make it work with xdebug 2.0.5 - and see the local function variables. Eclipse still freaks out if there is a watched expression that does not exist in the current context, but I'll survive as long as the variable list shows up...
I guess this means that:
1. Local class/function variables are unavailable in Eclipse when using PHP 5.3 with both xdebug 2.1.x and 2.0.5/6
2. Debugging PHP classes and functions in Eclipse does not work at all with xdebug 2.1.x because of the newly added CLASSNAME attribute (and/or it's base64 encoding)
3. Consider testing compatibility with Eclipse before releasing 2.1.0rc1... :)
I'm monitoring this issue, so add a note if I can help you out with this in any way...
eschatus: This is *not* a bug and unrelated to what your wrote. I would add to the eclipse report by my username and password stopped working or something. Anyway, Eclipse PDT does *not* handle this correctly. Values are only base64 encoded if that attribute is present, and as you can see from the XML above, the encoding="base64" attribute is not available for the extra CLASSNAME property. This is something that needs to be fixed in PDT, as it is described in the specs: http://xdebug.org/docs-dbgp.php#properties-variables-and-values [^] (last element in the table).
The issue is also totally not related to 0000421, so I removed your comment there.
|@incastrix: I mentioned this to the Komodo people, which do not show the class name for objects yet. As I only really use Komodo, I added this feature until they've sorted this out on their end.|
There are feature requests for both Komodo and Netbeans now:
and Eclipse/PDT is tracking it at:
|Oops, the netbeans bug is at https://netbeans.org/bugzilla/show_bug.cgi?id=183885 [^]|
|It's fixed in the latest Komodo 6, and Netbeans 6.9, so I've just removed the CLASSNAME thing for 2.1.1dev and 2.2dev.|
|2010-01-10 21:20||migajek||New Issue|
|2010-01-10 21:20||migajek||PHP Version||=> 5.3.2|
|2010-01-10 21:20||migajek||Xdebug Version||=> 2.1.0-dev|
|2010-02-04 01:30||incastrix||Note Added: 0001318|
|2010-02-04 09:46||migajek||Note Added: 0001319|
|2010-03-11 17:17||eschatus||Note Added: 0001378|
|2010-03-12 09:12||eschatus||Note Edited: 0001378|
|2010-03-12 09:13||eschatus||Note Edited: 0001378|
|2010-03-12 09:14||eschatus||Note Edited: 0001378|
|2010-03-12 11:16||eschatus||Note Edited: 0001378|
|2010-03-20 23:22||derick||Note Added: 0001396|
|2010-03-20 23:27||derick||Note Added: 0001397|
|2010-04-04 00:31||derick||Relationship added||has duplicate 0000556|
|2010-04-12 12:23||derick||Note Added: 0001442|
|2010-04-13 20:45||derick||Note Added: 0001447|
|2011-02-24 12:00||derick||Note Added: 0001681|
|2011-02-24 12:00||derick||Status||new => closed|
|2011-02-24 12:00||derick||Assigned To||=> derick|
|2011-02-24 12:00||derick||Resolution||open => fixed|
|Copyright © 2000 - 2019 MantisBT Team|