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 <[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-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:[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
> >> >
> >>
> >
>
>
