cxf http-conduit SSL handshake_failure

[marc.blomquist]

The problem is pretty simple. I'm getting a handshake_failure exception as a client trying to connect to a server with a two way ssl. I've turned on logging to the max and what I can see in the SSL logging is that I'm not sending my cert to the server. When looking at the http-conduit log messages I see the following log message,

Conduit 'blahblahblah' has been configured for plain http

Looking at the source code for http-conduit for this log message tells me that this can only happen if the tlsClientParameters was null. I'm loading the http-conduit in a beans.xml file. I know the file is picked up and parsed because in the logging I see it being picked up and also if I make a mistake in it then servicemix complains with an exception. So the file IS being picked up... but I am not sure why the http-conduit config I have in it is NOT having any effect. I've attached the config file,

I'll take any help I can get : (

I've been at this problem for a week now! there is no error message in the logs other than the one mentioned. I've looked at many examples on the web, but none of the suggested fixes seem to work.[This guy for example has almost the exact same problem|http://cxf.547215.n5.nabble.com/CXF-client-SSL-pain-td547359.html] and I followed what he did but no luck.

Problem has been solved, but I've seen a lot of people with similar headaches with different solutions so I'm linking all the links I've gathered while I tried to solve this problem. Hopefully it will help others. Note that you'll have to check out all links to get a good idea of how everything works because each link only shows a small part of the bigger picture in getting cxf to work in ServiceMix:

-  POM example of dependencies for cxf

- Jars and libraries cxf needs (detailed)

- cxf.xml configuration file

- http-conduit xml spring examples

- someone else with problems with http-conduit

- another person with http-conduit problems

Edited by: marc.blomquist on Feb 6, 2012 6:58 PM

[njiang]

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.

Willem

[marc.blomquist]

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.

[marc.blomquist]

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

[marc.blomquist]

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.

[njiang]

Hi,

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.

Willem

[ffang]

Hi,

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.

Freeman