cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fahman_dude <fahman_d...@hotmail.com>
Subject Oneway MEP and fastInfoset without 'force'
Date Wed, 24 Feb 2010 14:15:15 GMT

Hello,

I am not sure if this is actually cxf relevant or just the way how Oneway
MEP and fastInfoset work, but I observed this:

If a fastInfoset (accept=application/fastinfoset) @Oneway Message is sent to
the Server and 'force' option of the fastInfoset is not set to 'true', the
server would give 202 response and would use content-type: text/xml like
this:

15:04:33,000 DEBUG [main] cxf.transport.http.HTTPConduit (2132)     - Header
fields: 
    null: [HTTP/1.1 202 Accepted]
    Content-Length: [0]
    Content-Type: [text/xml]
    Server: [Jetty(6.1.21)]

I am not sure if this is the consequence of server answering with text/xml,
but as a result the client issues all of the following requests with
text/xml aswell instead of switching to application/fastinfoset.

Per definition fastinfoset works like this:
1. client requests server with content-type:text/xml but indicates that it
(client) accept:application/fastinfoset;
2. server responds with content-type:application/fastinfoset
3. all the following requests from client to server will be with
content-type:application/fastinfoset

I have successfully tested this with Twoway MEP Message and was quite
suprized as I just noticed that client does not use application/fastinfoset
anymore since I changed my message to be Oneway.

Any comments on this would be appretiated.

cheers
reinis
-- 
View this message in context: http://old.nabble.com/Oneway-MEP-and-fastInfoset-without-%27force%27-tp27714213p27714213.html
Sent from the cxf-user mailing list archive at Nabble.com.


Mime
View raw message