I'm sorry, it's tied to the "http" implementation as the
HTTPTransportFactory generates the HTTPConduit and is also hardcoded to
spit out JettyDesintations. That kind of ties them both together.
-Polar
Glynn, Eoghan wrote:
-----Original Message-----
From: Polar Humenn [mailto:[EMAIL PROTECTED]
Sent: 03 April 2007 21:26
To: [email protected]
Subject: Re: Jetty dependency
I specifically think this is the right approach.
Me too.
Right now the HTTPConduit is tied to using JettyDestinations.
How is the HTTPConduit tied to using JettyDestinations?
It gets a decoupled Destination via whatever DestinationFactory happens
to registered with the DestinationFactoryManager against http:// sytle
URIs.
Where's the hard jetty dependence in HTTPConduit?
/Eoghan
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.
