You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Jarek Gawor <jg...@gmail.com> on 2007/04/01 06:51:32 UTC
Jetty dependency
Using the latest snapshot I see the following error:
java.lang.NoClassDefFoundError: org/mortbay/jetty/Connector
at org.apache.cxf.transport.http.JettyHTTPDestination.retrieveEngine(JettyHTTPDestination.java:87)
at org.apache.cxf.transport.http.HTTPTransportFactory.getDestination(HTTPTransportFactory.java:123)
at org.apache.cxf.binding.soap.SoapTransportFactory.getDestination(SoapTransportFactory.java:74)
at org.apache.cxf.endpoint.ServerImpl.<init>(ServerImpl.java:77)
at org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:86)
Is this dependency required? I thought it was removed.
Thanks,
Jarek
Re: Jetty dependency
Posted by Daniel Kulp <dk...@apache.org>.
Actually, I already have this 80% done (I'm running into some of the same
issues the Geronimo folks are running into related to this). Thus,
I'll just finish it up and get it committed.
Dan
On Tuesday 03 April 2007 22:36, Liu, Jervis wrote:
> Hi, if there is no further objection, I will create a jira task to
> separate http into two modules. I will be working on this probably end
> of this week or early next week.
>
> Cheers,
> Jervis
>
> > -----Original Message-----
> > From: Polar Humenn [mailto:phumenn@iona.com]
> > Sent: 2007?4?4? 4:26
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Jetty dependency
> >
> >
> > 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.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
RE: Jetty dependency
Posted by "Liu, Jervis" <jl...@iona.com>.
Hi, if there is no further objection, I will create a jira task to separate http into two modules. I will be working on this probably end of this week or early next week.
Cheers,
Jervis
> -----Original Message-----
> From: Polar Humenn [mailto:phumenn@iona.com]
> Sent: 2007?4?4? 4:26
> To: cxf-dev@incubator.apache.org
> Subject: Re: Jetty dependency
>
>
> 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.
> >
> >
> >
>
>
RE: Jetty dependency
Posted by "Glynn, Eoghan" <eo...@iona.com>.
Well thats a different issue entirely, and trivial to solve by splitting
the HTTPTransportFactory into its constituent ConduitInitiator and
DestinationFactory components.
But it has no bearing what-so-ever on the conduit & decoupled
destination debate, as per your digression.
/Eoghan
> -----Original Message-----
> From: Polar Humenn [mailto:phumenn@iona.com]
> Sent: 04 April 2007 19:33
> To: cxf-dev@incubator.apache.org
> Subject: Re: Jetty dependency
>
> 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:phumenn@iona.com]
> >> Sent: 03 April 2007 21:26
> >> To: cxf-dev@incubator.apache.org
> >> 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.
> >>>
> >>>
> >>>
> >>>
> >>
>
>
Re: Jetty dependency
Posted by Polar Humenn <ph...@iona.com>.
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:phumenn@iona.com]
>> Sent: 03 April 2007 21:26
>> To: cxf-dev@incubator.apache.org
>> 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.
>>>
>>>
>>>
>>>
>>
RE: Jetty dependency
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----Original Message-----
> From: Polar Humenn [mailto:phumenn@iona.com]
> Sent: 03 April 2007 21:26
> To: cxf-dev@incubator.apache.org
> 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.
> >
> >
> >
>
>
Re: Jetty dependency
Posted by Polar Humenn <ph...@iona.com>.
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.
>
>
>
Re: Jetty dependency
Posted by Daniel Kulp <dk...@apache.org>.
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.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
RE: Jetty dependency
Posted by "Liu, Jervis" <jl...@iona.com>.
> -----Original Message-----
> From: Liu, Jervis [mailto:jliu@iona.com]
> Sent: 2007?4?4? 0:40
> To: cxf-dev@incubator.apache.org
> Subject: RE: Jetty dependency
>
>
>
>
> > -----Original Message-----
> > From: Daniel Kulp [mailto:dkulp@apache.org]
> > Sent: 2007?4?3? 22:58
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Jetty dependency
> >
> >
> >
> >
> > Honestly, I think what makes the most sense is to split the
> > http module
> > into two parts:
> >
> > http - would just contain the base classes and the servlet.
> > It wouldn't
> > actually register anything.
> >
> > http-jetty - would be the Jetty implementation
> >
> >
> > Thus, third parties that want to use the HTTP support but not
> > jetty would
> > have something that works. Also, the "servlet" case
> > (example, running
> > in tomcat) wouldn't bring the Jetty classes in either.
> >
>
> 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?)
> > Dan
> >
> >
> >
> > On Tuesday 03 April 2007 10:34, Jarek Gawor wrote:
> > > The Geronimo integration code is (somewhat) based on the
> CXFServlet.
> > > That is, it explicitly registers our
> GeronimoDestinationFactory with
> > > the DestinationFactoryManager using registerDestinationFactory
> > > function. The problem is (as we discovered with Daniel
> D.) that when
> > > I'm publishing a service and ServerFactoryBean.create() is
> > called, the
> > > ExtensionManagerImpl kicks in and eventually causes the
> > > GeronimoDestinationFactory to be replaced with the default ones.
> > > Here's the stack trace when the overwrite happens:
> > >
> > >
> >
> org.apache.cxf.transport.DestinationFactoryManagerImpl.registerDestina
> > >tionFactory(DestinationFactoryManagerImpl.java:75) at
> > >
> >
> org.apache.cxf.binding.soap.SoapTransportFactory.registerWithBindingMa
> > >nager(SoapTransportFactory.java:183) at
> > > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> > >
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> > >ava:39) at
> > >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
> > >orImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585)
> > > at
> > >
> >
> org.apache.cxf.common.injection.ResourceInjector.invokePostConstruct(R
> > >esourceInjector.java:288) at
> > >
> >
> org.apache.cxf.common.injection.ResourceInjector.inject(ResourceInject
> > >or.java:79) at
> > >
> >
> org.apache.cxf.bus.extension.ExtensionManagerImpl.loadAndRegister(Exte
> > >nsionManagerImpl.java:154) at
> > >
> >
> org.apache.cxf.bus.extension.ExtensionManagerImpl.activateViaNS(Extens
> > >ionManagerImpl.java:84) at
> > >
> org.apache.cxf.bus.extension.DeferredMap.get(DeferredMap.java:42) at
> > >
> >
> org.apache.cxf.transport.DestinationFactoryManagerImpl.getDestinationF
> > >actory(DestinationFactoryManagerImpl.java:103) at
> > >
> >
> org.apache.cxf.frontend.AbstractEndpointFactory.createEndpointInfo(Abs
> > >tractEndpointFactory.java:157) at
> > >
> >
> org.apache.cxf.frontend.AbstractEndpointFactory.createEndpoint(Abstrac
> > >tEndpointFactory.java:86) at
> > >
> >
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.jav
> > >a:85)
> > >
> > > Thanks,
> > > Jarek
> > >
> > > On 4/3/07, Liu, Jervis <jl...@iona.com> wrote:
> > > > Hi Jarek, as Willem already mentioned, the stack trace
> showed that
> > > > you still got HTTPTransportFactory instead of
> > > > GeronimoDestinationFactory. At the moment, there are two ways to
> > > > associate DestinationFactory with namespaces. One way to
> > do this is
> > > > providing a CXF extension file, for example, the
> > > >
> > cxf\trunk\rt\transports\http\src\main\resources\META-INF\cxf\cxf-ext
> > > >ension-http.xml, in your case, you can provide a
> > > > cxf-extension-geronimo.xml. When CXF bus starts up, it loads all
> > > > extension files, "IF" your cxf-extension-geronimo.xml is loaded
> > > > after cxf-extension-http.xml, then all relevant
> namespaces will be
> > > > associated with GeronimoDestinationFactory. As
> > > > GeronimoDestinationFactory and HTTPTransportFactory are
> > associated
> > > > with same name spaces, this approach wont work as there is no
> > > > guarantee which one is getting loaded first. The second
> > approach is
> > > > explicitly replacing namespace registry,
> > > > CXFServlet.replaceDestionFactory() shows how to do
> this. The trick
> > > > is that you have to make sure you do this after bus has
> > started up,
> > > > but before DestinationFactory .getDestination() is
> getting called.
> > > > If you can not use the second approach, we probably
> needs to come
> > > > out with sth new.
> > > >
> > > > Cheers,
> > > > Jervis
> > > >
> > > > > -----Original Message-----
> > > > > From: Willem Jiang [mailto:ning.jiang@iona.com]
> > > > > Sent: 2007?4?3? 11:55
> > > > > To: cxf-dev@incubator.apache.org
> > > > > Subject: Re: Jetty dependency
> > > > >
> > > > >
> > > > > Hi Jarek,
> > > > >
> > > > > It looks like the HTTPTransportFactory has been
> > registered to the
> > > > > bus and your GeronimoDestinationFactory did not replace it.
> > > > > CXF Bus will try to load the all cxf-extention-*.xml
> by default.
> > > > > You may exclude the cxf-extention-http.xml from the jar or
> > > > > just do like
> > > > > the CXFServlet to register all the http transport related
> > > > > namespace again.
> > > > >
> > > > > I just noticed Dan committed a patch for this, but I think
> > > > > you need to
> > > > > make sure GeronimoDestinationFactory be registered to the bus
> > > > > before the
> > > > > HTTPTransportFactory.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Willem.
> > > > >
> > > > > Jarek Gawor wrote:
> > > > > > Hi Dan,
> > > > > >
> > > > > > Any news on this issue?
> > > > > >
> > > > > > Thanks,
> > > > > > Jarek
> > > > > >
> > > > > > On 4/1/07, Jarek Gawor <jg...@gmail.com> wrote:
> > > > > >> No, I'm not using CXFServlet. Ok, thanks.
> > > > > >>
> > > > > >> Our GeronimoDestinationFactory extends
> > > > >
> > > > > HTTPTransportFactory and we do
> > > > >
> > > > > >> overwrite the getDestination() method so maybe something
> > > > >
> > > > > doesn't get
> > > > >
> > > > > >> registered properly as before.
> > > > > >>
> > > > > >> Jarek
> > > > > >>
> > > > > >> On 4/1/07, Dan Diephouse <da...@envoisolutions.com> wrote:
> > > > > >> > Are you using the CXFServlet? If so, then CXF
> > should use the
> > > > > >> > ServletTransportFactory as it's transport (and not
> > > > >
> > > > > require jetty).
> > > > >
> > > > > >> > Otherwise, it should use Jetty as it's transport.
> > > > > >> >
> > > > > >> > Maybe I messed things up with my latest changes to
> > CXFServlet
> > > > > >>
> > > > > >> though. I will
> > > > > >>
> > > > > >> > have to take a deeper look tomorrow when I'm more awake.
> > > > >
> > > > > I'll get
> > > > >
> > > > > >> back to
> > > > > >>
> > > > > >> > you soon.
> > > > > >> >
> > > > > >> > Thanks,
> > > > > >> > Dan
> > > > > >> >
> > > > > >> > On 3/31/07, Jarek Gawor <jg...@gmail.com> wrote:
> > > > > >> > > Using the latest snapshot I see the following error:
> > > > > >> > >
> > > > > >> > > java.lang.NoClassDefFoundError:
> > org/mortbay/jetty/Connector
> > > > > >> > > at
> > > > >
> > > > >
> > org.apache.cxf.transport.http.JettyHTTPDestination.retrieveEngine(
> > > > >
> > > > > >> > > JettyHTTPDestination.java:87)
> > > > > >> > > at
> > > > >
> > > > >
> > org.apache.cxf.transport.http.HTTPTransportFactory.getDestination(
> > > > >
> > > > > >> > > HTTPTransportFactory.java:123)
> > > > > >> > > at
> > > > > >>
> > > > > >>
> > org.apache.cxf.binding.soap.SoapTransportFactory.getDestination
> > > > > >>
> > > > > >> > > (SoapTransportFactory.java:74)
> > > > > >> > > at
> > > > > >>
> > > > > >>
> org.apache.cxf.endpoint.ServerImpl.<init>(ServerImpl.java:77)
> > > > > >>
> > > > > >> > > at
> > > > > >> > > org.apache.cxf.frontend.ServerFactoryBean.create(
> > > > > >> > > ServerFactoryBean.java:86)
> > > > > >> > >
> > > > > >> > > Is this dependency required? I thought it was removed.
> > > > > >> > >
> > > > > >> > > Thanks,
> > > > > >> > > Jarek
> > > > > >> >
> > > > > >> > --
> > > > > >> > Dan Diephouse
> > > > > >> > Envoi Solutions
> > > > > >> > http://envoisolutions.com | http://netzooid.com/blog
> >
> > --
> > J. Daniel Kulp
> > Principal Engineer
> > IONA
> > P: 781-902-8727 C: 508-380-7194
> > daniel.kulp@iona.com
> > http://www.dankulp.com/blog
> >
>
RE: Jetty dependency
Posted by "Liu, Jervis" <jl...@iona.com>.
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: 2007?4?3? 22:58
> To: cxf-dev@incubator.apache.org
> Subject: Re: Jetty dependency
>
>
>
>
> Honestly, I think what makes the most sense is to split the
> http module
> into two parts:
>
> http - would just contain the base classes and the servlet.
> It wouldn't
> actually register anything.
>
> http-jetty - would be the Jetty implementation
>
>
> Thus, third parties that want to use the HTTP support but not
> jetty would
> have something that works. Also, the "servlet" case
> (example, running
> in tomcat) wouldn't bring the Jetty classes in either.
>
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...
>
> Dan
>
>
>
> On Tuesday 03 April 2007 10:34, Jarek Gawor wrote:
> > The Geronimo integration code is (somewhat) based on the CXFServlet.
> > That is, it explicitly registers our GeronimoDestinationFactory with
> > the DestinationFactoryManager using registerDestinationFactory
> > function. The problem is (as we discovered with Daniel D.) that when
> > I'm publishing a service and ServerFactoryBean.create() is
> called, the
> > ExtensionManagerImpl kicks in and eventually causes the
> > GeronimoDestinationFactory to be replaced with the default ones.
> > Here's the stack trace when the overwrite happens:
> >
> >
> org.apache.cxf.transport.DestinationFactoryManagerImpl.registerDestina
> >tionFactory(DestinationFactoryManagerImpl.java:75) at
> >
> org.apache.cxf.binding.soap.SoapTransportFactory.registerWithBindingMa
> >nager(SoapTransportFactory.java:183) at
> > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> >ava:39) at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
> >orImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585)
> > at
> >
> org.apache.cxf.common.injection.ResourceInjector.invokePostConstruct(R
> >esourceInjector.java:288) at
> >
> org.apache.cxf.common.injection.ResourceInjector.inject(ResourceInject
> >or.java:79) at
> >
> org.apache.cxf.bus.extension.ExtensionManagerImpl.loadAndRegister(Exte
> >nsionManagerImpl.java:154) at
> >
> org.apache.cxf.bus.extension.ExtensionManagerImpl.activateViaNS(Extens
> >ionManagerImpl.java:84) at
> > org.apache.cxf.bus.extension.DeferredMap.get(DeferredMap.java:42) at
> >
> org.apache.cxf.transport.DestinationFactoryManagerImpl.getDestinationF
> >actory(DestinationFactoryManagerImpl.java:103) at
> >
> org.apache.cxf.frontend.AbstractEndpointFactory.createEndpointInfo(Abs
> >tractEndpointFactory.java:157) at
> >
> org.apache.cxf.frontend.AbstractEndpointFactory.createEndpoint(Abstrac
> >tEndpointFactory.java:86) at
> >
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.jav
> >a:85)
> >
> > Thanks,
> > Jarek
> >
> > On 4/3/07, Liu, Jervis <jl...@iona.com> wrote:
> > > Hi Jarek, as Willem already mentioned, the stack trace showed that
> > > you still got HTTPTransportFactory instead of
> > > GeronimoDestinationFactory. At the moment, there are two ways to
> > > associate DestinationFactory with namespaces. One way to
> do this is
> > > providing a CXF extension file, for example, the
> > >
> cxf\trunk\rt\transports\http\src\main\resources\META-INF\cxf\cxf-ext
> > >ension-http.xml, in your case, you can provide a
> > > cxf-extension-geronimo.xml. When CXF bus starts up, it loads all
> > > extension files, "IF" your cxf-extension-geronimo.xml is loaded
> > > after cxf-extension-http.xml, then all relevant namespaces will be
> > > associated with GeronimoDestinationFactory. As
> > > GeronimoDestinationFactory and HTTPTransportFactory are
> associated
> > > with same name spaces, this approach wont work as there is no
> > > guarantee which one is getting loaded first. The second
> approach is
> > > explicitly replacing namespace registry,
> > > CXFServlet.replaceDestionFactory() shows how to do this. The trick
> > > is that you have to make sure you do this after bus has
> started up,
> > > but before DestinationFactory .getDestination() is getting called.
> > > If you can not use the second approach, we probably needs to come
> > > out with sth new.
> > >
> > > Cheers,
> > > Jervis
> > >
> > > > -----Original Message-----
> > > > From: Willem Jiang [mailto:ning.jiang@iona.com]
> > > > Sent: 2007?4?3? 11:55
> > > > To: cxf-dev@incubator.apache.org
> > > > Subject: Re: Jetty dependency
> > > >
> > > >
> > > > Hi Jarek,
> > > >
> > > > It looks like the HTTPTransportFactory has been
> registered to the
> > > > bus and your GeronimoDestinationFactory did not replace it.
> > > > CXF Bus will try to load the all cxf-extention-*.xml by default.
> > > > You may exclude the cxf-extention-http.xml from the jar or
> > > > just do like
> > > > the CXFServlet to register all the http transport related
> > > > namespace again.
> > > >
> > > > I just noticed Dan committed a patch for this, but I think
> > > > you need to
> > > > make sure GeronimoDestinationFactory be registered to the bus
> > > > before the
> > > > HTTPTransportFactory.
> > > >
> > > > Cheers,
> > > >
> > > > Willem.
> > > >
> > > > Jarek Gawor wrote:
> > > > > Hi Dan,
> > > > >
> > > > > Any news on this issue?
> > > > >
> > > > > Thanks,
> > > > > Jarek
> > > > >
> > > > > On 4/1/07, Jarek Gawor <jg...@gmail.com> wrote:
> > > > >> No, I'm not using CXFServlet. Ok, thanks.
> > > > >>
> > > > >> Our GeronimoDestinationFactory extends
> > > >
> > > > HTTPTransportFactory and we do
> > > >
> > > > >> overwrite the getDestination() method so maybe something
> > > >
> > > > doesn't get
> > > >
> > > > >> registered properly as before.
> > > > >>
> > > > >> Jarek
> > > > >>
> > > > >> On 4/1/07, Dan Diephouse <da...@envoisolutions.com> wrote:
> > > > >> > Are you using the CXFServlet? If so, then CXF
> should use the
> > > > >> > ServletTransportFactory as it's transport (and not
> > > >
> > > > require jetty).
> > > >
> > > > >> > Otherwise, it should use Jetty as it's transport.
> > > > >> >
> > > > >> > Maybe I messed things up with my latest changes to
> CXFServlet
> > > > >>
> > > > >> though. I will
> > > > >>
> > > > >> > have to take a deeper look tomorrow when I'm more awake.
> > > >
> > > > I'll get
> > > >
> > > > >> back to
> > > > >>
> > > > >> > you soon.
> > > > >> >
> > > > >> > Thanks,
> > > > >> > Dan
> > > > >> >
> > > > >> > On 3/31/07, Jarek Gawor <jg...@gmail.com> wrote:
> > > > >> > > Using the latest snapshot I see the following error:
> > > > >> > >
> > > > >> > > java.lang.NoClassDefFoundError:
> org/mortbay/jetty/Connector
> > > > >> > > at
> > > >
> > > >
> org.apache.cxf.transport.http.JettyHTTPDestination.retrieveEngine(
> > > >
> > > > >> > > JettyHTTPDestination.java:87)
> > > > >> > > at
> > > >
> > > >
> org.apache.cxf.transport.http.HTTPTransportFactory.getDestination(
> > > >
> > > > >> > > HTTPTransportFactory.java:123)
> > > > >> > > at
> > > > >>
> > > > >>
> org.apache.cxf.binding.soap.SoapTransportFactory.getDestination
> > > > >>
> > > > >> > > (SoapTransportFactory.java:74)
> > > > >> > > at
> > > > >>
> > > > >> org.apache.cxf.endpoint.ServerImpl.<init>(ServerImpl.java:77)
> > > > >>
> > > > >> > > at
> > > > >> > > org.apache.cxf.frontend.ServerFactoryBean.create(
> > > > >> > > ServerFactoryBean.java:86)
> > > > >> > >
> > > > >> > > Is this dependency required? I thought it was removed.
> > > > >> > >
> > > > >> > > Thanks,
> > > > >> > > Jarek
> > > > >> >
> > > > >> > --
> > > > >> > Dan Diephouse
> > > > >> > Envoi Solutions
> > > > >> > http://envoisolutions.com | http://netzooid.com/blog
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
>
Re: Jetty dependency
Posted by Daniel Kulp <dk...@apache.org>.
Honestly, I think what makes the most sense is to split the http module
into two parts:
http - would just contain the base classes and the servlet. It wouldn't
actually register anything.
http-jetty - would be the Jetty implementation
Thus, third parties that want to use the HTTP support but not jetty would
have something that works. Also, the "servlet" case (example, running
in tomcat) wouldn't bring the Jetty classes in either.
Dan
On Tuesday 03 April 2007 10:34, Jarek Gawor wrote:
> The Geronimo integration code is (somewhat) based on the CXFServlet.
> That is, it explicitly registers our GeronimoDestinationFactory with
> the DestinationFactoryManager using registerDestinationFactory
> function. The problem is (as we discovered with Daniel D.) that when
> I'm publishing a service and ServerFactoryBean.create() is called, the
> ExtensionManagerImpl kicks in and eventually causes the
> GeronimoDestinationFactory to be replaced with the default ones.
> Here's the stack trace when the overwrite happens:
>
> org.apache.cxf.transport.DestinationFactoryManagerImpl.registerDestina
>tionFactory(DestinationFactoryManagerImpl.java:75) at
> org.apache.cxf.binding.soap.SoapTransportFactory.registerWithBindingMa
>nager(SoapTransportFactory.java:183) at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
>ava:39) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
>orImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.cxf.common.injection.ResourceInjector.invokePostConstruct(R
>esourceInjector.java:288) at
> org.apache.cxf.common.injection.ResourceInjector.inject(ResourceInject
>or.java:79) at
> org.apache.cxf.bus.extension.ExtensionManagerImpl.loadAndRegister(Exte
>nsionManagerImpl.java:154) at
> org.apache.cxf.bus.extension.ExtensionManagerImpl.activateViaNS(Extens
>ionManagerImpl.java:84) at
> org.apache.cxf.bus.extension.DeferredMap.get(DeferredMap.java:42) at
> org.apache.cxf.transport.DestinationFactoryManagerImpl.getDestinationF
>actory(DestinationFactoryManagerImpl.java:103) at
> org.apache.cxf.frontend.AbstractEndpointFactory.createEndpointInfo(Abs
>tractEndpointFactory.java:157) at
> org.apache.cxf.frontend.AbstractEndpointFactory.createEndpoint(Abstrac
>tEndpointFactory.java:86) at
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.jav
>a:85)
>
> Thanks,
> Jarek
>
> On 4/3/07, Liu, Jervis <jl...@iona.com> wrote:
> > Hi Jarek, as Willem already mentioned, the stack trace showed that
> > you still got HTTPTransportFactory instead of
> > GeronimoDestinationFactory. At the moment, there are two ways to
> > associate DestinationFactory with namespaces. One way to do this is
> > providing a CXF extension file, for example, the
> > cxf\trunk\rt\transports\http\src\main\resources\META-INF\cxf\cxf-ext
> >ension-http.xml, in your case, you can provide a
> > cxf-extension-geronimo.xml. When CXF bus starts up, it loads all
> > extension files, "IF" your cxf-extension-geronimo.xml is loaded
> > after cxf-extension-http.xml, then all relevant namespaces will be
> > associated with GeronimoDestinationFactory. As
> > GeronimoDestinationFactory and HTTPTransportFactory are associated
> > with same name spaces, this approach wont work as there is no
> > guarantee which one is getting loaded first. The second approach is
> > explicitly replacing namespace registry,
> > CXFServlet.replaceDestionFactory() shows how to do this. The trick
> > is that you have to make sure you do this after bus has started up,
> > but before DestinationFactory .getDestination() is getting called.
> > If you can not use the second approach, we probably needs to come
> > out with sth new.
> >
> > Cheers,
> > Jervis
> >
> > > -----Original Message-----
> > > From: Willem Jiang [mailto:ning.jiang@iona.com]
> > > Sent: 2007?4?3? 11:55
> > > To: cxf-dev@incubator.apache.org
> > > Subject: Re: Jetty dependency
> > >
> > >
> > > Hi Jarek,
> > >
> > > It looks like the HTTPTransportFactory has been registered to the
> > > bus and your GeronimoDestinationFactory did not replace it.
> > > CXF Bus will try to load the all cxf-extention-*.xml by default.
> > > You may exclude the cxf-extention-http.xml from the jar or
> > > just do like
> > > the CXFServlet to register all the http transport related
> > > namespace again.
> > >
> > > I just noticed Dan committed a patch for this, but I think
> > > you need to
> > > make sure GeronimoDestinationFactory be registered to the bus
> > > before the
> > > HTTPTransportFactory.
> > >
> > > Cheers,
> > >
> > > Willem.
> > >
> > > Jarek Gawor wrote:
> > > > Hi Dan,
> > > >
> > > > Any news on this issue?
> > > >
> > > > Thanks,
> > > > Jarek
> > > >
> > > > On 4/1/07, Jarek Gawor <jg...@gmail.com> wrote:
> > > >> No, I'm not using CXFServlet. Ok, thanks.
> > > >>
> > > >> Our GeronimoDestinationFactory extends
> > >
> > > HTTPTransportFactory and we do
> > >
> > > >> overwrite the getDestination() method so maybe something
> > >
> > > doesn't get
> > >
> > > >> registered properly as before.
> > > >>
> > > >> Jarek
> > > >>
> > > >> On 4/1/07, Dan Diephouse <da...@envoisolutions.com> wrote:
> > > >> > Are you using the CXFServlet? If so, then CXF should use the
> > > >> > ServletTransportFactory as it's transport (and not
> > >
> > > require jetty).
> > >
> > > >> > Otherwise, it should use Jetty as it's transport.
> > > >> >
> > > >> > Maybe I messed things up with my latest changes to CXFServlet
> > > >>
> > > >> though. I will
> > > >>
> > > >> > have to take a deeper look tomorrow when I'm more awake.
> > >
> > > I'll get
> > >
> > > >> back to
> > > >>
> > > >> > you soon.
> > > >> >
> > > >> > Thanks,
> > > >> > Dan
> > > >> >
> > > >> > On 3/31/07, Jarek Gawor <jg...@gmail.com> wrote:
> > > >> > > Using the latest snapshot I see the following error:
> > > >> > >
> > > >> > > java.lang.NoClassDefFoundError: org/mortbay/jetty/Connector
> > > >> > > at
> > >
> > > org.apache.cxf.transport.http.JettyHTTPDestination.retrieveEngine(
> > >
> > > >> > > JettyHTTPDestination.java:87)
> > > >> > > at
> > >
> > > org.apache.cxf.transport.http.HTTPTransportFactory.getDestination(
> > >
> > > >> > > HTTPTransportFactory.java:123)
> > > >> > > at
> > > >>
> > > >> org.apache.cxf.binding.soap.SoapTransportFactory.getDestination
> > > >>
> > > >> > > (SoapTransportFactory.java:74)
> > > >> > > at
> > > >>
> > > >> org.apache.cxf.endpoint.ServerImpl.<init>(ServerImpl.java:77)
> > > >>
> > > >> > > at
> > > >> > > org.apache.cxf.frontend.ServerFactoryBean.create(
> > > >> > > ServerFactoryBean.java:86)
> > > >> > >
> > > >> > > Is this dependency required? I thought it was removed.
> > > >> > >
> > > >> > > Thanks,
> > > >> > > Jarek
> > > >> >
> > > >> > --
> > > >> > Dan Diephouse
> > > >> > Envoi Solutions
> > > >> > http://envoisolutions.com | http://netzooid.com/blog
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: Jetty dependency
Posted by Jarek Gawor <jg...@gmail.com>.
I found a workaround for this issue. I call the following first and
then I do the overwrites:
bus.getExtension(BindingFactoryManager.class).getBindingFactory("http://schemas.xmlsoap.org/wsdl/soap/http");
Here's my understanding. The ExtensionManagerImpl activates extensions
based on a namespace and there can be more then one extensions
registered for the same namespace. For example,
"http://www.w3.org/2003/05/soap/bindings/HTTP/" is used as a
BindingFactory and TransportFactory. So say we have namespace 'A' that
has two different extensions E1 and E2 registered. If I overwrite the
namespace 'A' in E1 but call E2.get('A') the ExtensionManagerImpl will
activate both of these extensions. And if E1 has a default for
namespace 'A' then whatever I originally registered for that namespace
will be replaced with the default.
Also, a similar problem exists with one extension and two namespaces.
For example, using the following program:
dfm.registerDestinationFactory("http://cxf.apache.org/transports/http/configuration",
factory);
System.out.println(dfm.getDestinationFactory("http://cxf.apache.org/transports/http/configuration"));
System.out.println(dfm.getDestinationFactory("http://schemas.xmlsoap.org/wsdl/http/"));
System.out.println(dfm.getDestinationFactory("http://cxf.apache.org/transports/http/configuration"));
I would expect the output to be:
org.apache.geronimo.cxf.GeronimoDestinationFactory@4e19a1
org.apache.cxf.transport.http.HTTPTransportFactory@bf091d
org.apache.geronimo.cxf.GeronimoDestinationFactory@4e19a1
but I get:
org.apache.geronimo.cxf.GeronimoDestinationFactory@4e19a1
org.apache.cxf.transport.http.HTTPTransportFactory@bf091d
org.apache.cxf.transport.http.HTTPTransportFactory@bf091d
Jarek
On 4/3/07, Jarek Gawor <jg...@gmail.com> wrote:
> The Geronimo integration code is (somewhat) based on the CXFServlet.
> That is, it explicitly registers our GeronimoDestinationFactory with
> the DestinationFactoryManager using registerDestinationFactory
> function. The problem is (as we discovered with Daniel D.) that when
> I'm publishing a service and ServerFactoryBean.create() is called, the
> ExtensionManagerImpl kicks in and eventually causes the
> GeronimoDestinationFactory to be replaced with the default ones.
> Here's the stack trace when the overwrite happens:
> org.apache.cxf.transport.DestinationFactoryManagerImpl.registerDestinationFactory(DestinationFactoryManagerImpl.java:75)
> at org.apache.cxf.binding.soap.SoapTransportFactory.registerWithBindingManager(SoapTransportFactory.java:183)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.apache.cxf.common.injection.ResourceInjector.invokePostConstruct(ResourceInjector.java:288)
> at org.apache.cxf.common.injection.ResourceInjector.inject(ResourceInjector.java:79)
> at org.apache.cxf.bus.extension.ExtensionManagerImpl.loadAndRegister(ExtensionManagerImpl.java:154)
> at org.apache.cxf.bus.extension.ExtensionManagerImpl.activateViaNS(ExtensionManagerImpl.java:84)
> at org.apache.cxf.bus.extension.DeferredMap.get(DeferredMap.java:42)
> at org.apache.cxf.transport.DestinationFactoryManagerImpl.getDestinationFactory(DestinationFactoryManagerImpl.java:103)
> at org.apache.cxf.frontend.AbstractEndpointFactory.createEndpointInfo(AbstractEndpointFactory.java:157)
> at org.apache.cxf.frontend.AbstractEndpointFactory.createEndpoint(AbstractEndpointFactory.java:86)
> at org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:85)
>
> Thanks,
> Jarek
>
> On 4/3/07, Liu, Jervis <jl...@iona.com> wrote:
> > Hi Jarek, as Willem already mentioned, the stack trace showed that you still got HTTPTransportFactory instead of GeronimoDestinationFactory. At the moment, there are two ways to associate DestinationFactory with namespaces. One way to do this is providing a CXF extension file, for example, the cxf\trunk\rt\transports\http\src\main\resources\META-INF\cxf\cxf-extension-http.xml, in your case, you can provide a cxf-extension-geronimo.xml. When CXF bus starts up, it loads all extension files, "IF" your cxf-extension-geronimo.xml is loaded after cxf-extension-http.xml, then all relevant namespaces will be associated with GeronimoDestinationFactory. As GeronimoDestinationFactory and HTTPTransportFactory are associated with same name spaces, this approach wont work as there is no guarantee which one is getting loaded first. The second approach is explicitly replacing namespace registry, CXFServlet.replaceDestionFactory() shows how to do this. The trick is that you have to make sure you do this after bus has started up, but before DestinationFactory .getDestination() is getting called. If you can not use the second approach, we probably needs to come out with sth new.
> >
> > Cheers,
> > Jervis
> >
> > > -----Original Message-----
> > > From: Willem Jiang [mailto:ning.jiang@iona.com]
> > > Sent: 2007?4?3? 11:55
> > > To: cxf-dev@incubator.apache.org
> > > Subject: Re: Jetty dependency
> > >
> > >
> > > Hi Jarek,
> > >
> > > It looks like the HTTPTransportFactory has been registered to the bus
> > > and your GeronimoDestinationFactory did not replace it.
> > > CXF Bus will try to load the all cxf-extention-*.xml by default.
> > > You may exclude the cxf-extention-http.xml from the jar or
> > > just do like
> > > the CXFServlet to register all the http transport related
> > > namespace again.
> > >
> > > I just noticed Dan committed a patch for this, but I think
> > > you need to
> > > make sure GeronimoDestinationFactory be registered to the bus
> > > before the
> > > HTTPTransportFactory.
> > >
> > > Cheers,
> > >
> > > Willem.
> > >
> > > Jarek Gawor wrote:
> > > > Hi Dan,
> > > >
> > > > Any news on this issue?
> > > >
> > > > Thanks,
> > > > Jarek
> > > >
> > > > On 4/1/07, Jarek Gawor <jg...@gmail.com> wrote:
> > > >> No, I'm not using CXFServlet. Ok, thanks.
> > > >>
> > > >> Our GeronimoDestinationFactory extends
> > > HTTPTransportFactory and we do
> > > >> overwrite the getDestination() method so maybe something
> > > doesn't get
> > > >> registered properly as before.
> > > >>
> > > >> Jarek
> > > >>
> > > >> On 4/1/07, Dan Diephouse <da...@envoisolutions.com> wrote:
> > > >> > Are you using the CXFServlet? If so, then CXF should use the
> > > >> > ServletTransportFactory as it's transport (and not
> > > require jetty).
> > > >> > Otherwise, it should use Jetty as it's transport.
> > > >> >
> > > >> > Maybe I messed things up with my latest changes to CXFServlet
> > > >> though. I will
> > > >> > have to take a deeper look tomorrow when I'm more awake.
> > > I'll get
> > > >> back to
> > > >> > you soon.
> > > >> >
> > > >> > Thanks,
> > > >> > Dan
> > > >> >
> > > >> > On 3/31/07, Jarek Gawor <jg...@gmail.com> wrote:
> > > >> > >
> > > >> > > Using the latest snapshot I see the following error:
> > > >> > >
> > > >> > > java.lang.NoClassDefFoundError: org/mortbay/jetty/Connector
> > > >> > > at
> > > >> > >
> > > org.apache.cxf.transport.http.JettyHTTPDestination.retrieveEngine(
> > > >> > > JettyHTTPDestination.java:87)
> > > >> > > at
> > > >> > >
> > > org.apache.cxf.transport.http.HTTPTransportFactory.getDestination(
> > > >> > > HTTPTransportFactory.java:123)
> > > >> > > at
> > > >> org.apache.cxf.binding.soap.SoapTransportFactory.getDestination
> > > >> > > (SoapTransportFactory.java:74)
> > > >> > > at
> > > >> org.apache.cxf.endpoint.ServerImpl.<init>(ServerImpl.java:77)
> > > >> > > at org.apache.cxf.frontend.ServerFactoryBean.create(
> > > >> > > ServerFactoryBean.java:86)
> > > >> > >
> > > >> > > Is this dependency required? I thought it was removed.
> > > >> > >
> > > >> > > Thanks,
> > > >> > > Jarek
> > > >> > >
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Dan Diephouse
> > > >> > Envoi Solutions
> > > >> > http://envoisolutions.com | http://netzooid.com/blog
> > > >> >
> > > >>
> > > >
> > >
> > >
> >
>
Re: Jetty dependency
Posted by Jarek Gawor <jg...@gmail.com>.
The Geronimo integration code is (somewhat) based on the CXFServlet.
That is, it explicitly registers our GeronimoDestinationFactory with
the DestinationFactoryManager using registerDestinationFactory
function. The problem is (as we discovered with Daniel D.) that when
I'm publishing a service and ServerFactoryBean.create() is called, the
ExtensionManagerImpl kicks in and eventually causes the
GeronimoDestinationFactory to be replaced with the default ones.
Here's the stack trace when the overwrite happens:
org.apache.cxf.transport.DestinationFactoryManagerImpl.registerDestinationFactory(DestinationFactoryManagerImpl.java:75)
at org.apache.cxf.binding.soap.SoapTransportFactory.registerWithBindingManager(SoapTransportFactory.java:183)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.cxf.common.injection.ResourceInjector.invokePostConstruct(ResourceInjector.java:288)
at org.apache.cxf.common.injection.ResourceInjector.inject(ResourceInjector.java:79)
at org.apache.cxf.bus.extension.ExtensionManagerImpl.loadAndRegister(ExtensionManagerImpl.java:154)
at org.apache.cxf.bus.extension.ExtensionManagerImpl.activateViaNS(ExtensionManagerImpl.java:84)
at org.apache.cxf.bus.extension.DeferredMap.get(DeferredMap.java:42)
at org.apache.cxf.transport.DestinationFactoryManagerImpl.getDestinationFactory(DestinationFactoryManagerImpl.java:103)
at org.apache.cxf.frontend.AbstractEndpointFactory.createEndpointInfo(AbstractEndpointFactory.java:157)
at org.apache.cxf.frontend.AbstractEndpointFactory.createEndpoint(AbstractEndpointFactory.java:86)
at org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:85)
Thanks,
Jarek
On 4/3/07, Liu, Jervis <jl...@iona.com> wrote:
> Hi Jarek, as Willem already mentioned, the stack trace showed that you still got HTTPTransportFactory instead of GeronimoDestinationFactory. At the moment, there are two ways to associate DestinationFactory with namespaces. One way to do this is providing a CXF extension file, for example, the cxf\trunk\rt\transports\http\src\main\resources\META-INF\cxf\cxf-extension-http.xml, in your case, you can provide a cxf-extension-geronimo.xml. When CXF bus starts up, it loads all extension files, "IF" your cxf-extension-geronimo.xml is loaded after cxf-extension-http.xml, then all relevant namespaces will be associated with GeronimoDestinationFactory. As GeronimoDestinationFactory and HTTPTransportFactory are associated with same name spaces, this approach wont work as there is no guarantee which one is getting loaded first. The second approach is explicitly replacing namespace registry, CXFServlet.replaceDestionFactory() shows how to do this. The trick is that you have to make sure you do this after bus has started up, but before DestinationFactory .getDestination() is getting called. If you can not use the second approach, we probably needs to come out with sth new.
>
> Cheers,
> Jervis
>
> > -----Original Message-----
> > From: Willem Jiang [mailto:ning.jiang@iona.com]
> > Sent: 2007?4?3? 11:55
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Jetty dependency
> >
> >
> > Hi Jarek,
> >
> > It looks like the HTTPTransportFactory has been registered to the bus
> > and your GeronimoDestinationFactory did not replace it.
> > CXF Bus will try to load the all cxf-extention-*.xml by default.
> > You may exclude the cxf-extention-http.xml from the jar or
> > just do like
> > the CXFServlet to register all the http transport related
> > namespace again.
> >
> > I just noticed Dan committed a patch for this, but I think
> > you need to
> > make sure GeronimoDestinationFactory be registered to the bus
> > before the
> > HTTPTransportFactory.
> >
> > Cheers,
> >
> > Willem.
> >
> > Jarek Gawor wrote:
> > > Hi Dan,
> > >
> > > Any news on this issue?
> > >
> > > Thanks,
> > > Jarek
> > >
> > > On 4/1/07, Jarek Gawor <jg...@gmail.com> wrote:
> > >> No, I'm not using CXFServlet. Ok, thanks.
> > >>
> > >> Our GeronimoDestinationFactory extends
> > HTTPTransportFactory and we do
> > >> overwrite the getDestination() method so maybe something
> > doesn't get
> > >> registered properly as before.
> > >>
> > >> Jarek
> > >>
> > >> On 4/1/07, Dan Diephouse <da...@envoisolutions.com> wrote:
> > >> > Are you using the CXFServlet? If so, then CXF should use the
> > >> > ServletTransportFactory as it's transport (and not
> > require jetty).
> > >> > Otherwise, it should use Jetty as it's transport.
> > >> >
> > >> > Maybe I messed things up with my latest changes to CXFServlet
> > >> though. I will
> > >> > have to take a deeper look tomorrow when I'm more awake.
> > I'll get
> > >> back to
> > >> > you soon.
> > >> >
> > >> > Thanks,
> > >> > Dan
> > >> >
> > >> > On 3/31/07, Jarek Gawor <jg...@gmail.com> wrote:
> > >> > >
> > >> > > Using the latest snapshot I see the following error:
> > >> > >
> > >> > > java.lang.NoClassDefFoundError: org/mortbay/jetty/Connector
> > >> > > at
> > >> > >
> > org.apache.cxf.transport.http.JettyHTTPDestination.retrieveEngine(
> > >> > > JettyHTTPDestination.java:87)
> > >> > > at
> > >> > >
> > org.apache.cxf.transport.http.HTTPTransportFactory.getDestination(
> > >> > > HTTPTransportFactory.java:123)
> > >> > > at
> > >> org.apache.cxf.binding.soap.SoapTransportFactory.getDestination
> > >> > > (SoapTransportFactory.java:74)
> > >> > > at
> > >> org.apache.cxf.endpoint.ServerImpl.<init>(ServerImpl.java:77)
> > >> > > at org.apache.cxf.frontend.ServerFactoryBean.create(
> > >> > > ServerFactoryBean.java:86)
> > >> > >
> > >> > > Is this dependency required? I thought it was removed.
> > >> > >
> > >> > > Thanks,
> > >> > > Jarek
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Dan Diephouse
> > >> > Envoi Solutions
> > >> > http://envoisolutions.com | http://netzooid.com/blog
> > >> >
> > >>
> > >
> >
> >
>
RE: Jetty dependency
Posted by "Liu, Jervis" <jl...@iona.com>.
Hi Jarek, as Willem already mentioned, the stack trace showed that you still got HTTPTransportFactory instead of GeronimoDestinationFactory. At the moment, there are two ways to associate DestinationFactory with namespaces. One way to do this is providing a CXF extension file, for example, the cxf\trunk\rt\transports\http\src\main\resources\META-INF\cxf\cxf-extension-http.xml, in your case, you can provide a cxf-extension-geronimo.xml. When CXF bus starts up, it loads all extension files, "IF" your cxf-extension-geronimo.xml is loaded after cxf-extension-http.xml, then all relevant namespaces will be associated with GeronimoDestinationFactory. As GeronimoDestinationFactory and HTTPTransportFactory are associated with same name spaces, this approach wont work as there is no guarantee which one is getting loaded first. The second approach is explicitly replacing namespace registry, CXFServlet.replaceDestionFactory() shows how to do this. The trick is that you have to make sure you do this after bus has started up, but before DestinationFactory .getDestination() is getting called. If you can not use the second approach, we probably needs to come out with sth new.
Cheers,
Jervis
> -----Original Message-----
> From: Willem Jiang [mailto:ning.jiang@iona.com]
> Sent: 2007?4?3? 11:55
> To: cxf-dev@incubator.apache.org
> Subject: Re: Jetty dependency
>
>
> Hi Jarek,
>
> It looks like the HTTPTransportFactory has been registered to the bus
> and your GeronimoDestinationFactory did not replace it.
> CXF Bus will try to load the all cxf-extention-*.xml by default.
> You may exclude the cxf-extention-http.xml from the jar or
> just do like
> the CXFServlet to register all the http transport related
> namespace again.
>
> I just noticed Dan committed a patch for this, but I think
> you need to
> make sure GeronimoDestinationFactory be registered to the bus
> before the
> HTTPTransportFactory.
>
> Cheers,
>
> Willem.
>
> Jarek Gawor wrote:
> > Hi Dan,
> >
> > Any news on this issue?
> >
> > Thanks,
> > Jarek
> >
> > On 4/1/07, Jarek Gawor <jg...@gmail.com> wrote:
> >> No, I'm not using CXFServlet. Ok, thanks.
> >>
> >> Our GeronimoDestinationFactory extends
> HTTPTransportFactory and we do
> >> overwrite the getDestination() method so maybe something
> doesn't get
> >> registered properly as before.
> >>
> >> Jarek
> >>
> >> On 4/1/07, Dan Diephouse <da...@envoisolutions.com> wrote:
> >> > Are you using the CXFServlet? If so, then CXF should use the
> >> > ServletTransportFactory as it's transport (and not
> require jetty).
> >> > Otherwise, it should use Jetty as it's transport.
> >> >
> >> > Maybe I messed things up with my latest changes to CXFServlet
> >> though. I will
> >> > have to take a deeper look tomorrow when I'm more awake.
> I'll get
> >> back to
> >> > you soon.
> >> >
> >> > Thanks,
> >> > Dan
> >> >
> >> > On 3/31/07, Jarek Gawor <jg...@gmail.com> wrote:
> >> > >
> >> > > Using the latest snapshot I see the following error:
> >> > >
> >> > > java.lang.NoClassDefFoundError: org/mortbay/jetty/Connector
> >> > > at
> >> > >
> org.apache.cxf.transport.http.JettyHTTPDestination.retrieveEngine(
> >> > > JettyHTTPDestination.java:87)
> >> > > at
> >> > >
> org.apache.cxf.transport.http.HTTPTransportFactory.getDestination(
> >> > > HTTPTransportFactory.java:123)
> >> > > at
> >> org.apache.cxf.binding.soap.SoapTransportFactory.getDestination
> >> > > (SoapTransportFactory.java:74)
> >> > > at
> >> org.apache.cxf.endpoint.ServerImpl.<init>(ServerImpl.java:77)
> >> > > at org.apache.cxf.frontend.ServerFactoryBean.create(
> >> > > ServerFactoryBean.java:86)
> >> > >
> >> > > Is this dependency required? I thought it was removed.
> >> > >
> >> > > Thanks,
> >> > > Jarek
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Dan Diephouse
> >> > Envoi Solutions
> >> > http://envoisolutions.com | http://netzooid.com/blog
> >> >
> >>
> >
>
>
Re: Jetty dependency
Posted by Willem Jiang <ni...@iona.com>.
Hi Jarek,
It looks like the HTTPTransportFactory has been registered to the bus
and your GeronimoDestinationFactory did not replace it.
CXF Bus will try to load the all cxf-extention-*.xml by default.
You may exclude the cxf-extention-http.xml from the jar or just do like
the CXFServlet to register all the http transport related namespace again.
I just noticed Dan committed a patch for this, but I think you need to
make sure GeronimoDestinationFactory be registered to the bus before the
HTTPTransportFactory.
Cheers,
Willem.
Jarek Gawor wrote:
> Hi Dan,
>
> Any news on this issue?
>
> Thanks,
> Jarek
>
> On 4/1/07, Jarek Gawor <jg...@gmail.com> wrote:
>> No, I'm not using CXFServlet. Ok, thanks.
>>
>> Our GeronimoDestinationFactory extends HTTPTransportFactory and we do
>> overwrite the getDestination() method so maybe something doesn't get
>> registered properly as before.
>>
>> Jarek
>>
>> On 4/1/07, Dan Diephouse <da...@envoisolutions.com> wrote:
>> > Are you using the CXFServlet? If so, then CXF should use the
>> > ServletTransportFactory as it's transport (and not require jetty).
>> > Otherwise, it should use Jetty as it's transport.
>> >
>> > Maybe I messed things up with my latest changes to CXFServlet
>> though. I will
>> > have to take a deeper look tomorrow when I'm more awake. I'll get
>> back to
>> > you soon.
>> >
>> > Thanks,
>> > Dan
>> >
>> > On 3/31/07, Jarek Gawor <jg...@gmail.com> wrote:
>> > >
>> > > Using the latest snapshot I see the following error:
>> > >
>> > > java.lang.NoClassDefFoundError: org/mortbay/jetty/Connector
>> > > at
>> > > org.apache.cxf.transport.http.JettyHTTPDestination.retrieveEngine(
>> > > JettyHTTPDestination.java:87)
>> > > at
>> > > org.apache.cxf.transport.http.HTTPTransportFactory.getDestination(
>> > > HTTPTransportFactory.java:123)
>> > > at
>> org.apache.cxf.binding.soap.SoapTransportFactory.getDestination
>> > > (SoapTransportFactory.java:74)
>> > > at
>> org.apache.cxf.endpoint.ServerImpl.<init>(ServerImpl.java:77)
>> > > at org.apache.cxf.frontend.ServerFactoryBean.create(
>> > > ServerFactoryBean.java:86)
>> > >
>> > > Is this dependency required? I thought it was removed.
>> > >
>> > > Thanks,
>> > > Jarek
>> > >
>> >
>> >
>> >
>> > --
>> > Dan Diephouse
>> > Envoi Solutions
>> > http://envoisolutions.com | http://netzooid.com/blog
>> >
>>
>
Re: Jetty dependency
Posted by Jarek Gawor <jg...@gmail.com>.
Hi Dan,
Any news on this issue?
Thanks,
Jarek
On 4/1/07, Jarek Gawor <jg...@gmail.com> wrote:
> No, I'm not using CXFServlet. Ok, thanks.
>
> Our GeronimoDestinationFactory extends HTTPTransportFactory and we do
> overwrite the getDestination() method so maybe something doesn't get
> registered properly as before.
>
> Jarek
>
> On 4/1/07, Dan Diephouse <da...@envoisolutions.com> wrote:
> > Are you using the CXFServlet? If so, then CXF should use the
> > ServletTransportFactory as it's transport (and not require jetty).
> > Otherwise, it should use Jetty as it's transport.
> >
> > Maybe I messed things up with my latest changes to CXFServlet though. I will
> > have to take a deeper look tomorrow when I'm more awake. I'll get back to
> > you soon.
> >
> > Thanks,
> > Dan
> >
> > On 3/31/07, Jarek Gawor <jg...@gmail.com> wrote:
> > >
> > > Using the latest snapshot I see the following error:
> > >
> > > java.lang.NoClassDefFoundError: org/mortbay/jetty/Connector
> > > at
> > > org.apache.cxf.transport.http.JettyHTTPDestination.retrieveEngine(
> > > JettyHTTPDestination.java:87)
> > > at
> > > org.apache.cxf.transport.http.HTTPTransportFactory.getDestination(
> > > HTTPTransportFactory.java:123)
> > > at org.apache.cxf.binding.soap.SoapTransportFactory.getDestination
> > > (SoapTransportFactory.java:74)
> > > at org.apache.cxf.endpoint.ServerImpl.<init>(ServerImpl.java:77)
> > > at org.apache.cxf.frontend.ServerFactoryBean.create(
> > > ServerFactoryBean.java:86)
> > >
> > > Is this dependency required? I thought it was removed.
> > >
> > > Thanks,
> > > Jarek
> > >
> >
> >
> >
> > --
> > Dan Diephouse
> > Envoi Solutions
> > http://envoisolutions.com | http://netzooid.com/blog
> >
>
Re: Jetty dependency
Posted by Jarek Gawor <jg...@gmail.com>.
No, I'm not using CXFServlet. Ok, thanks.
Our GeronimoDestinationFactory extends HTTPTransportFactory and we do
overwrite the getDestination() method so maybe something doesn't get
registered properly as before.
Jarek
On 4/1/07, Dan Diephouse <da...@envoisolutions.com> wrote:
> Are you using the CXFServlet? If so, then CXF should use the
> ServletTransportFactory as it's transport (and not require jetty).
> Otherwise, it should use Jetty as it's transport.
>
> Maybe I messed things up with my latest changes to CXFServlet though. I will
> have to take a deeper look tomorrow when I'm more awake. I'll get back to
> you soon.
>
> Thanks,
> Dan
>
> On 3/31/07, Jarek Gawor <jg...@gmail.com> wrote:
> >
> > Using the latest snapshot I see the following error:
> >
> > java.lang.NoClassDefFoundError: org/mortbay/jetty/Connector
> > at
> > org.apache.cxf.transport.http.JettyHTTPDestination.retrieveEngine(
> > JettyHTTPDestination.java:87)
> > at
> > org.apache.cxf.transport.http.HTTPTransportFactory.getDestination(
> > HTTPTransportFactory.java:123)
> > at org.apache.cxf.binding.soap.SoapTransportFactory.getDestination
> > (SoapTransportFactory.java:74)
> > at org.apache.cxf.endpoint.ServerImpl.<init>(ServerImpl.java:77)
> > at org.apache.cxf.frontend.ServerFactoryBean.create(
> > ServerFactoryBean.java:86)
> >
> > Is this dependency required? I thought it was removed.
> >
> > Thanks,
> > Jarek
> >
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
Re: Jetty dependency
Posted by Dan Diephouse <da...@envoisolutions.com>.
Are you using the CXFServlet? If so, then CXF should use the
ServletTransportFactory as it's transport (and not require jetty).
Otherwise, it should use Jetty as it's transport.
Maybe I messed things up with my latest changes to CXFServlet though. I will
have to take a deeper look tomorrow when I'm more awake. I'll get back to
you soon.
Thanks,
Dan
On 3/31/07, Jarek Gawor <jg...@gmail.com> wrote:
>
> Using the latest snapshot I see the following error:
>
> java.lang.NoClassDefFoundError: org/mortbay/jetty/Connector
> at
> org.apache.cxf.transport.http.JettyHTTPDestination.retrieveEngine(
> JettyHTTPDestination.java:87)
> at
> org.apache.cxf.transport.http.HTTPTransportFactory.getDestination(
> HTTPTransportFactory.java:123)
> at org.apache.cxf.binding.soap.SoapTransportFactory.getDestination
> (SoapTransportFactory.java:74)
> at org.apache.cxf.endpoint.ServerImpl.<init>(ServerImpl.java:77)
> at org.apache.cxf.frontend.ServerFactoryBean.create(
> ServerFactoryBean.java:86)
>
> Is this dependency required? I thought it was removed.
>
> Thanks,
> Jarek
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog