cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Liu, Jervis" <j...@iona.com>
Subject RE: Jetty dependency
Date Tue, 03 Apr 2007 17:06:21 GMT


> -----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 <jliu@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 <jgawor@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 <dan@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 <jgawor@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
> > 
> 

Mime
View raw message