<mx:TraceTarget level="0"> is the MXML tag that maps to the mx.logging.targets.TraceTarget class. This is just one implementation of the ILoggingTarget API that happens to use the Flash Player trace() API.
As you noticed, trace() only works with the debug Flash Player... but you don't have to actually "debug" to see this output (although that is a common way to do so because of Flex Builder's Console panel records this output too). The other way is to setup mm.cfg in your OS user directory to write out trace info to flashlog.txt. See: http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_19323 But be careful of older comments in articles like this about the property TraceOutputFileName - you can no longer customize the location of flashlog.txt. That is, from FP9 onwards this file appears in a fixed location and cannot be customized. e.g. on typical Windows XP installation, the latest player writes to: C:\Documents and Settings\username\Application Data\Macromedia\Flash Player\Logs\flashlog.txt If you just use <mx:TraceTarget level="0"> you'll get all events for all categories. You can add filters to cut down on the amount of info too... See: http://livedocs.adobe.com/flex/2/langref/mx/logging/targets/TraceTarget. html http://livedocs.adobe.com/flex/2/docs/wwhelp/wwhimpl/js/html/wwhelp.htm? href=00001534.html It's largely the rpc, messaging and data services classes that make use of mx.logging.* btw. ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of simonjpalmer Sent: Friday, May 04, 2007 2:45 PM To: [email protected] Subject: [flexcoders] Re: Help! Object integrity across DataService.commit() Thanks for the tip Pete, anything to reduce the noise in the logs is good. Jeff mentioned the TraceTarget tag on the client side and I have been doing some digging there. I'm not completely clear how to use it. Are there any light docs I can read to get me started? I am used to writing trace commands into my code but I don't seem to be able to use the TraceTarget meaningfully. Does it only work if running in debug? Simon --- In [email protected] <mailto:flexcoders%40yahoogroups.com> , "Peter Farland" <[EMAIL PROTECTED]> wrote: > > Just a minor note Simon, for the logging categories, I'd suggest using > either "Endpoint.*" OR "Message.*" rather than both at the same time as > they give two different views for virtually the same information. The > other categories are fine, but these two in particular are some what > best treated as mutually exclusive to cut down on noise. > > (The endpoint.* is a raw property view of what is going through the > serializer and deserializer, the message.* is what is seen by the > message broker from a POJO sense of each message). > > Pete > > ________________________________ > > From: [email protected] <mailto:flexcoders%40yahoogroups.com> [mailto:[email protected] <mailto:flexcoders%40yahoogroups.com> ] On > Behalf Of simonjpalmer > Sent: Thursday, May 03, 2007 3:21 PM > To: [email protected] <mailto:flexcoders%40yahoogroups.com> > Subject: [flexcoders] Re: Help! Object integrity across > DataService.commit() > > > > thanks, that did it, I now have copious debug logs. Onto fence two... > > --- In [email protected] <mailto:flexcoders%40yahoogroups.com> <mailto:flexcoders%40yahoogroups.com> > , "Jeff Vroom" <jvroom@> wrote: > > > > That certainly looks right to me. That version of ConsoleTarget just > > uses the System.out to print messages so you might look around to see > if > > they are going into a separate log file. You might try changing > > ConsoleTarget to ServletLogTarget which uses the Servlet's log method. > > That sometimes works better on app servers which like to redirect > > System.out to some other log file. > > > > > > > > Jeff > > > > > > > > ________________________________ > > > > From: [email protected] <mailto:flexcoders%40yahoogroups.com> <mailto:flexcoders%40yahoogroups.com> > [mailto:[email protected] <mailto:flexcoders%40yahoogroups.com> <mailto:flexcoders%40yahoogroups.com> > ] On > > Behalf Of simonjpalmer > > Sent: Thursday, May 03, 2007 10:41 AM > > To: [email protected] <mailto:flexcoders%40yahoogroups.com> <mailto:flexcoders%40yahoogroups.com> > > Subject: [flexcoders] Re: Help! Object integrity across > > DataService.commit() > > > > > > > > Jeff, > > > > I have fallen at the first fence trying to switch on the debug logs. > > I presumed this happened in the logging section of > > services-config.xml, so this is what I did: > > > > <logging> > > <target class="flex.messaging.log.ConsoleTarget" level="Debug"> > > <properties> > > <prefix>[Flex] </prefix> > > <includeDate>false</includeDate> > > <includeTime>false</includeTime> > > <includeLevel>false</includeLevel> > > <includeCategory>false</includeCategory> > > </properties> > > <filters> > > <pattern>Endpoint.*</pattern> > > <pattern>Service.*</pattern> > > <pattern>Configuration</pattern> > > <pattern>DataService.*</pattern> > > <pattern>Message.*</pattern> > > </filters> > > </target> > > </logging> > > > > then I started my server and did some things through my UI which cause > > data to be read/written. I was watching my server stdout through a > > console and saw no additional messages. So I went to my server log > > which is where teh rest of my debug logging shows up to see what I > > got. Unfortunately I have nothing more than I was previously getting. > > > > What have I done wrong? Where should I be looking? Have I put the > > patterns in the config file correctly? > > > > If you would repfer to take this off flexcoders I can get in touch > > directly or you can email me simon.palmer @ gmail.com > > > > Simon > > > > --- In [email protected] <mailto:flexcoders%40yahoogroups.com> > <mailto:flexcoders%40yahoogroups.com> > <mailto:flexcoders%40yahoogroups.com> > > , "simonjpalmer" <simonjpalmer@> > > wrote: > > > > > > Jeff, > > > > > > thank you for your response, I realaly appreciate it, this is > driving > > > me slightly mad and there's a lot in here for me to try. Thanks also > > > for the offer of help decoding the logs, I may well take you up on > > > that. It's going to take me a couple of days to get into a position > > > to try this out properly but I will be back... > > > > > > Regards > > > Simon > > > > > > --- In [email protected] <mailto:flexcoders%40yahoogroups.com> > <mailto:flexcoders%40yahoogroups.com> > > <mailto:flexcoders%40yahoogroups.com> , "Jeff Vroom" <jvroom@> wrote: > > > > > > > > One of the features of Data Management is that the assembler can > > modify > > > > the objects involved in a create or an update. After the commit, > > these > > > > changes are applied to the managed copy. One common change made > > on the > > > > server is that during the create the server assigns new ids to the > > newly > > > > created items. If the assembler does not make any changes, nothing > > > > should be changed after the commit. > > > > > > > > > > > > > > > > So I think the first step would be to turn on the debug level for > > the > > > > "Message.*" and "DataService.*" patterns in the server logs, and > > compare > > > > the before and after "create" and "update" events in the logs. > > For lazy > > > > associations, the state of the association properties is stored in > > the > > > > "referencedIds" headers in the messages. For non-lazy > > associations, if > > > > you put toString methods in your DTOs to dump out relevant info > > that is > > > > helpful. > > > > > > > > > > > > > > > > One more thing to try that may help. When the objects have > > lazy="true" > > > > (not the default) only the references to objects are updated. At > > most, > > > > data management has to update references to objects so the > instances > > > > would only change if the ids were changed. When lazy="false" we > > > > recursively update the object graph for the properties changed > > which is > > > > more involved so you might try adding lazy="true". In particular, > > make > > > > sure that parent has lazy="true" as backptrs tend to perform and > > behave > > > > better when you are not sending the parent's state along with an > > update > > > > of the child. This does sometimes mean you have to catch and > ignore > > > > ItemPendingErrors but usually this doesn't happen for parents. > > > > > > > > > > > > > > > > If you could use help analyzing the logs, send them along. > Sometimes > > > > the client side debug log is useful in these situations too > > > > (<mx:TraceTarget/>). > > > > > > > > > > > > > > > > Jeff > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: [email protected] <mailto:flexcoders%40yahoogroups.com> > <mailto:flexcoders%40yahoogroups.com> > > <mailto:flexcoders%40yahoogroups.com> > > [mailto:[email protected] <mailto:flexcoders%40yahoogroups.com> > <mailto:flexcoders%40yahoogroups.com> > <mailto:flexcoders%40yahoogroups.com> > > ] On > > > > Behalf Of simonjpalmer > > > > Sent: Tuesday, April 17, 2007 7:20 AM > > > > To: [email protected] <mailto:flexcoders%40yahoogroups.com> > <mailto:flexcoders%40yahoogroups.com> > <mailto:flexcoders%40yahoogroups.com> > > > > > > Subject: [flexcoders] Help! Object integrity across > > DataService.commit() > > > > > > > > > > > > > > > > I seem to be getting object instances changing across a commit() > > > > boundary. Half the object ID's change through a commit for no > > > > apparent reason. This means I have no capability to manage a > > > > parent-child relationship in data. Utter disaster! > > > > > > > > Here's the situation. I have a parent child hierarchy of objects, > > > > from the root to the leaves: > > > > PO > > > > PP > > > > SS > > > > SC > > > > OP > > > > So PO's contain PP's, PP's contain SS's and so forth. > > > > > > > > I converse with a single data service which delivers a set of PO's > > and > > > > the PP's are thereafter lazily loaded. I don't break the > dataservice > > > > or object model anywhere below that, so a PP is treated as a > single > > > > entity and read and written as such with its entire sub-graph of > > > > objects. > > > > > > > > I have two destinations, one for PO's and one for PP's and this > all > > > > works fine. > > > > > > > > However, when I create a graph such as the one above and commit it > > to > > > > the server through the PO destination I have different object > > > > instances for SS, SC and OP's after the call to commit returns. > > > > > > > > This is a problem because there are some properties which are > > specific > > > > to the object instance, in particular an object reference to its > > > > parent. The object instance of the parent is changing across the > > > > commit boundary. > > > > > > > > Before commit everything is joined up nicely as you would expect: > > > > > > > > PO @42f2451 > > > > PP @43f3629 parent @42f2451 > > > > SS @4c0ee71 parent @43f3629 > > > > SC @a5d69d1 parent @4c0ee71 > > > > OP @a2f5a01 parent @a5d69d1 > > > > > > > > after commit these are the same... > > > > > > > > PO @42f2451 > > > > PP @43f3629 parent @42f2451 > > > > > > > > however everything else is different > > > > > > > > SS @4c0e151 parent @a94d3d1 > > > > SC @4ba2d31 parent @4c0e151 > > > > OP @<new> parent @4ba2d31 > > > > > > > > what's worse is that the new parent instance of PP held on the new > > SS > > > > (i.e. whatever is under @a94d3d1) has itself a null parent > > reference. > > > > That means that after the commit my tree below SS is dangling in > the > > > > wind and I cannot find the parentage up to PO! > > > > > > > > This is a complete disaster. It effectively means I have no > > > > bi-directional one-to-many support, e.g. no Parent-Child, the most > > > > basic of relationships! > > > > > > > > Worse, if I traverse down from PO to OP I cannot traverse back up > > > > again! It goes down one path and up another which ends before it > > gets > > > > to PO. > > > > > > > > So I have three questions: > > > > > > > > What am I doing wrong? > > > > How do I prevent my object instances from being screwed around > with > > > > during commit? > > > > How do I tell when commit() has finished? Is there an Event I can > > > > trap for its completion? Then I could at least repair my tree. > > > > > > > > very glum... > > > > > > > > SP > > > > > > > > > >
