And a dumb question: I assume that this is just as visible in SOAPui
as it is in WireShark.

On Sat, Feb 21, 2009 at 3:44 PM, Benson Margulies <[email protected]> wrote:
> 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>&lt;?xml
>>> version=&quot;1.0&quot; encoding=&quot;UTF-8&quot; ?&gt;&lt;TOKEN
>>> TYPE=&quot;2&quot;&gt;&lt;PUBLIC&gt;&lt;MEMBER-ID&gt;0&lt;/MEMBER-ID&gt;
>>> &lt;NAME&gt;test&lt;/NAME&gt;&lt;HOST&gt;3&lt;/HOST&gt;&lt;EXPIRY-DATE&gt;1235170512998&lt;/EXPIRY-DATE&gt;&lt;/PUBLIC&gt;&lt;CIPHER-TEXT&gt;&lt;![CDATA[MNYIeugbGuJ7V1zq9nMm82JTlmiSswJMSokjYI5z962n6dp9vkO/Kf51/hIjtDzPmfCc6BX7m7+togEG4bAFsSggKFgPmlm+nefFLhZ8EOofmSTq/or0wrMar3WA1WlbZGkGZOjl6A+6v9oSONvsdJW4PLP7Lk06iwwIeZdbFXmeKSWxdonCXw==]]&gt;&lt;/CIPHER-TEXT&gt;&lt;/TOKEN&gt;</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/
>>>
>>>
>>>
>>
>>
>>
>

Reply via email to