You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by charlie <ch...@gmail.com> on 2009/02/21 11:54:09 UTC
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/
Re: CXF 2.1 to CXF 2.2
Posted by charlie <ch...@gmail.com>.
Ron thx for the detail reply.. I think is prob to do with one. For some
reason during the upgrade I removed the @Produces stuff from the service
class.. I am gonna add it back in and see how it goes..
Great to see CXF's mailing list is so helpful :))
Charlie
2009/2/22 Christian Schneider <ch...@die-schneider.net>
> Benson Margulies schrieb:
>
>> OK, I'm confused.
>>
>> The non-xml log files look fine to me when I just read them into an
>> editor.
>>
>> Wireshark says 'invalid text', but it mostly it is just truncating. I
>> see <ns2:id><ns2:com, and then it stops. It looks more like the server
>> truncated than that anyone injected trash. I see this with the 'follow
>> TCP stream' option which dumps the entire session.
>>
>> What we're really crying here is for a way to make a CXF client reject
>> this. There's nothing on our client side that would paper-over junk in
>> the stream.
>>
>>
>>
>
> Sometime ago I had a problem with CXF and truncated xml. It happened when I
> turned on the logging interceptor.
> When the logging was on the xml was truncated when it was off it was ok.
> Perhaps this could be something similar.
>
> Greetings
>
> Christian
>
> --
>
> Christian Schneider
> ---
> http://www.liquid-reality.de
>
>
--
http://finker.wordpress.com/
Re: CXF 2.1 to CXF 2.2
Posted by Christian Schneider <ch...@die-schneider.net>.
Benson Margulies schrieb:
> OK, I'm confused.
>
> The non-xml log files look fine to me when I just read them into an editor.
>
> Wireshark says 'invalid text', but it mostly it is just truncating. I
> see <ns2:id><ns2:com, and then it stops. It looks more like the server
> truncated than that anyone injected trash. I see this with the 'follow
> TCP stream' option which dumps the entire session.
>
> What we're really crying here is for a way to make a CXF client reject
> this. There's nothing on our client side that would paper-over junk in
> the stream.
>
>
Sometime ago I had a problem with CXF and truncated xml. It happened
when I turned on the logging interceptor.
When the logging was on the xml was truncated when it was off it was ok.
Perhaps this could be something similar.
Greetings
Christian
--
Christian Schneider
---
http://www.liquid-reality.de
RE: CXF 2.1 to CXF 2.2
Posted by Ron Grimes <rg...@sinclairoil.com>.
With SOAPUI, I sometimes get a normal response with all the data, and other times I get an empty result set, using the same request parameters in the WireShark case.
I only attached the one packet in the wireshark dump (for brevity sake), but I am also seeing an error "Checksum: 0xb763 [incorrect, should be 0xcc2d (maybe caused by "TCP checksum offload"?)]". Not sure what that's all about.
If you write me privately, I'll give you the wsdl address so you can run SOAPUI tests.
Ron
________________________________
From: Benson Margulies [mailto:bimargulies@gmail.com]
Sent: Sat 2/21/2009 2:08 PM
To: users@cxf.apache.org
Subject: Re: CXF 2.1 to CXF 2.2
OK, I'm confused.
The non-xml log files look fine to me when I just read them into an editor.
Wireshark says 'invalid text', but it mostly it is just truncating. I
see <ns2:id><ns2:com, and then it stops. It looks more like the server
truncated than that anyone injected trash. I see this with the 'follow
TCP stream' option which dumps the entire session.
What we're really crying here is for a way to make a CXF client reject
this. There's nothing on our client side that would paper-over junk in
the stream.
Can you help me see the trash in the PacketBytes or RawTCP files?
I can't help wondering if Flex is confused about content length.
On Sat, Feb 21, 2009 at 3:45 PM, Benson Margulies <bi...@gmail.com> wrote:
> 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 <bi...@gmail.com> 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 <rg...@sinclairoil.com> 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:bimargulies@gmail.com]
>>> Sent: Sat 2/21/2009 12:20 PM
>>> To: users@cxf.apache.org
>>> 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 <rg...@sinclairoil.com> 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:charleskailunglee@gmail.com]
>>>> Sent: Sat 2/21/2009 3:54 AM
>>>> To: users@cxf.apache.org
>>>> 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/
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
Re: CXF 2.1 to CXF 2.2
Posted by Benson Margulies <bi...@gmail.com>.
OK, I'm confused.
The non-xml log files look fine to me when I just read them into an editor.
Wireshark says 'invalid text', but it mostly it is just truncating. I
see <ns2:id><ns2:com, and then it stops. It looks more like the server
truncated than that anyone injected trash. I see this with the 'follow
TCP stream' option which dumps the entire session.
What we're really crying here is for a way to make a CXF client reject
this. There's nothing on our client side that would paper-over junk in
the stream.
Can you help me see the trash in the PacketBytes or RawTCP files?
I can't help wondering if Flex is confused about content length.
On Sat, Feb 21, 2009 at 3:45 PM, Benson Margulies <bi...@gmail.com> wrote:
> 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 <bi...@gmail.com> 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 <rg...@sinclairoil.com> 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:bimargulies@gmail.com]
>>> Sent: Sat 2/21/2009 12:20 PM
>>> To: users@cxf.apache.org
>>> 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 <rg...@sinclairoil.com> 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:charleskailunglee@gmail.com]
>>>> Sent: Sat 2/21/2009 3:54 AM
>>>> To: users@cxf.apache.org
>>>> 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/
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
Re: CXF 2.1 to CXF 2.2
Posted by Benson Margulies <bi...@gmail.com>.
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 <bi...@gmail.com> 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 <rg...@sinclairoil.com> 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:bimargulies@gmail.com]
>> Sent: Sat 2/21/2009 12:20 PM
>> To: users@cxf.apache.org
>> 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 <rg...@sinclairoil.com> 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:charleskailunglee@gmail.com]
>>> Sent: Sat 2/21/2009 3:54 AM
>>> To: users@cxf.apache.org
>>> 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/
>>>
>>>
>>>
>>
>>
>>
>
Re: CXF 2.1 to CXF 2.2
Posted by Benson Margulies <bi...@gmail.com>.
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 <rg...@sinclairoil.com> 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:bimargulies@gmail.com]
> Sent: Sat 2/21/2009 12:20 PM
> To: users@cxf.apache.org
> 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 <rg...@sinclairoil.com> 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:charleskailunglee@gmail.com]
>> Sent: Sat 2/21/2009 3:54 AM
>> To: users@cxf.apache.org
>> 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/
>>
>>
>>
>
>
>
RE: CXF 2.1 to CXF 2.2
Posted by Ron Grimes <rg...@sinclairoil.com>.
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:bimargulies@gmail.com]
Sent: Sat 2/21/2009 12:20 PM
To: users@cxf.apache.org
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 <rg...@sinclairoil.com> 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:charleskailunglee@gmail.com]
> Sent: Sat 2/21/2009 3:54 AM
> To: users@cxf.apache.org
> 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/
>
>
>
Re: CXF 2.1 to CXF 2.2
Posted by Benson Margulies <bi...@gmail.com>.
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 <rg...@sinclairoil.com> 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:charleskailunglee@gmail.com]
> Sent: Sat 2/21/2009 3:54 AM
> To: users@cxf.apache.org
> 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/
>
>
>
RE: CXF 2.1 to CXF 2.2
Posted by Ron Grimes <rg...@sinclairoil.com>.
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:charleskailunglee@gmail.com]
Sent: Sat 2/21/2009 3:54 AM
To: users@cxf.apache.org
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/