cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <...@envoisolutions.com>
Subject Re: FW: Transport API again
Date Tue, 10 Oct 2006 21:19:36 GMT
Eoghan Glynn wrote:

>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com 
> <mailto:dan@envoisolutions.com>]
> > Sent: Tuesday, October 10, 2006 11:44 AM
> > To: cxf-dev@incubator.apache.org <mailto:cxf-dev@incubator.apache.org>
> > Subject: Transport API again
> >
> > Hiya,
> > David Jencks and I are working on the Geronimo integration. We have to
> > write a new HTTP transport
>
> Hi Dan,
>
> Can you explain why the CXF/Geronimo integration requires a brand new 
> HTTP transport?
>
> I wasn't overly familiar with the old Celtix/Geronimo integration, but 
> IIRC it used the Geronimo WebServiceBuilder/WebServiceContainer/GBean 
> touch points and didn't require an alternative HTTP transport 
> implementation.
>
Geronimo has a web service servlet thing which passes through requests 
and response to us to use.

> > and I am reminded again that I'm not a fan
> of
> > the current getBackChannel() as isn't really dependent on the
> transport.
> > Additionally people (like myself) find it confusing. Eoghan - have you
> > thought about this any more?
>
> Sure, the back-channel could be established more directly by going 
> straight to the ConduitInitiator. However as I said before, the idea 
> of modelling getBackChannel() on the Destination intsead was to allow 
> for a compatibility check to be done by the transport ... e.g. for the 
> HTTPS Destination to ensure the ReplyTo URI included the "https" as 
> opposed to the "http" scheme.

Yes, but as I said earlier, this is a policy thing and it would seem to 
make more sense to expose the necessary information to make this a 
higher level decision. Right now it looks like we're going to have a 
Jetty, Servlet, Geronimo, and AsyncWeb transports. 4 cases of the same 
code seems enough to me to move it out of the transport to a higher layer.

>
> > Also, I was talking to Greg of Jetty fame and he said that you can
> > create an OutputStream and write headers after that, provided you
> don't
> > write data which exceeds the size of the response buffer. Maybe we
> > should change our HTTP code so it doesn't use the wrappedoutputstream
> > then?
>
> Was Greg talking about the Jetty implementation? 
>
> The problem is we don't use Jetty on the client-side, instead we use 
> the java.net.HttpURLConnection 
> and I'm pretty sure that attempting to set a request header after calling HttpURLConnection.getOutputStream()

> will fail with an IllegalStateException.

Ah, I see now. Yes, he was talking about Jetty. I had just noticed that 
you were using the wrappedoutputstream in the jetty response, so I 
thought we could take that out.

- Dan

-- 
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


Mime
View raw message