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:

[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

but I get:

[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Jarek

On 4/3/07, Jarek Gawor <[EMAIL PROTECTED]> 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 <[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
> > >> >
> > >>
> > >
> >
> >
>

Reply via email to