>
>
> harryvanrijn wrote:
>>
>> To my opinion the cxf.xml file is not read, all be it in the classpath
>> (beneath .../WEB-INF/classes).
>> So the problem remains that I have a SOAP Client (standalone or in a
>> servlet, whatever) that refuses to
>> communicate over HTTPS. After all I do not understand why the cxf.xml is
>> not read.
>>
>
> You might want to confirm if that is a problem, by doing some dependency
> injection from your cxf.xml to your SOAP client, e.g., passing in a string
> ("Hello World!") from the cxf.xml to your client code, and having the latter
> output or log that value.  Does it get that message?
>
> BTW, here's an alternative to client creation that might fix your
> problem--look at here:
> http://www.jroller.com/gmazza/date/20080729, Step #5, Substeps #1 and #3 --
> Using JaxWsProxyFactoryBean may be just what you need.
>
Hi Glen,

I tried indeed to setup the communication with the JaxWsProxyFactoryBean, that 
worked!
I already had some suspect as you state below that 'local' and 'remote' 
Settings concerning
the HTTP(S) protocol conflict with each other.
So the JaxWsProxyFactoryBean approach gave me the impression that everything 
was handled
locally, that is, the endpoint with https was used.
But thank you very much for the explanations.

bye

Harry

>
> harryvanrijn wrote:
>>
>> The other point(#5), 'using https://', is something that I cannot change,
>> because the WSDL is read from
>> the remote server anytime when I create myWebService.
>>
>
> That's a shame, because I'm nearly certain that is the heart of your
> problem--CXF clients read a local (on-machine) version of the WSDL first,
> and from that WSDL's wsdl:service's soap:address, use that URL.  If that
> local wsdl's address is http:// instead of https://, you will get that
> error.  While CXF clients will indeed reload the WSDL from the remote server
> as you're saying above, the first step--that of determining the address of
> the remote server to begin with--comes from that local WSDL.  Where is that
> local WSDL?  It is normally hardcoded in the JAX-WS generated *Service.java
> class--I would start hunting for it there, and when you find that WSDL,
> changing its address to https://.
In the wsdl was no valid URL, just a placeholder: 
http://replace_with_actual_url.
I didn't pay attention to this..., but now I understand the URL resolving 
mechanism.
Again, thanks a lot for this information.
>
> Glen
>
> --
> View this message in context:
> http://www.nabble.com/java.io.IOException%3A-Illegal-Protocol-http-for-HTTPS-URLConnection--Factory-tp19412659p19435643.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>

Reply via email to