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, "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: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On > Behalf Of simonjpalmer > Sent: Thursday, May 03, 2007 3:21 PM > To: flexcoders@yahoogroups.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> > , "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@yahoogroups.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> > > 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> > > , "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> , "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@yahoogroups.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> > > > > > > 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 > > > > > > > > > >
