cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <daniel.k...@iona.com>
Subject Re: Proposal for Decoupling and Issues with CXFServlet
Date Thu, 18 Jan 2007 16:48:44 GMT
On Thursday 18 January 2007 09:08, Glynn, Eoghan wrote:
> > (FWIW, I don't think it would be all that worthwhile to add a
> > special interface at this point as the only case we would
> > need it is the two way partial response. Seems much simpler
> > to just put in a message.put(RESPONSE_CODE,
> > 202) in RM like we do in SOAP for the time being. If we had
> > another transport which required special syntax we could add
> > extension points at that time.)
>
> Ok we're just going to have to agree to disagree on this.
>
> I really don't like setting the response code from outside the
> transport.

I'm WAY WAY behind on this thread, but I really need to jump in on this 
point......


I COMPLETELY disagree with you on this one.   There is NOTHING in the HTTP 
spec that says "RM partial responses are 202" or "SOAP faults are 500", 
etc....      Our HTTP transport should NOT have any of that stuff coded into 
it.   

The mapping of SOAP faults to response code 500 is part of the SOAP spec.   
Thus, the SOAP layer should be setting that. 

The RM response code mappings are part of the RM spec.   The RM layer should 
be specifying that.

There should not be any RM logic burned into the transports.   That's bad.    
I'm OK with possibly adding a couple methods to help make the RM capabilities 
easier, but burning the logic into the transports is bad.   Making the 
transports very complex to write is also bad.

Anyway, I don't know all the details (I'm way behind on the discussion 
threads), but that point just jumped out as "not good."  (IMO)


-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com

Mime
View raw message