I think there have been calls for option #2 for other reasons besides
disabling the X509 checks. So #2 provides additional benefits--it's
probably something we should be supporting anyway. I also like option #2
politically (we're not explicitly allowing disabling of the X509 checks,
it's just we
Hello,
For the educational side, I feel we could help users enhancing the
exception messages. For example, a "SunCertPathBuilderException:
unable to find valid certification path to requested target" for a
self signed certificate could be more explanatory.
=> I would be very happy to make proposit
I guess you can add additional info to the error message if you like, but the
advantage of keeping as much of the regular text as possible is that it
helps nicely with Googling. I'm reminded of something (I believe) Christian
Scheider had said, that he does *not* like error messages to be transla
Regarding exception messages, my mistake if my explanation was not
clear enough. I share Christian's interest in root cause exception
message in english to search google.
My idea is to sometimes wrap root exceptions in exceptions that hold
contextual messages ; I already proposed some enhancements
Dear all,
After talks on the mailing list regarding ways to ease usage of
HTTPS in CXF client I created "[CXF-2693] Allow to use
HttpsURLConnection's defaultSSLSocketFactory and
defaultHostnameVerifier in CXF client".
If people are happy with this new feature, I would be very happy to
co
I started a new thread on the mailing list to propose an
implementation of option #2 : "[CXF-2693] Allow to use
HttpsURLConnection's defaultSSLSocketFactory and
defaultHostnameVerifier in CXF client"
Could you give me a feedback on this implementation ? Is it the kind
of thing you thought about or
