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:[EMAIL PROTECTED] On Behalf Of simonjpalmer Sent: Thursday, May 03, 2007 10:41 AM To: [email protected] 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> , "simonjpalmer" <[EMAIL PROTECTED]> 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> , "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:[email protected] <mailto:flexcoders%40yahoogroups.com> ] On > > Behalf Of simonjpalmer > > Sent: Tuesday, April 17, 2007 7:20 AM > > To: [email protected] <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 > > >
