Re: HTTP SPI working for us?

[Alessio Soldano <as...@redhat.com>]

  On 07/31/2010 05:40 AM, Glen Mazza wrote:
> Daniel  Kulp wrote:
>> I don't think it will as I know I haven't implemented anything using the
>> http/spi things yet and I don't remember Jim doing so either.    The
>> JAX-WS
>> 2.2 TCK doesn't hit it at all.     Thus, it's not really something that
>> needs
>> to be there to claim compliance.
>>
>> I did see that blog entry and thought it looked interesting, but I really
>> haven't had the time to try getting that stuff implemented.  It may be
>> pretty
>> tricky to implement as it almost requires a whole new transport, but I
>> haven't
>> looked to much at it.
>>
>> Dan
> Neither have I.  But if I understand the new functionality correctly, it
> would not be so much the need for a new transport but a need to abstract
> CXF's present usage of Jetty in implementing Endpoint in a manner that
> allows other servlet containers to be placed in.  What JAX-WS 2.2 basically
> does (in pseudocode) is switch from this:
>
> Endpoint e21 = new Endpoint(...);
>
> to this:
>
> Endpoint e22 = new Endpoint(Jetty, ...);
>
> allowing the developer to replace "Jetty" with "Tomcat" or "Grizzly", etc.,
> in the first parameter of the constructor above (as soon as
> Endpoint-supporting implementations of the latter two are created.)   If my
> understanding here is correct, then Jetty would remain the default
> implementation for our Endpoint interface with its own simplified
> constructor, i.e., new Endpoint(...) would be the same as new
> Endpoint(Jetty, ...), and Endpoint reimplemented so constructors of the
> latter form could be created.
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, 
com.sun.net.httpserver.* 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 javax.xml.ws.spi.http) 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?

[1] http://forums.java.net/jive/thread.jspa?messageID=478300

-- 
Alessio Soldano
Web Service Lead, JBoss

Re: HTTP SPI working for us?

[Daniel Kulp <dk...@apache.org>]

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,
> com.sun.net.httpserver.* 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 javax.xml.ws.spi.http) 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 
this. 

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog