cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <>
Subject RE: HTTP dependency/decoupling issue
Date Tue, 06 Feb 2007 00:44:58 GMT
> -----Original Message-----
> From: Dan Diephouse [] 
> Sent: 05 February 2007 18:53
> To:
> Subject: HTTP dependency/decoupling issue
> Hi All,
> I'm working with someone who is looking to use CXF as a web 
> service client.
> Currently we require a lot of jars[1], which is a topic for 
> another thread.
> However there are two specific problems I see with things currently.
> 1. We require jetty to be on the classpath if people want to 
> use a web service client. I'm very strongly against requiring 
> Jetty to do simple HTTP clients. XFire already has people 
> annoyed because of its dependency list [2], I would hate to 
> imagine the the response if we required Jetty to do a simple 
> web service client.
> I tried an initial fix of removing the inner classes from 
> HTTPConduit which reference Jetty, but HTTPConduit has a 
> dependency on ServerEngine which references 
> AbstractHttpHandler, so its not quite so straightforward.
> 2. The HTTPConduit explicitly uses Jetty instead of depending 
> on our Destination API. What if someone is deployed in a 
> servlet environment and only port 80 is open? We should be We 
> should be able to set up a decoupled listener on the servlet 
> transport as well. Anyone know what the point is of 
> explicitly referencing Jetty's APIs?

Well the reason I did that way is simple. The logic required to handle
an incoming HTTP message, *prior* to the MessageObserver.onMessage()
being notified, is subtly different depending on whether its an incoming
request or decoupled response. 

Different message properties need to be set for example, and a different
strategy is required in order to associate an Exchange with the incoming
message (in decoupled case we need to create temporary disposable
Exchange which is then later replaced by the real Exchange once the
response is correlated with the corresponding request). So simply
getting a Destination from the current HTTP DestinationFactory wouldn't
have given me exactly what I wanted. 

So to achieve this difference in handling the incoming HTTP message, the
most convenient thing was to register a specialized Jetty handler for
decoupled responses, given that we were already using Jetty as our
primary standalone HTTP listener.

Now on reflection, I reckon I could have achieved the same thing by
getting a HTTP Destination from the current factory, combined with a
wrapper MessageObserver that set and unset properties, exchange, content
etc. appropriately before calling on through to the real MessageObserver
(the ClientImpl in the decoupled case).

I'll look at changing it around to work this way.

However can you expand on what exactly the objection is to Jetty on the
client-side? Lets deal with the standalone client app and servlet
container cases separately.

In the stand-alone client app case, is it the size of the Jetty jar
that's the problem? Note there are other far larger jars already
required on the client side. We could stick in a light-weight
alternative HTTP DestinationFactory based on say nanoHTTP, though I'm
unconvinced that shaving off a few hundred kb off the client foot-print
is worth the trouble. Or is the issue just that for a non-decoupled
client, we shouldn't have a requirement for Jetty, but for a decoupled
client the footprint of Jetty is fine?

In the client deployed in tomcat use-case, I think we can accommodate
this with the changes I mention above, as long as the configured
decoupled response endpoint URI is chosen carefully not to line up with
the tomcat HTTP connector port and the url-pattern specified in the
web.xml (with say "/decoupled response" appended).


> --
> One solution would be to use the Destination API explicitly 
> in the HTTPConduit instead of using the Jetty APIs. Another 
> would be to of removing decoupling from the transport layer. 
> I would appreciate it if others spoke up and gave their input 
> as well though.
> I am of course for the latter. We have so much added 
> complexity because of this (Decoupled* classes, ServerEngine 
> references, extra Conduit APIs, the ugly 
> Destination.getBackChannel(...), etc.) Its very feasible to 
> do this and I still don't see what we have to lose by doing 
> separating this all out. But I'm repeating myself...
> - Dan
> 1. Jars required currently:
> XmlSchema-1.1.jar
> activation-1.1.jar
> aopalliance-1.0.jar
> commons-logging-1.1.jar
> cxf-api-2.0-incubator-RC-SNAPSHOT.jar
> cxf-common-schemas-2.0-incubator-RC-SNAPSHOT.jar
> cxf-common-utilities-2.0-incubator-RC-SNAPSHOT.jar
> cxf-metacode-2.0-incubator-RC-SNAPSHOT.jar
> cxf-rt-bindings-soap-2.0-incubator-RC-SNAPSHOT.jar
> cxf-rt-core-2.0-incubator-RC-SNAPSHOT.jar
> cxf-rt-databinding-jaxb-2.0-incubator-RC-SNAPSHOT.jar
> cxf-rt-frontend-jaxws-2.0-incubator-RC-SNAPSHOT.jar
> cxf-rt-transports-http-2.0-incubator-RC-SNAPSHOT.jar
> cxf-tools-common-2.0-incubator-RC-SNAPSHOT.jar
> jaxb-api-2.0.jar
> jaxb-impl-2.0.3.jar
> jaxb-xjc-2.0.3.jar
> jaxws-api-2.0.jar
> jsr181-api-1.0-MR1.jar
> jsr250-api-1.0.jar
> mail-1.4.jar
> org.mortbay.jetty-5.1.11.jar
> saaj-api-1.3.jar
> saaj-impl-1.3.jar
> spring-aop-2.0.jar
> spring-beans-2.0.jar
> spring-context-2.0.jar
> spring-core-2.0.jar
> stax-api-1.0.1.jar
> wsdl4j-1.6.1.jar
> wstx-asl-3.2.0.jar
> I'll be able to make SAAJ, Spring, and aopalliance optional 
> as well with a little more tweaking...
> 2. One recent example of many -
> - I could work my way through the xfire user archives, but I 
> don't really have the time.
> --
> Dan Diephouse
> Envoi Solutions
> |

View raw message