You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Glen Mazza <gl...@gmail.com> on 2010/07/30 03:50:39 UTC
HTTP SPI working for us?
Team, Jitendra Kotamaraju of the Metro team recently created[1] a
JAXWS-Grizzly-HTTP SPI[2] (Service Provider Interface, I guess) that allows
for a programmatic change of the underlying servlet container used for the
Endpoint class (Grizzly instead of Jetty in our case.)
I haven't tested it on CXF 2.3, but he claims this should work on any JAX-WS
2.2 runtime. Is this portion (the HTTP SPI) of JAX-WS 2.2 already finished
in the upcoming CXF 2.3, i.e., this should work for us?
Thanks,
Glen
[1]
http://weblogs.java.net/blog/jitu/archive/2010/07/09/grizzly-transport-using-jax-ws-22-http-spi
[2]
https://jax-ws-commons.dev.java.net/grizzly-httpspi/jaxws-grizzly-httpspi/index.html
--
View this message in context: http://cxf.547215.n5.nabble.com/HTTP-SPI-working-for-us-tp2259090p2259090.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: HTTP SPI working for us?
Posted by 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
Re: HTTP SPI working for us?
Posted by 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?
Posted by Glen Mazza <gl...@gmail.com>.
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.
Glen
--
View this message in context: http://cxf.547215.n5.nabble.com/HTTP-SPI-working-for-us-tp2259090p2260305.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: HTTP SPI working for us?
Posted by Daniel Kulp <dk...@apache.org>.
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
On Thursday 29 July 2010 9:50:39 pm Glen Mazza wrote:
> Team, Jitendra Kotamaraju of the Metro team recently created[1] a
> JAXWS-Grizzly-HTTP SPI[2] (Service Provider Interface, I guess) that allows
> for a programmatic change of the underlying servlet container used for the
> Endpoint class (Grizzly instead of Jetty in our case.)
>
> I haven't tested it on CXF 2.3, but he claims this should work on any
> JAX-WS 2.2 runtime. Is this portion (the HTTP SPI) of JAX-WS 2.2 already
> finished in the upcoming CXF 2.3, i.e., this should work for us?
>
> Thanks,
> Glen
>
> [1]
> http://weblogs.java.net/blog/jitu/archive/2010/07/09/grizzly-transport-usin
> g-jax-ws-22-http-spi [2]
> https://jax-ws-commons.dev.java.net/grizzly-httpspi/jaxws-grizzly-httpspi/i
> ndex.html
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog