It's almost been a month now and I'm starting to feel like I'm in development Hell. For some of you on this forum you will already be familiar with the problem since I posted it on the FuseSource forums. Back then I didn't fully understand the problem, but after talking with Willem for a while and doing a lot of testing and research I finally understand what is going on, so I feel like I should repost this question here and starting from square one again because I still haven't resolved the problem because there is one last piece of the puzzle I don't fully understand.
*Situation* Basically I was given a thirdparty non-osgi jar that I was told to use to connect to a target server. We use FuseESB so we wanted to integrate it into our ServiceMix. The thirdparty jar uses a cxf.xml file to create an http-conduit with the *.http-conduit wildcard to make a two way SSL connection. We've tested the thirdparty jar with just Eclipse alone and we know it works since we're able to establish a connection to the server with SSL. We do not have access to the source code and this thirdparty jar. All we can do is muck around with the CXF file. *The Problem* The problem we have is that when we try and use this thirdparty jar in our ServiceMix it throws a handshake_failure exception when trying to first connect to the server. *The theorized cause* Looking at the SSL logs and CXF logs we found that connection was plain old http and not https. Our guess was that the http-conduit was being ignored some how. We searched all our bundles in ServiceMix and found another completely unrelated bundle that was using CXF. We commented out the /<import resource="classpath:META-INF/cxf/cxf.xml" />/ in the spring file of the other bundle. After doing that the thirdparty bundle started to work in ServiceMix. The fact that this caused it to work confused me and my teammates A LOT. We thought that two unrelated bundles in servicemix would not affect each other. I asked http://fusesource.com/forums/thread.jspa?threadID=3690&tstart=0 a lot of questions on the FuseESB forums and Willem explained a few things, the most important being that the CXF bus is by default shared by ALL bundles. This was confirmed when I found http://tmielke.blogspot.com/2010/12/configure-client-side-cxf-bus-in-osgi.html Mielke's blog post and this in the http://cxf.apache.org/javadoc/latest/org/apache/cxf/BusFactory.html CXF API . So we think the CXF bus from the thirdparty jar was being overwritten by the CXF bus of the other bundle through spring loading as Willem thought... but I don't fully understand how that would cause the http-conduit to be ignored? How is the http-conduit being overwritten? Is the http-conduit some how part of the bus? I did find this http://cxf.547215.n5.nabble.com/HttpConduit-thread-safety-td562073.html#a562076 post answered by Daniel Kulp that mentioned there is one http-conduit for everyone and that to get around it we need to use the code he mentioned... unfortunately we can't access the source code of the jar so we can't really make this change... Is there anyway, given the restrictions placed on us, to successfully integrate this thirdparty jar with it's cxf.xml file into ServiceMix or do we have no choice but to tell the developers of the thirdparty jar to change their code? There is a very high chance they will tell us no. I have thought of two other solutions: 1. I was thinking about turning their thirdparty jar into an OSGI service, but I don't think that will solve the problem because it's still the same JVM, so the CXF bus is still shared even if it's a service, right? 2. Give up integrating the thirdparty jar into the FuseESB ServiceMix and just run it outside our system. -- View this message in context: http://cxf.547215.n5.nabble.com/Multiple-CXF-instances-ServiceMix-Thirdparty-Jar-help-tp5482963p5482963.html Sent from the cxf-user mailing list archive at Nabble.com.
