I specifically think this is the right approach. Right now the
HTTPConduit is tied to using JettyDestinations. I don't even see why you
need Jetty if you a) don't have any decouple endpoints, or you aren't
doing any servers at all.
This could come back to the argument that the conduit shouldn't be
managing decoupled endpoints, but I digress.
Cheers,
-Polar
Daniel Kulp wrote:
On Tuesday 03 April 2007 13:06, Liu, Jervis wrote:
So lets say we now have two DestinationFactory
implementations available in the classpath, one is
JettyDestinationFactory another one is
GeronimoDestinationFactory, how do we control which one gets
picked up by bus? As long as we still ship
JettyDestinationFactory with the distribution and have its
cxf-extension-http.xml in the classpath,
JettyDestinationFactory will get loaded. We cant say in order
to load your own DestinationFactory implementation, you need
to remove JettyDestinationFactory's cxf-extension-http.xml
from classpath then add your DestinationFactory' extension
file into classpath. We will need sth else...
To answer my own question, do you mean we seperate current
cxf-rt-transports-http-2.0-incubator-RC-SNAPSHOT.jar into two jars,
one is for basic http support stuff, one is for Jetty, lets call it
cxf-http-jetty.jar here. So if users do not want to use jetty, they
just don't put cxf-http-jetty jar into their classpath. So this works
I believe, the only issue is that users wont be able to use that
single cxf-bundle jar ( I believe we do want Jetty stuff in our
cxf-bundle jar as this is our default support for http, don't we?)
Right. That's exactly what I mean. For "normal" users using the bundle
jar, no impact. However, for the embedded developers using the full
module approach (expecially those using Maven), they can selectively not
include the Jetty stuff if they don't want/need it.
