views:

528

answers:

6

I have an n-tier system where a frontend templating layer makes calls out to a backend application server. For instance, I need to retrieve some search results, and the frontend calls the backend to get the results.

Both the templating engine and the appserver are written in PHP. I currently use PHPed to initiate debug sessions to the templating engine, however, when the http request goes out to remote service my debugger just sits and waits for the IO to complete.

What I would like to do is emulate the HTTP call but really just stay inside my PHP process, do a giant push of the environment onto some kind of stack, then have my appserver environment load and process the call. After the call is done, I do an env pop, and get the results of the http call in a var (for instance, via an output buffer). I can run both services on the same server. Does anyone have any ideas or libraries that already do this?

+2  A: 

Can you not run a debugger and set a breakpoint in the appserver too? Two different debug sessions - one to trap the templating engine call and one to trap the call in the appserver.

You should be able to trace the output from the appserver in the templating engine debugging session.

If it is not possible to run two debug sessions then create some test inputs for the appserver by capturing outputs from the templating engine and use a single debugger with your test appserver inputs.

Steve Claridge
Good idea... In PHPed at least, the debug engine passes a debug ID so the called process can "phone home" to the IDE. I will see if I can figure out a way to have that debugID passed along on the second call, and maybe I can get the debuggger to spark a new session.
Zak
+1  A: 

This is embarrassingly crude, and quite free of any study of how the debugger works, but have you tried adding

    debugBreak();

at the entry points to your called routine? (Assuming both processes running on the same machine).

I have used this technique to break back into a process called via AMFPHP. I have had a PHP file loading Flash file into browser, which then calls back to PHP using AMFPHP, all on the same server. When I hit the debugBreak() line, PhpED regains control.

willw
+1  A: 

Why don't you use an HTTP sniffer? Something like tcpflow.

Alternatively, you could just log the complete XML to a file for each request & response.

Unfortunately it's not clear from your question what you're trying to achieve so these are just guesses. You should probably state more clearly exactly what problem you're trying to solve.

You could possibly re-factor your code that calls out to the remove service and use dependency injection and mocks. That would allow you to isolate the development of the front-end with the back by suppling "mocked" but valid data.

Hope that helps.

apinstein
+1  A: 

Can I assume you're talking about the lack of threads in PHP, so the service stops the flow of your program and halts the debugger? There's ways around it, but they are hard, cumbersome and hackish.

For example, if you use a framework like Zend for the HTTP traffic, you can hack the HTTP class to use primitive sockets for the service reading/writing instead of the built-in stuff, and create a small task switcher (loop :) to track what's going on.

You could of course use fopen ( 'http://...' ) and fread in chunks in a loop as well, that could do the trick, but you need http: support in streams turned on.

AlexanderJohannesen
+1  A: 
Jeffrey Knight
+1  A: 

This is not open source, but check out Charles. It works as a proxy, and is the best debugging proxy I've seen to date. It works on linux, os/x and windows.

Pretty much any HTTP library will allow you to specify a proxy.

Evert