Imagine the times when Flash Builder (Gumbo) was still in beta, times when the Network Monitor was still only a twinkle in the corner of a Flex engineer's eye. Imagine... your current day job, and a Flex 3 project with a bit of ColdFusion powered Remoting (other Remoting gateways are available) thrown in. Which is going wrong. And you need to debug the Remoting calls.
Ok, that doesn't require much imagination, I know. We know that Flash Builder will make our lives somewhat easier when it finally ships, but in the meantime your boss doesn't allow you to run beta software so what does one do besides coming to work for me? And maybe, just maybe, your boss is really mean (unlike myself) and won't even pay out for a license of Charles. So now what?
I present to you
So what does TraceTarget do? In a nutshell it outputs a ton of logging information into your Console when you debug your Flex project, and in particular it tells you a lot about the Remoting calls that you are undoubtedly making. Here's an example of my current project, first without TraceTarget added:
2result getUserDetails
2'9670B130-68C5-3D75-D251-3D30C4A99F2E' producer set destination to 'ColdFusion'.
3'F2AF48B3-896A-FA9D-D77A-3D30C4AF2A71' producer set destination to 'ColdFusion'.
4'8495032E-7DE7-49B1-124E-3D30C4EB0643' producer set destination to 'ColdFusion'.
5'8495032E-7DE7-49B1-124E-3D30C4EB0643' producer sending message '17E7B79A-6D4E-21C3-4F67-3D30C4EE538F'
6'my-cfamf' channel endpoint set to http://www.demo.com/flex2gateway/
7'my-cfamf' channel settings are:
8<channel id="my-cfamf" type="mx.messaging.channels.AMFChannel">
9 <endpoint uri="http://www.demo.com/flex2gateway/"/>
10 <properties>
11 <polling-enabled>false</polling-enabled>
12 </properties>
13</channel>
14'my-cfamf' pinging endpoint.
15'my-cfamf' channel is connected.
16'my-cfamf' channel sending message:
17(mx.messaging.messages::RemotingMessage)#0
18 body = (Array)#1
19 [0] "abcd"
20 clientId = (null)
21 destination = "ColdFusion"
22 headers = (Object)#2
23 messageId = "17E7B79A-6D4E-21C3-4F67-3D30C4EE538F"
24 operation = "getRoomDetails"
25 source = "api.v1.private.rooms"
26 timestamp = 0
27 timeToLive = 0
28'8495032E-7DE7-49B1-124E-3D30C4EB0643' producer connected.
29'8495032E-7DE7-49B1-124E-3D30C4EB0643' producer acknowledge of '17E7B79A-6D4E-21C3-4F67-3D30C4EE538F'.
301
31'9670B130-68C5-3D75-D251-3D30C4A99F2E' producer sending message '01B287E5-5EF5-1B40-75EE-3D30C648A026'
32'9670B130-68C5-3D75-D251-3D30C4A99F2E' producer connected.
33'my-cfamf' channel sending message:
34(mx.messaging.messages::RemotingMessage)#0
35 body = (Array)#1
36 clientId = (null)
37 destination = "ColdFusion"
38 headers = (Object)#2
39 messageId = "01B287E5-5EF5-1B40-75EE-3D30C648A026"
40 operation = "getUserDetails"
41 source = "api.v1.private.users"
42 timestamp = 0
43 timeToLive = 0
44'9670B130-68C5-3D75-D251-3D30C4A99F2E' producer acknowledge of '01B287E5-5EF5-1B40-75EE-3D30C648A026'.
45result getUserDetails
Pretty cool, right? You can read more about TraceTarget and other logging frameworks here. But if you just want a quick and dirty way to see some more debug info on your Remoting calls then you could do worse than simply sticking the TraceTarget tag into your main.mxml file and save yourself some hassle. It may not be as slick as Charles or the upcoming Network Monitor but it can be handy nevertheless. Have fun coding.

#1 by creacog on 8/22/09 - 5:40 PM
Just remember to comment-out the TraceTarget tag before deploying a release build - either manually or employ conditional compilation...
http://tinyurl.com/6l8paa
#2 by Jodie O'Rourke on 8/24/09 - 11:01 AM
#3 by creacog on 8/24/09 - 2:37 PM
I just double-checked my position by actually doing it.
If you simply "Export release build" then double-click the bin-release SWF to play within Flash player within the Flash IDE - you will see all the logging information traced to the Output panel. Flash Builder 4 beta.
Adding debug=false to compiler arguments does not 'omit trace'
There is a feature request here of relevance...
http://bugs.adobe.com/jira/browse/FB-11681
#4 by Jodie O'Rourke on 8/25/09 - 11:00 AM
That's a bit poor - separating debug from trace on the compiler args. I stand corrected!
We have an embargo on its use here as it just clutters the console; but just in case, our build script will remove trace() statements. I guess anyone who's really worried about trace statements 'leaking' into live will have a validation script run over their code prior to build/deploy... and like you say, conditional compilation is another water-tight way of preventing slip-ups.
Thanks for the info.
#5 by Anuj Gakhar on 7/2/10 - 2:00 PM
#6 by Anuj Gakhar on 7/2/10 - 2:02 PM