Hi Folks, I'm not sure we'd have to go so far as to create a separate Bus for the cxf osgi transport.
Part of the problem I think is that the super-class, AbstractHTTPTransportFactory, does the overwrite of the DestinationFactory registered with the DestinationFactoryManager in its PostConstruct method. Whereas the sub-class, OsgiServletTransport, does the same thing *again* in its init-method. The result is that by the time the OsgiServletTransport.init() is called, the destination factory has *already* been over-written for the transport IDs. Now if we supress the first step by overriding AbstractHTTPTransportFactory.registerWithBindingManager() as a no-op in OsgiServletTransport, then the OsgiServletTransport.init() can remember the factory previously registered against the transport IDs. Then in OsgiServletTransport.getDestination(), we could delegate to the original transport factory when the EndpointInfo address is absolute. Cheers, Eoghan 2009/5/26 Freeman Fang <[email protected]>: > Hi Edell, > > The cxf bc will try to retrieve the default cxf bus (which already register > http transportId with osgi http service by cxf osgi transport) if we didn't > specify bus for cxf bc endpoint, so specify cxf bus for cxf bc endpoint can > get it around. > I think there should be two ways to fix it > 1) shouldn't set the bus used for cxf osgi transport as default bus, we can > name this bus with a specific name and any other bundle which want to use > this bus(means use osgi http service as http transport) can retrieve it with > the specific name > or > 2) endpoint in cxf bc should never use default cxf bus even without busCfg > attribute > I prefer to the first solution since we kinda hack the cxf bus in cxf osgi > transport so it shouldn't be the default bus. > Freeman > > Edell Nolan wrote: >> >> Hi, >> >> I have a question on the CXF Transport for OSGi. >> >> Basically if you do the following >> >> Start Servicemix >> >> *at the console run => features/install examples-cxf-osgi >> *open a web browser and check that >> >> http://localhost:8080/cxf/HelloWorld?wsdl<http://localhost:8080/cxf/HelloWorld?wsdl*>gives >> you the demo WSDL >> set *log/set TRACE >> Build the cxf-wsdl-first demo and install it using => >> **osgi/install -s >> >> mvn:org.apache.servicemix.examples.cxf-wsdl-first/wsdl-first-cxf-sa/4.1.0-SNAPSHOT/zip >> * >> point your web browser to >> >> http://localhost:8092/PersonService?wsdl<http://localhost:8092/PersonService?wsdl*>to >> verify the cxf-wsdl-first demo is running >> >> this all works fine and you should see the both wsdl files. >> >> Then restart Servicemix. >> >> You can no longer see >> >> http://localhost:8092/PersonService?wsdl<http://localhost:8092/PersonService?wsdl*>wsdl >> - from debugging this along - it now ends up in the >> OSGITransportFactory and will throw an error in the log files >> >> "17:58:41,241 | ERROR | xtenderThread-66 | CxfBcComponent >> | mmon.xbean.AbstractXBeanDeployer 103 | >> javax.jbi.management.DeploymentException: java.lang.IllegalStateException: >> Endpoint address should be a relative URI wrt to the servlet address (use >> '/xxx' for example)" >> >> if you look at >> >> https://svn.apache.org/repos/asf/servicemix/smx4/features/trunk/cxf/cxf-transport-osgi/src/main/java/org/apache/servicemix/cxf/transport/http_osgi/OsgiTransportFactory.java >> >> In getDestination it throws >> if (URI.create(endpointInfo.getAddress()).isAbsolute()) { >> throw new IllegalStateException("Endpoint address should be a >> relative URI wrt to the servlet address (use '/xxx' for example)"); >> } >> >> the sequence of starting the two demos is the same on reboot but yet we >> get >> different results. >> >> As when you first attempt to run the cxf-wsdl-first demo the CXF Transport >> for OSGi is already running and we can see out PersonService wsdl. But it >> looks like the OSGI Transport is not set as the default until after a >> refresh/reboot. >> >> Then when you reboot and attempt to launch the PersonService wsdl it ends >> up >> in the OsgiTransportFactory which is not going to work. >> >> Shouldn't other services be able to be deployed independant of the Osgi >> Transport Service and use say the SoapTransportFactory. >> >> I did ask Freeman and he mentioned one work around would be to use your >> own >> bus. >> >> thanks, Edell. >> >> > > > -- > Freeman Fang > ------------------------ > Open Source SOA: http://fusesource.com > >
