I haven't debugged OSGi within Eclipse yet (hmm, new blog entry
opportunity... :), but I have with Tomcat and it's easier than one
might assume:
http://www.jroller.com/gmazza/entry/eclipse_debug_web_services. You
might wish to debug your OSGi container within Eclipse (perhaps a bit
more of a headache to learn but certainly a useful skill that will help
in future troubleshooting) so you can find out "why cxf is not using the
trust store that I set up in the <http:conduit> configuration" and
figure out which side of the "or" in "either ignores the <http:conduit>
configuration or it ignores the specified trust store" is the case,
helping point you to a resolution.
Glen
On 03/20/2013 03:41 PM, geecxf wrote:
Just to re-iterate. The nature of the error is clear to me (not my first
rodeo with SSL/TLS :) What's not clear is why cxf is not using the trust
store that I set up in the <http:conduit> configuration. It works just fine
when I inject the bus as a string property but not when using
getDefaultBus() or getThreadDefaultBus(). It seems like when I use
getDefaultBus() or getThreadDefaultBus it either ignores the <http:conduit>
configuration or it ignores the specified trust store.
I'll have a look at the links you suggested to see if there is any
information that could help.
Thanks,
D
--
View this message in context:
http://cxf.547215.n5.nabble.com/Code-only-STSClient-tp5724575p5724901.html
Sent from the cxf-user mailing list archive at Nabble.com.
