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
