Eclipse Community Forums: PHP Development Tools (PDT) » PDT / Xdebug / Multiple sub domains

Home » Language IDEs » PHP Development Tools (PDT) » PDT / Xdebug / Multiple sub domains

PDT / Xdebug / Multiple sub domains [message #84282]

Sat, 22 November 2008 00:20

Eclipse User

Hi,

I am wondering if it is possible to setup a PDT debug session to respond
to multiple sub domains?

I am working with an application that has ServerAlias' within a virtual
host such that any number of sub domains call the same code so if I
setup a breakpoint on a line of code it should break on any of the sub
domains.

Currently it doesn't look like it is possible due to the fact the the
PHP Server configuration has a URL like http://domain.com/. What I would
be looking for is something like http://*.domain.com/. Then in the path
mapping it would just be one entry.

--
Shawn Clark

Re: PDT / Xdebug / Multiple sub domains [message #84312 is a reply to message #84282]

Sat, 22 November 2008 04:50

Eclipse User

Originally posted by: dkel50.hotnospmail.com

Hi Shawn, I am not sure I fully understand the problem. The xdebug
implementation doesn't make use of urls for path mapping. The only time
the url is used is when you launch the debugger for the first time. This
then invokes that url and turns on the xdebug cookie so that the browser
is then in debug mode. All interaction between xdebug running in the web
server and PDT is done by absolute file name and this is what the path
mapper uses. So you map the absolute path in the web server to your
workspace path in PDT.

When you set a breakpoint in PDT, it can translate that to the correct
absolute path in your server and define the correct breakpoint in the
server. So if it is all the same code then that breakpoint will fire and
PDT will break.

PDT autogenerates a path mapping based on the file you specify in the
web script launch and the file that gets executed when the url is
invoked. You can of course create your own path mappings when you define
the server.

I hope this explanation helps.

Dave Kelsey

Shawn Clark wrote:
> Hi,
>
> I am wondering if it is possible to setup a PDT debug session to respond
> to multiple sub domains?
>
> I am working with an application that has ServerAlias' within a virtual
> host such that any number of sub domains call the same code so if I
> setup a breakpoint on a line of code it should break on any of the sub
> domains.
>
> Currently it doesn't look like it is possible due to the fact the the
> PHP Server configuration has a URL like http://domain.com/. What I would
> be looking for is something like http://*.domain.com/. Then in the path
> mapping it would just be one entry.
>
> --
> Shawn Clark

Re: PDT / Xdebug / Multiple sub domains [message #84388 is a reply to message #84312]

Sat, 22 November 2008 15:26

Eclipse User

Ah... that is sort of what I was thinking but it wasn't working and now
I think I understand exactly what the problem is and it isn't so much a
problem with PDT as it is with Xdebug.

When Eclipse loads the URL in the server configuration for the debug
session it passes along the information which Xdebug then puts into a
session cookie for the browser. The thing I am guessing is happening is
that the cookie is only for the current domain and not any sub-domain of
that domain. So when I am going to a sub-domain the cookie isn't being
passed to Xdebug and as such Xdebug isn't relaying the absolute path
information to the IDE.

I am going to test now and will see if that is the case. I will just
watch where Xdebug tells the browser to assign the cookie. I am guessing
it is just for the main domain that is for the URL that is set in Eclipse.

--
Shawn Clark

Dave wrote:
> Hi Shawn, I am not sure I fully understand the problem. The xdebug
> implementation doesn't make use of urls for path mapping. The only time
> the url is used is when you launch the debugger for the first time. This
> then invokes that url and turns on the xdebug cookie so that the browser
> is then in debug mode. All interaction between xdebug running in the web
> server and PDT is done by absolute file name and this is what the path
> mapper uses. So you map the absolute path in the web server to your
> workspace path in PDT.
>
> When you set a breakpoint in PDT, it can translate that to the correct
> absolute path in your server and define the correct breakpoint in the
> server. So if it is all the same code then that breakpoint will fire and
> PDT will break.
>
> PDT autogenerates a path mapping based on the file you specify in the
> web script launch and the file that gets executed when the url is
> invoked. You can of course create your own path mappings when you define
> the server.
>
> I hope this explanation helps.
>
> Dave Kelsey
>
>
> Shawn Clark wrote:
>> Hi,
>>
>> I am wondering if it is possible to setup a PDT debug session to
>> respond to multiple sub domains?
>>
>> I am working with an application that has ServerAlias' within a
>> virtual host such that any number of sub domains call the same code so
>> if I setup a breakpoint on a line of code it should break on any of
>> the sub domains.
>>
>> Currently it doesn't look like it is possible due to the fact the the
>> PHP Server configuration has a URL like http://domain.com/. What I
>> would be looking for is something like http://*.domain.com/. Then in
>> the path mapping it would just be one entry.
>>
>> --
>> Shawn Clark

Re: PDT / Xdebug / Multiple sub domains [message #84400 is a reply to message #84388]

Sat, 22 November 2008 16:09

Eclipse User

Just tested and it is indeed a problem with the cookie. Within my
application I have some site wide cookies setup so that the host is
..domain.com where the first . is to signify all sub-domains. What I did
was edit my XDEBUG_SESSION cookie once it was created to add the . in
the front and now I can debug all sub-domains.

So my question now is can one or the other of the following be made
available:

- Can a flag be set within the Xdebug php.ini settings to allow a wild
card sub-domain cookie instead of the domain itself
- Can a URL argument be passed along with the XDEBUG_SESSION_START to
state that it is for all sub-domains
- With this option a setting would need to be added to the Xdebug
server configuration within PDT to tell which PHP server configurations
can pass that argument

If time is of concern then I can look at making the change to PDT if
someone is able to help with the Xdebug side of things. I did notice
there is a Firefox add-on to enable Xdebug for a specific page. I am
going to look at extending that add-on to do multiple sub-domains as
well as an interim solution.

--
Shawn Clark

Shawn Clark wrote:
> Ah... that is sort of what I was thinking but it wasn't working and now
> I think I understand exactly what the problem is and it isn't so much a
> problem with PDT as it is with Xdebug.
>
> When Eclipse loads the URL in the server configuration for the debug
> session it passes along the information which Xdebug then puts into a
> session cookie for the browser. The thing I am guessing is happening is
> that the cookie is only for the current domain and not any sub-domain of
> that domain. So when I am going to a sub-domain the cookie isn't being
> passed to Xdebug and as such Xdebug isn't relaying the absolute path
> information to the IDE.
>
> I am going to test now and will see if that is the case. I will just
> watch where Xdebug tells the browser to assign the cookie. I am guessing
> it is just for the main domain that is for the URL that is set in Eclipse.
>
> --
> Shawn Clark
>
> Dave wrote:
>> Hi Shawn, I am not sure I fully understand the problem. The xdebug
>> implementation doesn't make use of urls for path mapping. The only
>> time the url is used is when you launch the debugger for the first
>> time. This then invokes that url and turns on the xdebug cookie so
>> that the browser is then in debug mode. All interaction between xdebug
>> running in the web server and PDT is done by absolute file name and
>> this is what the path mapper uses. So you map the absolute path in the
>> web server to your workspace path in PDT.
>>
>> When you set a breakpoint in PDT, it can translate that to the correct
>> absolute path in your server and define the correct breakpoint in the
>> server. So if it is all the same code then that breakpoint will fire
>> and PDT will break.
>>
>> PDT autogenerates a path mapping based on the file you specify in the
>> web script launch and the file that gets executed when the url is
>> invoked. You can of course create your own path mappings when you
>> define the server.
>>
>> I hope this explanation helps.
>>
>> Dave Kelsey
>>
>>
>> Shawn Clark wrote:
>>> Hi,
>>>
>>> I am wondering if it is possible to setup a PDT debug session to
>>> respond to multiple sub domains?
>>>
>>> I am working with an application that has ServerAlias' within a
>>> virtual host such that any number of sub domains call the same code
>>> so if I setup a breakpoint on a line of code it should break on any
>>> of the sub domains.
>>>
>>> Currently it doesn't look like it is possible due to the fact the the
>>> PHP Server configuration has a URL like http://domain.com/. What I
>>> would be looking for is something like http://*.domain.com/. Then in
>>> the path mapping it would just be one entry.
>>>
>>> --
>>> Shawn Clark

Re: PDT / Xdebug / Multiple sub domains [message #84431 is a reply to message #84400]

Sat, 22 November 2008 18:02

Eclipse User

Hi Shawn, a good bit of detective work there. You may want to see what the author of xdebug thinks.
Suggest you go over to http://www.xdebug.org which should give details on the xdebug mailing list as
well as how to raise bugs and feature requests for xdebug.

Would be great as well if you could report back on how you got on with the xdebug firefox extension.

Regards
Dave Kelsey

Shawn Clark wrote:
> Just tested and it is indeed a problem with the cookie. Within my
> application I have some site wide cookies setup so that the host is
> .domain.com where the first . is to signify all sub-domains. What I did
> was edit my XDEBUG_SESSION cookie once it was created to add the . in
> the front and now I can debug all sub-domains.
>
> So my question now is can one or the other of the following be made
> available:
>
> - Can a flag be set within the Xdebug php.ini settings to allow a wild
> card sub-domain cookie instead of the domain itself
> - Can a URL argument be passed along with the XDEBUG_SESSION_START to
> state that it is for all sub-domains
> - With this option a setting would need to be added to the Xdebug
> server configuration within PDT to tell which PHP server configurations
> can pass that argument
>
> If time is of concern then I can look at making the change to PDT if
> someone is able to help with the Xdebug side of things. I did notice
> there is a Firefox add-on to enable Xdebug for a specific page. I am
> going to look at extending that add-on to do multiple sub-domains as
> well as an interim solution.
>
> --
> Shawn Clark
>
>
> Shawn Clark wrote:
>> Ah... that is sort of what I was thinking but it wasn't working and
>> now I think I understand exactly what the problem is and it isn't so
>> much a problem with PDT as it is with Xdebug.
>>
>> When Eclipse loads the URL in the server configuration for the debug
>> session it passes along the information which Xdebug then puts into a
>> session cookie for the browser. The thing I am guessing is happening
>> is that the cookie is only for the current domain and not any
>> sub-domain of that domain. So when I am going to a sub-domain the
>> cookie isn't being passed to Xdebug and as such Xdebug isn't relaying
>> the absolute path information to the IDE.
>>
>> I am going to test now and will see if that is the case. I will just
>> watch where Xdebug tells the browser to assign the cookie. I am
>> guessing it is just for the main domain that is for the URL that is
>> set in Eclipse.
>>
>> --
>> Shawn Clark
>>
>> Dave wrote:
>>> Hi Shawn, I am not sure I fully understand the problem. The xdebug
>>> implementation doesn't make use of urls for path mapping. The only
>>> time the url is used is when you launch the debugger for the first
>>> time. This then invokes that url and turns on the xdebug cookie so
>>> that the browser is then in debug mode. All interaction between
>>> xdebug running in the web server and PDT is done by absolute file
>>> name and this is what the path mapper uses. So you map the absolute
>>> path in the web server to your workspace path in PDT.
>>>
>>> When you set a breakpoint in PDT, it can translate that to the
>>> correct absolute path in your server and define the correct
>>> breakpoint in the server. So if it is all the same code then that
>>> breakpoint will fire and PDT will break.
>>>
>>> PDT autogenerates a path mapping based on the file you specify in the
>>> web script launch and the file that gets executed when the url is
>>> invoked. You can of course create your own path mappings when you
>>> define the server.
>>>
>>> I hope this explanation helps.
>>>
>>> Dave Kelsey
>>>
>>>
>>> Shawn Clark wrote:
>>>> Hi,
>>>>
>>>> I am wondering if it is possible to setup a PDT debug session to
>>>> respond to multiple sub domains?
>>>>
>>>> I am working with an application that has ServerAlias' within a
>>>> virtual host such that any number of sub domains call the same code
>>>> so if I setup a breakpoint on a line of code it should break on any
>>>> of the sub domains.
>>>>
>>>> Currently it doesn't look like it is possible due to the fact the
>>>> the PHP Server configuration has a URL like http://domain.com/. What
>>>> I would be looking for is something like http://*.domain.com/. Then
>>>> in the path mapping it would just be one entry.
>>>>
>>>> --
>>>> Shawn Clark

Re: PDT / Xdebug / Multiple sub domains [message #84628 is a reply to message #84431]

Sun, 23 November 2008 22:27

Eclipse User

Well I got a version of the Xdebug Firefox plugin to work on sub-domains
and even added a quick checkbox to create the cookies for sub-domains.
Only problem now is that by default Xdebug will create a cookie only for
the primary domain when Eclipse opens up the page with the start
information in the URL. For now what I have been doing is using the
plugin to create the cookie before starting the Eclipse debug session so
that the Xdebug server isn't writing the primary domain cookie and the
browser keeps the sub-domain one.

Might have to look into PDT a bit and see if I can setup an option so
that when I am starting a debug session within Eclipse it can load the
page in the web browser without sending the starting Xdebug parameters.
A couple times I have forgotten to set the cookie with the add-on then
once it has been created with Eclipse I have to go and delete that
cookie and create another with the wildcard sub-domain.

--
Shawn Clark

P.S. trying to figure out how to package up the Firefox plugin so that
other people can use it. Right now I just modified the code within the
firefox extensions folder.

Dave Kelsey wrote:
> Hi Shawn, a good bit of detective work there. You may want to see what
> the author of xdebug thinks. Suggest you go over to
> http://www.xdebug.org which should give details on the xdebug mailing
> list as well as how to raise bugs and feature requests for xdebug.
>
> Would be great as well if you could report back on how you got on with
> the xdebug firefox extension.
>
> Regards
> Dave Kelsey
>
> Shawn Clark wrote:
>> Just tested and it is indeed a problem with the cookie. Within my
>> application I have some site wide cookies setup so that the host is
>> .domain.com where the first . is to signify all sub-domains. What I
>> did was edit my XDEBUG_SESSION cookie once it was created to add the .
>> in the front and now I can debug all sub-domains.
>>
>> So my question now is can one or the other of the following be made
>> available:
>>
>> - Can a flag be set within the Xdebug php.ini settings to allow a wild
>> card sub-domain cookie instead of the domain itself
>> - Can a URL argument be passed along with the XDEBUG_SESSION_START to
>> state that it is for all sub-domains
>> - With this option a setting would need to be added to the Xdebug
>> server configuration within PDT to tell which PHP server
>> configurations can pass that argument
>>
>> If time is of concern then I can look at making the change to PDT if
>> someone is able to help with the Xdebug side of things. I did notice
>> there is a Firefox add-on to enable Xdebug for a specific page. I am
>> going to look at extending that add-on to do multiple sub-domains as
>> well as an interim solution.
>>
>> --
>> Shawn Clark
>>
>>
>> Shawn Clark wrote:
>>> Ah... that is sort of what I was thinking but it wasn't working and
>>> now I think I understand exactly what the problem is and it isn't so
>>> much a problem with PDT as it is with Xdebug.
>>>
>>> When Eclipse loads the URL in the server configuration for the debug
>>> session it passes along the information which Xdebug then puts into a
>>> session cookie for the browser. The thing I am guessing is happening
>>> is that the cookie is only for the current domain and not any
>>> sub-domain of that domain. So when I am going to a sub-domain the
>>> cookie isn't being passed to Xdebug and as such Xdebug isn't relaying
>>> the absolute path information to the IDE.
>>>
>>> I am going to test now and will see if that is the case. I will just
>>> watch where Xdebug tells the browser to assign the cookie. I am
>>> guessing it is just for the main domain that is for the URL that is
>>> set in Eclipse.
>>>
>>> --
>>> Shawn Clark
>>>
>>> Dave wrote:
>>>> Hi Shawn, I am not sure I fully understand the problem. The xdebug
>>>> implementation doesn't make use of urls for path mapping. The only
>>>> time the url is used is when you launch the debugger for the first
>>>> time. This then invokes that url and turns on the xdebug cookie so
>>>> that the browser is then in debug mode. All interaction between
>>>> xdebug running in the web server and PDT is done by absolute file
>>>> name and this is what the path mapper uses. So you map the absolute
>>>> path in the web server to your workspace path in PDT.
>>>>
>>>> When you set a breakpoint in PDT, it can translate that to the
>>>> correct absolute path in your server and define the correct
>>>> breakpoint in the server. So if it is all the same code then that
>>>> breakpoint will fire and PDT will break.
>>>>
>>>> PDT autogenerates a path mapping based on the file you specify in
>>>> the web script launch and the file that gets executed when the url
>>>> is invoked. You can of course create your own path mappings when you
>>>> define the server.
>>>>
>>>> I hope this explanation helps.
>>>>
>>>> Dave Kelsey
>>>>
>>>>
>>>> Shawn Clark wrote:
>>>>> Hi,
>>>>>
>>>>> I am wondering if it is possible to setup a PDT debug session to
>>>>> respond to multiple sub domains?
>>>>>
>>>>> I am working with an application that has ServerAlias' within a
>>>>> virtual host such that any number of sub domains call the same code
>>>>> so if I setup a breakpoint on a line of code it should break on any
>>>>> of the sub domains.
>>>>>
>>>>> Currently it doesn't look like it is possible due to the fact the
>>>>> the PHP Server configuration has a URL like http://domain.com/.
>>>>> What I would be looking for is something like http://*.domain.com/.
>>>>> Then in the path mapping it would just be one entry.
>>>>>
>>>>> --
>>>>> Shawn Clark

Re: PDT / Xdebug / Multiple sub domains [message #84633 is a reply to message #84628]

Mon, 24 November 2008 08:17

Eclipse User

Shawn, are you using PDT 2.0 builds ? If you are then you could make use of the JIT debugging
facility in PDT 2.0.

This allows your web server to initiate the debug session rather than PDT. You could then enter the
URL yourself in firefox and so long as xdebug sees a cookie it will initiate a debug session and PDT
will automatically create a launch for you.

I think the default for "Accept Remote Session (JIT)" is off be default so you will need to enable it.

Dave Kelsey

Shawn Clark wrote:
> Well I got a version of the Xdebug Firefox plugin to work on sub-domains
> and even added a quick checkbox to create the cookies for sub-domains.
> Only problem now is that by default Xdebug will create a cookie only for
> the primary domain when Eclipse opens up the page with the start
> information in the URL. For now what I have been doing is using the
> plugin to create the cookie before starting the Eclipse debug session so
> that the Xdebug server isn't writing the primary domain cookie and the
> browser keeps the sub-domain one.
>
> Might have to look into PDT a bit and see if I can setup an option so
> that when I am starting a debug session within Eclipse it can load the
> page in the web browser without sending the starting Xdebug parameters.
> A couple times I have forgotten to set the cookie with the add-on then
> once it has been created with Eclipse I have to go and delete that
> cookie and create another with the wildcard sub-domain.
>
> --
> Shawn Clark
>
> P.S. trying to figure out how to package up the Firefox plugin so that
> other people can use it. Right now I just modified the code within the
> firefox extensions folder.
>
> Dave Kelsey wrote:
>> Hi Shawn, a good bit of detective work there. You may want to see what
>> the author of xdebug thinks. Suggest you go over to
>> http://www.xdebug.org which should give details on the xdebug mailing
>> list as well as how to raise bugs and feature requests for xdebug.
>>
>> Would be great as well if you could report back on how you got on with
>> the xdebug firefox extension.
>>
>> Regards
>> Dave Kelsey
>>
>> Shawn Clark wrote:
>>> Just tested and it is indeed a problem with the cookie. Within my
>>> application I have some site wide cookies setup so that the host is
>>> .domain.com where the first . is to signify all sub-domains. What I
>>> did was edit my XDEBUG_SESSION cookie once it was created to add the
>>> . in the front and now I can debug all sub-domains.
>>>
>>> So my question now is can one or the other of the following be made
>>> available:
>>>
>>> - Can a flag be set within the Xdebug php.ini settings to allow a
>>> wild card sub-domain cookie instead of the domain itself
>>> - Can a URL argument be passed along with the XDEBUG_SESSION_START to
>>> state that it is for all sub-domains
>>> - With this option a setting would need to be added to the Xdebug
>>> server configuration within PDT to tell which PHP server
>>> configurations can pass that argument
>>>
>>> If time is of concern then I can look at making the change to PDT if
>>> someone is able to help with the Xdebug side of things. I did notice
>>> there is a Firefox add-on to enable Xdebug for a specific page. I am
>>> going to look at extending that add-on to do multiple sub-domains as
>>> well as an interim solution.
>>>
>>> --
>>> Shawn Clark
>>>
>>>
>>> Shawn Clark wrote:
>>>> Ah... that is sort of what I was thinking but it wasn't working and
>>>> now I think I understand exactly what the problem is and it isn't so
>>>> much a problem with PDT as it is with Xdebug.
>>>>
>>>> When Eclipse loads the URL in the server configuration for the debug
>>>> session it passes along the information which Xdebug then puts into
>>>> a session cookie for the browser. The thing I am guessing is
>>>> happening is that the cookie is only for the current domain and not
>>>> any sub-domain of that domain. So when I am going to a sub-domain
>>>> the cookie isn't being passed to Xdebug and as such Xdebug isn't
>>>> relaying the absolute path information to the IDE.
>>>>
>>>> I am going to test now and will see if that is the case. I will just
>>>> watch where Xdebug tells the browser to assign the cookie. I am
>>>> guessing it is just for the main domain that is for the URL that is
>>>> set in Eclipse.
>>>>
>>>> --
>>>> Shawn Clark
>>>>
>>>> Dave wrote:
>>>>> Hi Shawn, I am not sure I fully understand the problem. The xdebug
>>>>> implementation doesn't make use of urls for path mapping. The only
>>>>> time the url is used is when you launch the debugger for the first
>>>>> time. This then invokes that url and turns on the xdebug cookie so
>>>>> that the browser is then in debug mode. All interaction between
>>>>> xdebug running in the web server and PDT is done by absolute file
>>>>> name and this is what the path mapper uses. So you map the absolute
>>>>> path in the web server to your workspace path in PDT.
>>>>>
>>>>> When you set a breakpoint in PDT, it can translate that to the
>>>>> correct absolute path in your server and define the correct
>>>>> breakpoint in the server. So if it is all the same code then that
>>>>> breakpoint will fire and PDT will break.
>>>>>
>>>>> PDT autogenerates a path mapping based on the file you specify in
>>>>> the web script launch and the file that gets executed when the url
>>>>> is invoked. You can of course create your own path mappings when
>>>>> you define the server.
>>>>>
>>>>> I hope this explanation helps.
>>>>>
>>>>> Dave Kelsey
>>>>>
>>>>>
>>>>> Shawn Clark wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I am wondering if it is possible to setup a PDT debug session to
>>>>>> respond to multiple sub domains?
>>>>>>
>>>>>> I am working with an application that has ServerAlias' within a
>>>>>> virtual host such that any number of sub domains call the same
>>>>>> code so if I setup a breakpoint on a line of code it should break
>>>>>> on any of the sub domains.
>>>>>>
>>>>>> Currently it doesn't look like it is possible due to the fact the
>>>>>> the PHP Server configuration has a URL like http://domain.com/.
>>>>>> What I would be looking for is something like
>>>>>> http://*.domain.com/. Then in the path mapping it would just be
>>>>>> one entry.
>>>>>>
>>>>>> --
>>>>>> Shawn Clark

Re: PDT / Xdebug / Multiple sub domains [message #84644 is a reply to message #84633]

Mon, 24 November 2008 09:23

Eclipse User

AH!!! No way! I've so got to try this tomorrow...
Thanks for the tip.

Dave Kelsey wrote:

> Shawn, are you using PDT 2.0 builds ? If you are then you could make use of
the JIT debugging
> facility in PDT 2.0.

> This allows your web server to initiate the debug session rather than PDT.
You could then enter the
> URL yourself in firefox and so long as xdebug sees a cookie it will initiate
a debug session and PDT
> will automatically create a launch for you.

> I think the default for "Accept Remote Session (JIT)" is off be default so
you will need to enable it.

> Dave Kelsey

Re: PDT / Xdebug / Multiple sub domains [message #84678 is a reply to message #84633]

Mon, 24 November 2008 13:05

Eclipse User

Thanks for that bit of info and I will try it tonight on my dev setup there.

I am guessing this would not work if I have a proxy setup? Right now at
work we have a proxy setup so that multiple developers can debug web
sites on our development server. If xdebug is contacting the IDE through
JIT it would fail if it is going to the proxy?

--
Shawn Clark

Dave Kelsey wrote:
> Shawn, are you using PDT 2.0 builds ? If you are then you could make use
> of the JIT debugging facility in PDT 2.0.
>
> This allows your web server to initiate the debug session rather than
> PDT. You could then enter the URL yourself in firefox and so long as
> xdebug sees a cookie it will initiate a debug session and PDT will
> automatically create a launch for you.
>
> I think the default for "Accept Remote Session (JIT)" is off be default
> so you will need to enable it.
>
> Dave Kelsey
>
>
>
> Shawn Clark wrote:
>> Well I got a version of the Xdebug Firefox plugin to work on
>> sub-domains and even added a quick checkbox to create the cookies for
>> sub-domains. Only problem now is that by default Xdebug will create a
>> cookie only for the primary domain when Eclipse opens up the page with
>> the start information in the URL. For now what I have been doing is
>> using the plugin to create the cookie before starting the Eclipse
>> debug session so that the Xdebug server isn't writing the primary
>> domain cookie and the browser keeps the sub-domain one.
>>
>> Might have to look into PDT a bit and see if I can setup an option so
>> that when I am starting a debug session within Eclipse it can load the
>> page in the web browser without sending the starting Xdebug
>> parameters. A couple times I have forgotten to set the cookie with the
>> add-on then once it has been created with Eclipse I have to go and
>> delete that cookie and create another with the wildcard sub-domain.
>>
>> --
>> Shawn Clark
>>
>> P.S. trying to figure out how to package up the Firefox plugin so that
>> other people can use it. Right now I just modified the code within the
>> firefox extensions folder.
>>
>> Dave Kelsey wrote:
>>> Hi Shawn, a good bit of detective work there. You may want to see
>>> what the author of xdebug thinks. Suggest you go over to
>>> http://www.xdebug.org which should give details on the xdebug mailing
>>> list as well as how to raise bugs and feature requests for xdebug.
>>>
>>> Would be great as well if you could report back on how you got on
>>> with the xdebug firefox extension.
>>>
>>> Regards
>>> Dave Kelsey
>>>
>>> Shawn Clark wrote:
>>>> Just tested and it is indeed a problem with the cookie. Within my
>>>> application I have some site wide cookies setup so that the host is
>>>> .domain.com where the first . is to signify all sub-domains. What I
>>>> did was edit my XDEBUG_SESSION cookie once it was created to add the
>>>> . in the front and now I can debug all sub-domains.
>>>>
>>>> So my question now is can one or the other of the following be made
>>>> available:
>>>>
>>>> - Can a flag be set within the Xdebug php.ini settings to allow a
>>>> wild card sub-domain cookie instead of the domain itself
>>>> - Can a URL argument be passed along with the XDEBUG_SESSION_START
>>>> to state that it is for all sub-domains
>>>> - With this option a setting would need to be added to the Xdebug
>>>> server configuration within PDT to tell which PHP server
>>>> configurations can pass that argument
>>>>
>>>> If time is of concern then I can look at making the change to PDT if
>>>> someone is able to help with the Xdebug side of things. I did notice
>>>> there is a Firefox add-on to enable Xdebug for a specific page. I am
>>>> going to look at extending that add-on to do multiple sub-domains as
>>>> well as an interim solution.
>>>>
>>>> --
>>>> Shawn Clark
>>>>
>>>>
>>>> Shawn Clark wrote:
>>>>> Ah... that is sort of what I was thinking but it wasn't working and
>>>>> now I think I understand exactly what the problem is and it isn't
>>>>> so much a problem with PDT as it is with Xdebug.
>>>>>
>>>>> When Eclipse loads the URL in the server configuration for the
>>>>> debug session it passes along the information which Xdebug then
>>>>> puts into a session cookie for the browser. The thing I am guessing
>>>>> is happening is that the cookie is only for the current domain and
>>>>> not any sub-domain of that domain. So when I am going to a
>>>>> sub-domain the cookie isn't being passed to Xdebug and as such
>>>>> Xdebug isn't relaying the absolute path information to the IDE.
>>>>>
>>>>> I am going to test now and will see if that is the case. I will
>>>>> just watch where Xdebug tells the browser to assign the cookie. I
>>>>> am guessing it is just for the main domain that is for the URL that
>>>>> is set in Eclipse.
>>>>>
>>>>> --
>>>>> Shawn Clark
>>>>>
>>>>> Dave wrote:
>>>>>> Hi Shawn, I am not sure I fully understand the problem. The xdebug
>>>>>> implementation doesn't make use of urls for path mapping. The only
>>>>>> time the url is used is when you launch the debugger for the first
>>>>>> time. This then invokes that url and turns on the xdebug cookie so
>>>>>> that the browser is then in debug mode. All interaction between
>>>>>> xdebug running in the web server and PDT is done by absolute file
>>>>>> name and this is what the path mapper uses. So you map the
>>>>>> absolute path in the web server to your workspace path in PDT.
>>>>>>
>>>>>> When you set a breakpoint in PDT, it can translate that to the
>>>>>> correct absolute path in your server and define the correct
>>>>>> breakpoint in the server. So if it is all the same code then that
>>>>>> breakpoint will fire and PDT will break.
>>>>>>
>>>>>> PDT autogenerates a path mapping based on the file you specify in
>>>>>> the web script launch and the file that gets executed when the url
>>>>>> is invoked. You can of course create your own path mappings when
>>>>>> you define the server.
>>>>>>
>>>>>> I hope this explanation helps.
>>>>>>
>>>>>> Dave Kelsey
>>>>>>
>>>>>>
>>>>>> Shawn Clark wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am wondering if it is possible to setup a PDT debug session to
>>>>>>> respond to multiple sub domains?
>>>>>>>
>>>>>>> I am working with an application that has ServerAlias' within a
>>>>>>> virtual host such that any number of sub domains call the same
>>>>>>> code so if I setup a breakpoint on a line of code it should break
>>>>>>> on any of the sub domains.
>>>>>>>
>>>>>>> Currently it doesn't look like it is possible due to the fact the
>>>>>>> the PHP Server configuration has a URL like http://domain.com/.
>>>>>>> What I would be looking for is something like
>>>>>>> http://*.domain.com/. Then in the path mapping it would just be
>>>>>>> one entry.
>>>>>>>
>>>>>>> --
>>>>>>> Shawn Clark

Re: PDT / Xdebug / Multiple sub domains [message #84692 is a reply to message #84678]

Mon, 24 November 2008 14:12

Eclipse User

Hi Shawn, it should work through the DBGp proxy. I thought I tested the code through a proxy so will
be interested to hear any feedback you have.

Regards
Dave Kelsey

Shawn Clark wrote:
> Thanks for that bit of info and I will try it tonight on my dev setup
> there.
>
> I am guessing this would not work if I have a proxy setup? Right now at
> work we have a proxy setup so that multiple developers can debug web
> sites on our development server. If xdebug is contacting the IDE through
> JIT it would fail if it is going to the proxy?
>
> --
> Shawn Clark
>
> Dave Kelsey wrote:
>> Shawn, are you using PDT 2.0 builds ? If you are then you could make
>> use of the JIT debugging facility in PDT 2.0.
>>
>> This allows your web server to initiate the debug session rather than
>> PDT. You could then enter the URL yourself in firefox and so long as
>> xdebug sees a cookie it will initiate a debug session and PDT will
>> automatically create a launch for you.
>>
>> I think the default for "Accept Remote Session (JIT)" is off be
>> default so you will need to enable it.
>>
>> Dave Kelsey
>>
>>
>>
>> Shawn Clark wrote:
>>> Well I got a version of the Xdebug Firefox plugin to work on
>>> sub-domains and even added a quick checkbox to create the cookies for
>>> sub-domains. Only problem now is that by default Xdebug will create a
>>> cookie only for the primary domain when Eclipse opens up the page
>>> with the start information in the URL. For now what I have been doing
>>> is using the plugin to create the cookie before starting the Eclipse
>>> debug session so that the Xdebug server isn't writing the primary
>>> domain cookie and the browser keeps the sub-domain one.
>>>
>>> Might have to look into PDT a bit and see if I can setup an option so
>>> that when I am starting a debug session within Eclipse it can load
>>> the page in the web browser without sending the starting Xdebug
>>> parameters. A couple times I have forgotten to set the cookie with
>>> the add-on then once it has been created with Eclipse I have to go
>>> and delete that cookie and create another with the wildcard sub-domain.
>>>
>>> --
>>> Shawn Clark
>>>
>>> P.S. trying to figure out how to package up the Firefox plugin so
>>> that other people can use it. Right now I just modified the code
>>> within the firefox extensions folder.
>>>
>>> Dave Kelsey wrote:
>>>> Hi Shawn, a good bit of detective work there. You may want to see
>>>> what the author of xdebug thinks. Suggest you go over to
>>>> http://www.xdebug.org which should give details on the xdebug
>>>> mailing list as well as how to raise bugs and feature requests for
>>>> xdebug.
>>>>
>>>> Would be great as well if you could report back on how you got on
>>>> with the xdebug firefox extension.
>>>>
>>>> Regards
>>>> Dave Kelsey
>>>>
>>>> Shawn Clark wrote:
>>>>> Just tested and it is indeed a problem with the cookie. Within my
>>>>> application I have some site wide cookies setup so that the host is
>>>>> .domain.com where the first . is to signify all sub-domains. What I
>>>>> did was edit my XDEBUG_SESSION cookie once it was created to add
>>>>> the . in the front and now I can debug all sub-domains.
>>>>>
>>>>> So my question now is can one or the other of the following be made
>>>>> available:
>>>>>
>>>>> - Can a flag be set within the Xdebug php.ini settings to allow a
>>>>> wild card sub-domain cookie instead of the domain itself
>>>>> - Can a URL argument be passed along with the XDEBUG_SESSION_START
>>>>> to state that it is for all sub-domains
>>>>> - With this option a setting would need to be added to the Xdebug
>>>>> server configuration within PDT to tell which PHP server
>>>>> configurations can pass that argument
>>>>>
>>>>> If time is of concern then I can look at making the change to PDT
>>>>> if someone is able to help with the Xdebug side of things. I did
>>>>> notice there is a Firefox add-on to enable Xdebug for a specific
>>>>> page. I am going to look at extending that add-on to do multiple
>>>>> sub-domains as well as an interim solution.
>>>>>
>>>>> --
>>>>> Shawn Clark
>>>>>
>>>>>
>>>>> Shawn Clark wrote:
>>>>>> Ah... that is sort of what I was thinking but it wasn't working
>>>>>> and now I think I understand exactly what the problem is and it
>>>>>> isn't so much a problem with PDT as it is with Xdebug.
>>>>>>
>>>>>> When Eclipse loads the URL in the server configuration for the
>>>>>> debug session it passes along the information which Xdebug then
>>>>>> puts into a session cookie for the browser. The thing I am
>>>>>> guessing is happening is that the cookie is only for the current
>>>>>> domain and not any sub-domain of that domain. So when I am going
>>>>>> to a sub-domain the cookie isn't being passed to Xdebug and as
>>>>>> such Xdebug isn't relaying the absolute path information to the IDE.
>>>>>>
>>>>>> I am going to test now and will see if that is the case. I will
>>>>>> just watch where Xdebug tells the browser to assign the cookie. I
>>>>>> am guessing it is just for the main domain that is for the URL
>>>>>> that is set in Eclipse.
>>>>>>
>>>>>> --
>>>>>> Shawn Clark
>>>>>>
>>>>>> Dave wrote:
>>>>>>> Hi Shawn, I am not sure I fully understand the problem. The
>>>>>>> xdebug implementation doesn't make use of urls for path mapping.
>>>>>>> The only time the url is used is when you launch the debugger for
>>>>>>> the first time. This then invokes that url and turns on the
>>>>>>> xdebug cookie so that the browser is then in debug mode. All
>>>>>>> interaction between xdebug running in the web server and PDT is
>>>>>>> done by absolute file name and this is what the path mapper uses.
>>>>>>> So you map the absolute path in the web server to your workspace
>>>>>>> path in PDT.
>>>>>>>
>>>>>>> When you set a breakpoint in PDT, it can translate that to the
>>>>>>> correct absolute path in your server and define the correct
>>>>>>> breakpoint in the server. So if it is all the same code then that
>>>>>>> breakpoint will fire and PDT will break.
>>>>>>>
>>>>>>> PDT autogenerates a path mapping based on the file you specify in
>>>>>>> the web script launch and the file that gets executed when the
>>>>>>> url is invoked. You can of course create your own path mappings
>>>>>>> when you define the server.
>>>>>>>
>>>>>>> I hope this explanation helps.
>>>>>>>
>>>>>>> Dave Kelsey
>>>>>>>
>>>>>>>
>>>>>>> Shawn Clark wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I am wondering if it is possible to setup a PDT debug session to
>>>>>>>> respond to multiple sub domains?
>>>>>>>>
>>>>>>>> I am working with an application that has ServerAlias' within a
>>>>>>>> virtual host such that any number of sub domains call the same
>>>>>>>> code so if I setup a breakpoint on a line of code it should
>>>>>>>> break on any of the sub domains.
>>>>>>>>
>>>>>>>> Currently it doesn't look like it is possible due to the fact
>>>>>>>> the the PHP Server configuration has a URL like
>>>>>>>> http://domain.com/. What I would be looking for is something
>>>>>>>> like http://*.domain.com/. Then in the path mapping it would
>>>>>>>> just be one entry.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Shawn Clark

Re: PDT / Xdebug / Multiple sub domains [message #84915 is a reply to message #84692]

Thu, 27 November 2008 12:33

Eclipse User

Hi Dave,

What settings do I specifically need in the php.ini for Xdebug to do
JIT? I was looking through the documentation and see one setting about
xdebug.remote_mode where it can be "req" or "jit". By the description on
http://www.xdebug.org/docs/all_settings it doesn't sound like the right
option though as it says it will only connect on errors. The other
setting I see is xdebug.remote_autostart.

One of my questions about the JIT is that Eclipse has to register itself
with the proxy so that when the server contacts the proxy it knows where
to send the request. The thing is in my DBGp logs I don't see any
proxy_init or other requests in the log when Eclipse starts up. So how
does the request get routed properly?

--
Shawn Clark

Dave Kelsey wrote:
> Hi Shawn, it should work through the DBGp proxy. I thought I tested the
> code through a proxy so will be interested to hear any feedback you have.
>
> Regards
> Dave Kelsey
>
> Shawn Clark wrote:
>> Thanks for that bit of info and I will try it tonight on my dev setup
>> there.
>>
>> I am guessing this would not work if I have a proxy setup? Right now
>> at work we have a proxy setup so that multiple developers can debug
>> web sites on our development server. If xdebug is contacting the IDE
>> through JIT it would fail if it is going to the proxy?
>>
>> --
>> Shawn Clark
>>
>> Dave Kelsey wrote:
>>> Shawn, are you using PDT 2.0 builds ? If you are then you could make
>>> use of the JIT debugging facility in PDT 2.0.
>>>
>>> This allows your web server to initiate the debug session rather than
>>> PDT. You could then enter the URL yourself in firefox and so long as
>>> xdebug sees a cookie it will initiate a debug session and PDT will
>>> automatically create a launch for you.
>>>
>>> I think the default for "Accept Remote Session (JIT)" is off be
>>> default so you will need to enable it.
>>>
>>> Dave Kelsey
>>>
>>>
>>>
>>> Shawn Clark wrote:
>>>> Well I got a version of the Xdebug Firefox plugin to work on
>>>> sub-domains and even added a quick checkbox to create the cookies
>>>> for sub-domains. Only problem now is that by default Xdebug will
>>>> create a cookie only for the primary domain when Eclipse opens up
>>>> the page with the start information in the URL. For now what I have
>>>> been doing is using the plugin to create the cookie before starting
>>>> the Eclipse debug session so that the Xdebug server isn't writing
>>>> the primary domain cookie and the browser keeps the sub-domain one.
>>>>
>>>> Might have to look into PDT a bit and see if I can setup an option
>>>> so that when I am starting a debug session within Eclipse it can
>>>> load the page in the web browser without sending the starting Xdebug
>>>> parameters. A couple times I have forgotten to set the cookie with
>>>> the add-on then once it has been created with Eclipse I have to go
>>>> and delete that cookie and create another with the wildcard sub-domain.
>>>>
>>>> --
>>>> Shawn Clark
>>>>
>>>> P.S. trying to figure out how to package up the Firefox plugin so
>>>> that other people can use it. Right now I just modified the code
>>>> within the firefox extensions folder.
>>>>
>>>> Dave Kelsey wrote:
>>>>> Hi Shawn, a good bit of detective work there. You may want to see
>>>>> what the author of xdebug thinks. Suggest you go over to
>>>>> http://www.xdebug.org which should give details on the xdebug
>>>>> mailing list as well as how to raise bugs and feature requests for
>>>>> xdebug.
>>>>>
>>>>> Would be great as well if you could report back on how you got on
>>>>> with the xdebug firefox extension.
>>>>>
>>>>> Regards
>>>>> Dave Kelsey
>>>>>
>>>>> Shawn Clark wrote:
>>>>>> Just tested and it is indeed a problem with the cookie. Within my
>>>>>> application I have some site wide cookies setup so that the host
>>>>>> is .domain.com where the first . is to signify all sub-domains.
>>>>>> What I did was edit my XDEBUG_SESSION cookie once it was created
>>>>>> to add the . in the front and now I can debug all sub-domains.
>>>>>>
>>>>>> So my question now is can one or the other of the following be
>>>>>> made available:
>>>>>>
>>>>>> - Can a flag be set within the Xdebug php.ini settings to allow a
>>>>>> wild card sub-domain cookie instead of the domain itself
>>>>>> - Can a URL argument be passed along with the XDEBUG_SESSION_START
>>>>>> to state that it is for all sub-domains
>>>>>> - With this option a setting would need to be added to the
>>>>>> Xdebug server configuration within PDT to tell which PHP server
>>>>>> configurations can pass that argument
>>>>>>
>>>>>> If time is of concern then I can look at making the change to PDT
>>>>>> if someone is able to help with the Xdebug side of things. I did
>>>>>> notice there is a Firefox add-on to enable Xdebug for a specific
>>>>>> page. I am going to look at extending that add-on to do multiple
>>>>>> sub-domains as well as an interim solution.
>>>>>>
>>>>>> --
>>>>>> Shawn Clark
>>>>>>
>>>>>>
>>>>>> Shawn Clark wrote:
>>>>>>> Ah... that is sort of what I was thinking but it wasn't working
>>>>>>> and now I think I understand exactly what the problem is and it
>>>>>>> isn't so much a problem with PDT as it is with Xdebug.
>>>>>>>
>>>>>>> When Eclipse loads the URL in the server configuration for the
>>>>>>> debug session it passes along the information which Xdebug then
>>>>>>> puts into a session cookie for the browser. The thing I am
>>>>>>> guessing is happening is that the cookie is only for the current
>>>>>>> domain and not any sub-domain of that domain. So when I am going
>>>>>>> to a sub-domain the cookie isn't being passed to Xdebug and as
>>>>>>> such Xdebug isn't relaying the absolute path information to the IDE.
>>>>>>>
>>>>>>> I am going to test now and will see if that is the case. I will
>>>>>>> just watch where Xdebug tells the browser to assign the cookie. I
>>>>>>> am guessing it is just for the main domain that is for the URL
>>>>>>> that is set in Eclipse.
>>>>>>>
>>>>>>> --
>>>>>>> Shawn Clark
>>>>>>>
>>>>>>> Dave wrote:
>>>>>>>> Hi Shawn, I am not sure I fully understand the problem. The
>>>>>>>> xdebug implementation doesn't make use of urls for path mapping.
>>>>>>>> The only time the url is used is when you launch the debugger
>>>>>>>> for the first time. This then invokes that url and turns on the
>>>>>>>> xdebug cookie so that the browser is then in debug mode. All
>>>>>>>> interaction between xdebug running in the web server and PDT is
>>>>>>>> done by absolute file name and this is what the path mapper
>>>>>>>> uses. So you map the absolute path in the web server to your
>>>>>>>> workspace path in PDT.
>>>>>>>>
>>>>>>>> When you set a breakpoint in PDT, it can translate that to the
>>>>>>>> correct absolute path in your server and define the correct
>>>>>>>> breakpoint in the server. So if it is all the same code then
>>>>>>>> that breakpoint will fire and PDT will break.
>>>>>>>>
>>>>>>>> PDT autogenerates a path mapping based on the file you specify
>>>>>>>> in the web script launch and the file that gets executed when
>>>>>>>> the url is invoked. You can of course create your own path
>>>>>>>> mappings when you define the server.
>>>>>>>>
>>>>>>>> I hope this explanation helps.
>>>>>>>>
>>>>>>>> Dave Kelsey
>>>>>>>>
>>>>>>>>
>>>>>>>> Shawn Clark wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I am wondering if it is possible to setup a PDT debug session
>>>>>>>>> to respond to multiple sub domains?
>>>>>>>>>
>>>>>>>>> I am working with an application that has ServerAlias' within a
>>>>>>>>> virtual host such that any number of sub domains call the same
>>>>>>>>> code so if I setup a breakpoint on a line of code it should
>>>>>>>>> break on any of the sub domains.
>>>>>>>>>
>>>>>>>>> Currently it doesn't look like it is possible due to the fact
>>>>>>>>> the the PHP Server configuration has a URL like
>>>>>>>>> http://domain.com/. What I would be looking for is something
>>>>>>>>> like http://*.domain.com/. Then in the path mapping it would
>>>>>>>>> just be one entry.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Shawn Clark

Re: PDT / Xdebug / Multiple sub domains [message #84931 is a reply to message #84915]

Thu, 27 November 2008 13:47

Eclipse User

Hi Shawn, to enable this feature you need to go to the debug preferences in PDT. So in Preferences
expand PHP and then debug and select installed debuggers. Double click on xdebug. There should be an
entry called "Accept remote session (JIT)". Change that to "Any" to allow any remote connection to
be accepted. This option is also required if you are going to use the JIT feature of xdebug but you
don't need to make any changes for xdebug in your case as accept remote session allows xdebug to
initiate the debug session so long as the cookie is set in your browser to tell xdebug to do so.

With respect to the proxy, what happens when you enable remote session support is that PDT will then
go off and register with the proxy at that point allowing the remotely initiated session to be
correctly routed.

Dave Kelsey

Shawn Clark wrote:
> Hi Dave,
>
> What settings do I specifically need in the php.ini for Xdebug to do
> JIT? I was looking through the documentation and see one setting about
> xdebug.remote_mode where it can be "req" or "jit". By the description on
> http://www.xdebug.org/docs/all_settings it doesn't sound like the right
> option though as it says it will only connect on errors. The other
> setting I see is xdebug.remote_autostart.
>
> One of my questions about the JIT is that Eclipse has to register itself
> with the proxy so that when the server contacts the proxy it knows where
> to send the request. The thing is in my DBGp logs I don't see any
> proxy_init or other requests in the log when Eclipse starts up. So how
> does the request get routed properly?
>
> --
> Shawn Clark
>
>
>

Re: PDT / Xdebug / Multiple sub domains [message #84946 is a reply to message #84931]

Thu, 27 November 2008 14:54

Eclipse User

See thats the thing. I do have the JIT option enabled in Eclipse (I
forgot to state that in my previous email). I just don't see Eclipse
trying to register itself with the proxy at any point before I start to
debug some web page.

--
Shawn Clark

Dave Kelsey wrote:
> Hi Shawn, to enable this feature you need to go to the debug preferences
> in PDT. So in Preferences expand PHP and then debug and select installed
> debuggers. Double click on xdebug. There should be an entry called
> "Accept remote session (JIT)". Change that to "Any" to allow any remote
> connection to be accepted. This option is also required if you are going
> to use the JIT feature of xdebug but you don't need to make any changes
> for xdebug in your case as accept remote session allows xdebug to
> initiate the debug session so long as the cookie is set in your browser
> to tell xdebug to do so.
>
> With respect to the proxy, what happens when you enable remote session
> support is that PDT will then go off and register with the proxy at that
> point allowing the remotely initiated session to be correctly routed.
>
> Dave Kelsey
>
> Shawn Clark wrote:
>> Hi Dave,
>>
>> What settings do I specifically need in the php.ini for Xdebug to do
>> JIT? I was looking through the documentation and see one setting about
>> xdebug.remote_mode where it can be "req" or "jit". By the description
>> on http://www.xdebug.org/docs/all_settings it doesn't sound like the
>> right option though as it says it will only connect on errors. The
>> other setting I see is xdebug.remote_autostart.
>>
>> One of my questions about the JIT is that Eclipse has to register
>> itself with the proxy so that when the server contacts the proxy it
>> knows where to send the request. The thing is in my DBGp logs I don't
>> see any proxy_init or other requests in the log when Eclipse starts
>> up. So how does the request get routed properly?
>>
>> --
>> Shawn Clark
>>
>>
>>

Re: PDT / Xdebug / Multiple sub domains [message #84961 is a reply to message #84946]

Thu, 27 November 2008 15:08

Eclipse User

The registration occurs when you press ok. It could be that it isn't working quite right try turning
off the proxy by deselecting the use proxy, press ok, then go back in and re-enable use proxy and
press ok and see if that works.

If it does, then it is possible the sequence you used for some reason didn't trigger the
registration or you were already registered with a proxy of course.

If nothing works, let me know which version of PDT 2.0 you are using and I will give it a go as well.

Cheers
Dave Kelsey

Shawn Clark wrote:
> See thats the thing. I do have the JIT option enabled in Eclipse (I
> forgot to state that in my previous email). I just don't see Eclipse
> trying to register itself with the proxy at any point before I start to
> debug some web page.
>
> --
> Shawn Clark
>
> Dave Kelsey wrote:
>> Hi Shawn, to enable this feature you need to go to the debug
>> preferences in PDT. So in Preferences expand PHP and then debug and
>> select installed debuggers. Double click on xdebug. There should be an
>> entry called "Accept remote session (JIT)". Change that to "Any" to
>> allow any remote connection to be accepted. This option is also
>> required if you are going to use the JIT feature of xdebug but you
>> don't need to make any changes for xdebug in your case as accept
>> remote session allows xdebug to initiate the debug session so long as
>> the cookie is set in your browser to tell xdebug to do so.
>>
>> With respect to the proxy, what happens when you enable remote session
>> support is that PDT will then go off and register with the proxy at
>> that point allowing the remotely initiated session to be correctly
>> routed.
>>
>> Dave Kelsey
>>
>> Shawn Clark wrote:
>>> Hi Dave,
>>>
>>> What settings do I specifically need in the php.ini for Xdebug to do
>>> JIT? I was looking through the documentation and see one setting
>>> about xdebug.remote_mode where it can be "req" or "jit". By the
>>> description on http://www.xdebug.org/docs/all_settings it doesn't
>>> sound like the right option though as it says it will only connect on
>>> errors. The other setting I see is xdebug.remote_autostart.
>>>
>>> One of my questions about the JIT is that Eclipse has to register
>>> itself with the proxy so that when the server contacts the proxy it
>>> knows where to send the request. The thing is in my DBGp logs I don't
>>> see any proxy_init or other requests in the log when Eclipse starts
>>> up. So how does the request get routed properly?
>>>
>>> --
>>> Shawn Clark
>>>
>>>
>>>

Re: PDT / Xdebug / Multiple sub domains [message #85000 is a reply to message #84961]

Thu, 27 November 2008 17:26

Eclipse User

My findings:

When starting up Eclipse the IDE is not auto-registering itself with the
proxy. Once I change to enable / disable either the proxy or the JIT
then the IDE will register itself.

Once registered the Xdebug server will send the JIT request through the
proxy to Eclipse and I get a debug session that starts up. The problem I
am finding is that I have multiple PHP Servers setup and for some reason
the PDT can't figure out which server to use and as such is not able to
show the file being debugged. What it looks like is that it doesn't know
how to correlate the incoming file path with the PHP server list to
startup the proper debug session. Within the Debug view the session is
shown as "unknown" where it would normally be the name of the server
that I setup in the PHP Servers section.

So 90% there but still a bit to go. If there is anything I can do to
help make it work better please let me know.

--
Shawn Clark

Dave Kelsey wrote:
> The registration occurs when you press ok. It could be that it isn't
> working quite right try turning off the proxy by deselecting the use
> proxy, press ok, then go back in and re-enable use proxy and press ok
> and see if that works.
>
> If it does, then it is possible the sequence you used for some reason
> didn't trigger the registration or you were already registered with a
> proxy of course.
>
> If nothing works, let me know which version of PDT 2.0 you are using and
> I will give it a go as well.
>
> Cheers
> Dave Kelsey
>
> Shawn Clark wrote:
>> See thats the thing. I do have the JIT option enabled in Eclipse (I
>> forgot to state that in my previous email). I just don't see Eclipse
>> trying to register itself with the proxy at any point before I start
>> to debug some web page.
>>
>> --
>> Shawn Clark
>>
>> Dave Kelsey wrote:
>>> Hi Shawn, to enable this feature you need to go to the debug
>>> preferences in PDT. So in Preferences expand PHP and then debug and
>>> select installed debuggers. Double click on xdebug. There should be
>>> an entry called "Accept remote session (JIT)". Change that to "Any"
>>> to allow any remote connection to be accepted. This option is also
>>> required if you are going to use the JIT feature of xdebug but you
>>> don't need to make any changes for xdebug in your case as accept
>>> remote session allows xdebug to initiate the debug session so long as
>>> the cookie is set in your browser to tell xdebug to do so.
>>>
>>> With respect to the proxy, what happens when you enable remote
>>> session support is that PDT will then go off and register with the
>>> proxy at that point allowing the remotely initiated session to be
>>> correctly routed.
>>>
>>> Dave Kelsey
>>>
>>> Shawn Clark wrote:
>>>> Hi Dave,
>>>>
>>>> What settings do I specifically need in the php.ini for Xdebug to do
>>>> JIT? I was looking through the documentation and see one setting
>>>> about xdebug.remote_mode where it can be "req" or "jit". By the
>>>> description on http://www.xdebug.org/docs/all_settings it doesn't
>>>> sound like the right option though as it says it will only connect
>>>> on errors. The other setting I see is xdebug.remote_autostart.
>>>>
>>>> One of my questions about the JIT is that Eclipse has to register
>>>> itself with the proxy so that when the server contacts the proxy it
>>>> knows where to send the request. The thing is in my DBGp logs I
>>>> don't see any proxy_init or other requests in the log when Eclipse
>>>> starts up. So how does the request get routed properly?
>>>>
>>>> --
>>>> Shawn Clark
>>>>
>>>>
>>>>

Re: PDT / Xdebug / Multiple sub domains [message #85015 is a reply to message #85000]

Thu, 27 November 2008 18:12

Eclipse User

Hi Shawn, I will look into why it is not registering when eclipse is started. In the case where
remote session is not used, that should be the case. Registration only occurs on the first web
launch, but if remote session is enabled, then it really should register when eclipse is started.

As for the the other issues :-
- I expect the launch to say unknown. Because of the way I create a debug target in this manner it
is not easy to actually give the launch a meaningful name and I rely on a "feature" of eclipse to
not see the target in its real form. So it appears as unknown. It probably is possible to change
this but requires a lot of code to achieve it. So I decided to live with this for now.

- when an inbound session comes in I get the name of the file on the server from xdebug, but I don't
really know which file to associate that with in the workspace. It could attempt to look up the
server in the list of servers but as I don't know what port was invoked at the server end for
example then it may choose the wrong server definition and path mapping. What should happen is that
the path mapper dialog should be presented which allows the user to select what file should be
selected. It should say the name of the server file and you should be able to choose the appropriate
file in the workspace or file system. Once you choose, PDT will then compute the path map so that
while you debug other files within that debug session that was launched on your behalf you don't
need to select which file it should be.

So were you not prompted to select a file ? If you weren't then it should have done and maybe
something has changed since I implemented this, as I don't own the path mapper code, a change may
have occurred.

Many thanks for your feedback on this
Dave Kelsey

Shawn Clark wrote:
> My findings:
>
> When starting up Eclipse the IDE is not auto-registering itself with the
> proxy. Once I change to enable / disable either the proxy or the JIT
> then the IDE will register itself.
>
> Once registered the Xdebug server will send the JIT request through the
> proxy to Eclipse and I get a debug session that starts up. The problem I
> am finding is that I have multiple PHP Servers setup and for some reason
> the PDT can't figure out which server to use and as such is not able to
> show the file being debugged. What it looks like is that it doesn't know
> how to correlate the incoming file path with the PHP server list to
> startup the proper debug session. Within the Debug view the session is
> shown as "unknown" where it would normally be the name of the server
> that I setup in the PHP Servers section.
>
> So 90% there but still a bit to go. If there is anything I can do to
> help make it work better please let me know.
>
> --
> Shawn Clark

Re: PDT / Xdebug / Multiple sub domains [message #85045 is a reply to message #85015]

Thu, 27 November 2008 20:06

Eclipse User

Thanks for the information. That all makes sense as to what I am seeing.
When the JIT started there was nothing about asking which file to map it
to or any selection. It just showed the editor with the file:line number
in the tab label and the error that it couldn't find the source in the
editor content section.

For some background into my workspace setup:

Multiple projects
- project1 -> php server of project1.dev with path mapping of
/home/myaccount/project1/wwwroot to project1
- project2 -> php server of project2.dev with path mapping of
/home/myaccount/project2/wwwroot to project2
- project3 -> php server of project3.dev (hosted on another machine)
with path mapping of /home/myaccount/project3/wwwroot to project3

When doing the JIT debug session the error is that
/home/myaccount/project1/wwwroot/index.php could not be mapped.

When I am talking about PHP Server's that is within the Preferences ->
PHP -> PHP Servers. Another thing that I have setup is PHP Web Site's to
do debugging the other way (by request). I am not sure if this is how
other people are doing their debugging but what I have setup is under
"Debug Configuration" dialog in the PHP Web Page section I have created
a configuration for each of the described projects above. I am guessing
this isn't important for JIT as this is just used to start up the xdebug
session through the browser request.

I am using the latest PDT 2.0 I20081127. Again if there is anything I
can do to help make this work better please let me know. I am still
working on making the Xdebug plugin better to tie in with a JIT debug setup.

--
Shawn Clark

Dave Kelsey wrote:
> Hi Shawn, I will look into why it is not registering when eclipse is
> started. In the case where remote session is not used, that should be
> the case. Registration only occurs on the first web launch, but if
> remote session is enabled, then it really should register when eclipse
> is started.
>
> As for the the other issues :-
> - I expect the launch to say unknown. Because of the way I create a
> debug target in this manner it is not easy to actually give the launch a
> meaningful name and I rely on a "feature" of eclipse to not see the
> target in its real form. So it appears as unknown. It probably is
> possible to change this but requires a lot of code to achieve it. So I
> decided to live with this for now.
>
> - when an inbound session comes in I get the name of the file on the
> server from xdebug, but I don't really know which file to associate that
> with in the workspace. It could attempt to look up the server in the
> list of servers but as I don't know what port was invoked at the server
> end for example then it may choose the wrong server definition and path
> mapping. What should happen is that the path mapper dialog should be
> presented which allows the user to select what file should be selected.
> It should say the name of the server file and you should be able to
> choose the appropriate file in the workspace or file system. Once you
> choose, PDT will then compute the path map so that while you debug other
> files within that debug session that was launched on your behalf you
> don't need to select which file it should be.
>
> So were you not prompted to select a file ? If you weren't then it
> should have done and maybe something has changed since I implemented
> this, as I don't own the path mapper code, a change may have occurred.
>
> Many thanks for your feedback on this
> Dave Kelsey
>
> Shawn Clark wrote:
>> My findings:
>>
>> When starting up Eclipse the IDE is not auto-registering itself with
>> the proxy. Once I change to enable / disable either the proxy or the
>> JIT then the IDE will register itself.
>>
>> Once registered the Xdebug server will send the JIT request through
>> the proxy to Eclipse and I get a debug session that starts up. The
>> problem I am finding is that I have multiple PHP Servers setup and for
>> some reason the PDT can't figure out which server to use and as such
>> is not able to show the file being debugged. What it looks like is
>> that it doesn't know how to correlate the incoming file path with the
>> PHP server list to startup the proper debug session. Within the Debug
>> view the session is shown as "unknown" where it would normally be the
>> name of the server that I setup in the PHP Servers section.
>>
>> So 90% there but still a bit to go. If there is anything I can do to
>> help make it work better please let me know.
>>
>> --
>> Shawn Clark

Re: PDT / Xdebug / Multiple sub domains [message #85090 is a reply to message #85045]

Fri, 28 November 2008 05:30

Eclipse User

Hi Shawn, thanks very much for your feedback here. It was very useful. I have posted a message on
the newsgroup regarding the current state of the remote session facility. I have also hopefully
addressed the issue where PDT doesn't register with the proxy at startup if the Remote Session
support is enabled.

I don't know when any next integration or milestone build is scheduled but I hope these code changes
will get into the nightly builds from today (who knows).

Regards
Dave Kelsey

Shawn Clark wrote:
> Thanks for the information. That all makes sense as to what I am seeing.
> When the JIT started there was nothing about asking which file to map it
> to or any selection. It just showed the editor with the file:line number
> in the tab label and the error that it couldn't find the source in the
> editor content section.
>
> For some background into my workspace setup:
>
> Multiple projects
> - project1 -> php server of project1.dev with path mapping of
> /home/myaccount/project1/wwwroot to project1
> - project2 -> php server of project2.dev with path mapping of
> /home/myaccount/project2/wwwroot to project2
> - project3 -> php server of project3.dev (hosted on another machine)
> with path mapping of /home/myaccount/project3/wwwroot to project3
>
> When doing the JIT debug session the error is that
> /home/myaccount/project1/wwwroot/index.php could not be mapped.
>
> When I am talking about PHP Server's that is within the Preferences ->
> PHP -> PHP Servers. Another thing that I have setup is PHP Web Site's to
> do debugging the other way (by request). I am not sure if this is how
> other people are doing their debugging but what I have setup is under
> "Debug Configuration" dialog in the PHP Web Page section I have created
> a configuration for each of the described projects above. I am guessing
> this isn't important for JIT as this is just used to start up the xdebug
> session through the browser request.
>
> I am using the latest PDT 2.0 I20081127. Again if there is anything I
> can do to help make this work better please let me know. I am still
> working on making the Xdebug plugin better to tie in with a JIT debug
> setup.
>
> --
> Shawn Clark
>
>

Previous Topic:	XDebug and Remote Session initiation (JIT) Support
Next Topic:	Remote debugging question

Goto Forum:

-=] Back to Top [=-

Current Time: Fri Jul 18 06:20:55 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter