> -----Original Message----- > From: Liu, Jervis [mailto:[EMAIL PROTECTED] > Sent: 2007?4?4? 0:40 > To: [email protected] > Subject: RE: Jetty dependency > > > > > > -----Original Message----- > > From: Daniel Kulp [mailto:[EMAIL PROTECTED] > > Sent: 2007?4?3? 22:58 > > To: [email protected] > > 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > > > > Sent: 2007?4?3? 11:55 > > > > > To: [email protected] > > > > > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > [EMAIL PROTECTED] > > http://www.dankulp.com/blog > > >
