cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: HTTP SPI working for us?
Date Wed, 11 Aug 2010 18:32:16 GMT
On Wednesday 11 August 2010 12:16:29 pm Alessio Soldano wrote:
> My understanding is that completing the JAXWS 2.2 implementation
> covering the HTTP SPI stuff too implies being able to publish an
> endpoint against any http server implementing that SPI.
> Btw, that spi is very similar to the SPI in the jdk internal webserver,
>* which I believe is what the jaxws RI already
> supported through the Endpoint.publish(Object context) method (which
> currently does nothing in CXF, the Endpoint.publish(String addr) is used
> instead).
> JAXWS 2.2 added Endpoint.publish(HTTPContext context) (and the classes
> in as a "generalization" of what was already
> there in the RI.
> Now, Jitu is adding a connection between the new jaxws http spi and
> Grizzly -which btw is just few classes-, for supporting usecases like
> [1]. He correctly says that this Grizzly connection can be used with any
> JAXWS implementation, as of course most of the hard work (ehm, all of
> that) needs to be done for supporting the jaxws http spi.

> So, back to CXF, I agree adding support for this is basically writing a
> new transport. That would potentially allow running on many different
> http server though, including Grizzly (and the jdk internal httpserver,
> probably just few conversion classes required once this is done). Might
> allow, for instance, avoid shipping Jetty (which btw is the reason why I
> might be interested in working on this...)
> Do you agree / does this "sum up" of the situation make sense to you?

Pretty much yea.   

It might not be TOO hard to implement.   The ServerFactoryBean that is used 
during publish contains the DestinationFactory object (with setter/getter).  
Thus, the new publish method would just need to set that with a new 
Destination that wrappers the new SPI stuff.  I haven't looked at the new SPI 
stuff to know how hard that is.  I DO know that for some bizzare reason, it 
doesn't use HttpServletRequest/Response which would be required for a bunch of 
things.   Thus, you'll need to create instances of those that forward into the 
SPI things.

For the most part, if you can create an HttpServletRequest/Response, then a 
subclass of AbstractHttpDestination would be pretty easy to create to do all 

Daniel Kulp

View raw message