One of the things I have always liked with working in ColdFusion is the ability to derive detailed debugging information. You get a good idea of what is going behind the covers and do have a good basis to hunt down bugs.
Unfortunatly, this all breaks down when you start to do any kind of remoting (invoking CFCs from another technology). Currently, this is for Flex and SOAP (Webservices) type calls. If anything goes haywire, or the calls themselves are complex, e.g. call on many other components and tags you fly in the dark more often then not.
The common response to this kind of issue from peers is to use the line debugger, set breakpoints etc. and this does work to a certain degree.
However, where I get a little agitated is that most of the time when problems occur you are nowhere near a line-debugger or IDE to capture the processing.
For standard .cfm pages I can use the Silent Debugger option.
So I was wondering if I could build something similar that worked with CFCs and remoting. I would add this to the Application.cfc and, bingo, I could capture the debugging output to file. Alas, many hours later I had nothing workable. To make a long story short it does not look like there is a way to capture cfc debug output, because no debugging session is seems running.
Unfortunatly, it looks like the auto-wiring that ColdFusion performs makes the decision not to initialize / start a degugging session in the ServiceFactory (coldfusion.server.ServiceFactory).
Thus the call for factory.getDebuggingService() will fail and my attempts to manualy start the debugging service failed for lack of insight into how CF actually does this (what classes and method in what order).
So I was back to square one.
After a little more thinking and tinkering I decided to go for the workaround solution. This happens to be practical enough for me as my remoted cfcs are only stubs, so not much functionality is implemented there.
I have several stub types and, thus, decided to rewrite the call from SOAP / FLEX remoted calls to HTTP Post (REST) calls.
So in the remoted call I would just turnaround and call the REST gateway if I detected that we were trying to debug stuff using the IsDebugMode() function.
This would allow me to use the Silent Debugging option and capture the debug output to file even for calls coming from SOAP and FLEX remoting. I would also need to translate the reponse back correctly for FLEX and SOAP clients to consume.
All this is more overhead but not drastically so, while allowing me to trace errors while they occur even for remoted CFCs. I can access this information afterwards for analysis.
Overall, I am disapointed that I was not able to hook into native CF processes to expose debugging results. Maybe in future iterations this will be possible. However, being able to get this insight is invaluable to me.
Feel free to experiment.
Cheers,
B.
No comments:
Post a Comment