> -----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... > > 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 >
