Ron, I think you might have slightly misread me. What I meant to say was, 'sorry, I didn't see that you posted those logs or I would have looked at this again sooner.'
I will be trying again to make a repro for this inside the CXF test framework that will permit me or someone to track this down. --benson On Sat, Feb 21, 2009 at 3:20 PM, Ron Grimes <[email protected]> wrote: > Benson, > > I have attached a wireshark dump to the JIRA at > https://issues.apache.org/jira/browse/CXF-1956 > <https://issues.apache.org/jira/browse/CXF-1956> . It isolates the packet in > question and should show conclusively that the problem is how CXF is > generating the SOAP envelope. Please note that this was run on the Tomcat > server and shows the response from the server address (10.0.8.13) to my > client address (75....). If you open the ws_dump_20090221.pcap file and > navigate to the Packet Details panel, and then expand the "extensible Markup > Language" node, you will notice how it shows a "[ ERROR: Unrecognized text ] > " after the id node. > > The funny thing is, as I originally reported, it generally returns this exact > same data correctly on the first web service request, but somehow screws it > up on the second, third, etc. I do notice that, in this case, the garbage is > appended after the id node, which would be the GuestCommentId entity in > relation to the GuestComment entity. Because it sometimes returns this exact > same record just fine, and other times not, it rules out that the node > element genuinely contains bad data within the database. > > Please let me know if I can provide anything further to verify that this is a > CXF problem or not. > > Thanks, > > Ron Grimes > > > ________________________________ > > From: Benson Margulies [mailto:[email protected]] > Sent: Sat 2/21/2009 12:20 PM > To: [email protected] > Subject: Re: CXF 2.1 to CXF 2.2 > > > > Ron, > > I missed your last addition to this bug offering concrete evidence. > Somehow we have to come up with a reproduction of this that we can > work with. > > --benson > > > > On Sat, Feb 21, 2009 at 2:03 PM, Ron Grimes <[email protected]> wrote: >> If you're going to develop with Flex and CXF, there are some very quirky >> features you should be aware of: >> >> 1). Sometimes it helps to define your resultFormat to use "xml" instead of >> "e4x". See >> http://www.flexer.info/2008/09/10/httpservice-requesting-xml-from-feedburner-gets-parsed-with-xsl-in-ie-browser/ >> >> 2) Marshalling XML to the Flex/Flash client can be problematic if the HTTP >> response headers contain No-Cache. See >> http://faindu.wordpress.com/2008/04/18/ie7-ssl-xml-flex-error-2032-stream-error/ >> >> 3) Apache CXF sometimes returns garbage at the end of the SOAP envelope, >> which causes a fault in Flex. See my JIRA entry at >> https://issues.apache.org/jira/browse/CXF-1956 . I was able prove, via the >> Jira incident's WireShark attachments, that its the Spring/Apache CXF web >> service returning the garbage, but it remains unaddressed. I hope they solve >> it soon. To solve this, I had to put some "fix-it" logic in the Flex fault >> method to strip out the garbage and re-process just the SOAP envelope. >> >> Hope something here is helpful. >> >> Ron Grimes >> >> >> ________________________________ >> >> From: charlie [mailto:[email protected]] >> Sent: Sat 2/21/2009 3:54 AM >> To: [email protected] >> Subject: CXF 2.1 to CXF 2.2 >> >> >> >> Hi all, >> >> I have upgarded from 2.1.3 -> 2.2-SNAPSHOT as I need the multipart/form-data >> stuff. I have a flex client that runs in different browser calling these >> endpoints. Since the upgrade some of the endpoints have stopped working for >> the flex client. It was throwing a parseing exception. So i looked at the >> XML. From Internet Explorer and Safari I get this: >> {"Response":{"expiryDate":1235157506359,"passwordHash":"5f4dcc3b5aa765d61d8327deb882cf99","roleId":3,"securityToken":"<?xml >> version=\"1.0\" encoding=\"UTF-8\" ?><TOKEN >> TYPE=\"2\"><PUBLIC><MEMBER-ID>0<\/MEMBER-ID> >> <NAME>test<\/NAME><HOST>3<\/HOST><EXPIRY-DATE>1235170466370<\/EXPIRY-DATE><\/PUBLIC><CIPHER-TEXT><![CDATA[MNYIeugbGuJ7V1zq9nMm82JTlmiSswJMSokjYI5z9634nPkyJpWgDpuqcg3QkOXZmfCc6BX7m7+togEG4bAFsSggKFgPmlm+nefFLhZ8EOofmSTq\/or0wrMar3WA1WlbZGkGZOjl6A+6v9oSONvsdJW4PLP7Lk06iwwIeZdbFXmeKSWxdonCXw==]]><\/CIPHER-TEXT><\/TOKEN>","status":"OK"}} >> >> But is correct in Firefox: >> <?xml version="1.0" encoding="UTF-8" >> standalone="yes"?><Response><expiryDate>1235157552986</expiryDate><passwordHash>5f4dcc3b5aa765d61d8327deb882cf99</passwordHash><roleId>3</roleId><securityToken><?xml >> version="1.0" encoding="UTF-8" ?><TOKEN >> TYPE="2"><PUBLIC><MEMBER-ID>0</MEMBER-ID> >> <NAME>test</NAME><HOST>3</HOST><EXPIRY-DATE>1235170512998</EXPIRY-DATE></PUBLIC><CIPHER-TEXT><![CDATA[MNYIeugbGuJ7V1zq9nMm82JTlmiSswJMSokjYI5z962n6dp9vkO/Kf51/hIjtDzPmfCc6BX7m7+togEG4bAFsSggKFgPmlm+nefFLhZ8EOofmSTq/or0wrMar3WA1WlbZGkGZOjl6A+6v9oSONvsdJW4PLP7Lk06iwwIeZdbFXmeKSWxdonCXw==]]></CIPHER-TEXT></TOKEN></securityToken><status>OK</status></Response> >> >> It Almost seems like the browser have transform the data. Is there any thing >> I need to do to instruct the marshalling in 2.2? >> >> Thanks >> Charlie >> >> -- >> http://finker.wordpress.com/ >> >> >> > > >
