cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jarek Gawor" <jga...@gmail.com>
Subject Re: Jetty dependency
Date Tue, 03 Apr 2007 21:30:34 GMT
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 <jgawor@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 <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-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 <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
> > > >> >
> > > >>
> > > >
> > >
> > >
> >
>

Mime
View raw message