If the log file does not appear and you have a mm.cfg file, then usually it's because the debug version of the Flash Player is not installed (i.e. the debug version of the Flash Player installers that come with Flex... as you well know). Is there any chance that you updated to 9.0 r45 from the adobe.com website (perhaps this happened automatically?) and thus you no longer have your debug player installed (I think the last version of the debug player we shipped was for 9.0 r28?). I guess you could try re-installing the debug players to be absolutely sure. I'd also check if Firefox versus another browser like IE makes a difference. 1.) For the log levels, see: http://livedocs.adobe.com/flex/2/langref/mx/logging/LogEventLevel.html 2.) Not sure... I've wondered that myself but never dug deep enough to find out.
________________________________ From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of simonjpalmer Sent: Friday, May 04, 2007 4:21 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Help! Object integrity across DataService.commit() Thanks again Pete. So I have this in my application code which is stolen directly from the docs: <mx:TraceTarget> <mx:filters> <mx:Array> <mx:String>mx.data.DataService</mx:String> <mx:String>mx.data.ConflictResolver</mx:String> </mx:Array> </mx:filters> <!-- 2 is represents the LogEventLevel.DEBUG constant. --> <mx:level>2</mx:level> </mx:TraceTarget> I created an mm.cfg file for myself after checking where my HOMEDRIVE and HOMEPATH were and put the following in it: ErrorReportingEnable=1 TraceOutputFileEnable=1 I re-started my server and ran the client in the debugger but I don't get any log files created. I am judiciously ignoring the instructions about log paths as you suggested. Any ideas what I have done wrong? I get a whole whack of output into the console window, but no log file. Two other questions for you (or anyone else who knows the answers): 1) where do I go to find out what the integer values of the log levels are? 2) how do I get at an object's address in memory? This may sound a little weird. What I am looking for is that piece of information which shows up in the debugger and looks like "@afe634". I am presuming this is an address or an identifer of some kind and I think this is the key to me identifying what is happening to my objects. Their UIDs remain the same, but they are clearly not the same objects as their property values are different. I appear to have several managed objects with the same uid but different property values. Simon --- In flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> , "Peter Farland" <[EMAIL PROTECTED]> wrote: > > <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 <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. <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? <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: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> [mailto:flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> ] On > Behalf Of simonjpalmer > Sent: Friday, May 04, 2007 2:45 PM > To: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> > 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 flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> <mailto:flexcoders%40yahoogroups.com> > , "Peter Farland" <pfarland@> 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: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> <mailto:flexcoders%40yahoogroups.com> > [mailto:flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> <mailto:flexcoders%40yahoogroups.com> > ] On > > Behalf Of simonjpalmer > > Sent: Thursday, May 03, 2007 3:21 PM > > To: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> <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 flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> > <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: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> > <mailto:flexcoders%40yahoogroups.com> > <mailto:flexcoders%40yahoogroups.com> > > [mailto:flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> > <mailto:flexcoders%40yahoogroups.com> > <mailto:flexcoders%40yahoogroups.com> > > ] On > > > Behalf Of simonjpalmer > > > Sent: Thursday, May 03, 2007 10:41 AM > > > To: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> <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 flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> > <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 flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> > <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: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> > <mailto:flexcoders%40yahoogroups.com> > > <mailto:flexcoders%40yahoogroups.com> > > > <mailto:flexcoders%40yahoogroups.com> > > > [mailto:flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> > <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: flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> > <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 > > > > > > > > > > > > > > >
