Which version of ServiceMix are you using?
What does your CXF client look like in your bundle? I didn't see any client definition in the bean.xml.
You need to find a way to let the CXF client pick up the bus which you configured in the bean.xml.
Using service mix version 4.3.1.
Unfortunately this xml comes from a thirdparty program that is just a jar and this .xml file. The jar and .xml file work perfectly outside of servicemix (i.e. as an eclipse java program).
I'm new to how CXF works, but assuming we weren't using the thirdparty program, would your question imply that to normally get this to run we would need to first get the cxf client to use the cxf bus which would in turn load the http-conduit? This sounds like a "no duh" question but I'm just checking to see if I can understand exactly how CXF works, because so far a lot of the examples I've seen online rarely mention the cxf client, let alone a cxf bus, and tend to just have an http-conduit. I also don't understand how the cxf bus in this example is picking up the http-conduit, but I have seen examples in the cxf source code where the CXF bus programmatically picks up the .xml. So I'm assuming that the xml is altering the default bus and that the http-conduit would be added to the default bus.
Having spoken with the developers of the cxf file and the jar, we've been told it's pretty much a standard cxf setup and that there is nothing in the jar that would tamper with the cxf or cause it to behave strangely. Looking at examples at cxf.apache.org the cxf file seems to be pretty standard, minus the first bean that does some searching on the java system properties.
Further testing has also shown us that everything works fine in a clean apache servicemix setup. We're now digging to see what other bundles we have installed that could be causing the http-conduit to be ignored.
Edited by: marc.blomquist on Feb 2, 2012 2:55 PM
The problem has been solved. When building our bundle with the pom we thought that it would have been a good idea to embed the thirdparty jar into our bundle (embed option in maven-bundle-plugin). For whatever reason this turned out to be a very bad idea and caused not only the http-conduit issues mentioned in the first post but also caused the bundle to throw an exception on "refresh" whenever we restarted servicemix.
The solution was to not embed the thirdparty jar and instead turn it into an osgi bundle. As soon as we did that it solved all our problems.
Can I know which third party jar was embedded?
I'm trying to figure out how it can prevent CXF loading the http-conduit configuration.
I believe they embedded cxf or other third party jars in their own bundle, which is a bad practice in OSGi world, they should always install and refer bundles in the OSGi container.