cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: Fwd: Problems with non-Java clients
Date Mon, 06 Oct 2008 19:18:18 GMT
One thing I found is the following import:
I do not really understand what this does.

The other thing is the import of the WSDL containing the porttype. When 
using .Net make sure you use the command line generator and give it both 
wsdl files on the command line.
I have made the experience that the command line code generator does not 
always work when you simply give it the main wsdl. In general I would be 
carefull with imports. One thing you could try is integrating the wsdl 
in one file without imports.

Generally I do not like generating WSDLs myself. It is just too easy to 
make slight errors that cause problems on some platforms. I have written 
an article on the CXF wiki how to define your service in Java and then 
let CXF generate the wsdl. Then you can use this WSDL in both your 
clients and your server.
The WSDLs generated this way should work with .Net.


Alexandre Costa schrieb:
> Christian,
> Though our WSDL is not "made by hand", it could lacks some needed 
> definition.
> Follow the file, hoping any one could lend us hints (the time is 
> getting short critically to us)
> Thanks for the attention.
> -- 
> Alexandre Augusto Leite Costa
> Desenvolvimento
> Dextra Sistemas
> <>
> +55 19 3256-6722 / 9208-7944
> On Mon, Oct 6, 2008 at 3:33 PM, Christian Schneider 
> < <>> wrote:
>     Are you allowed to post the WSDL? Perhaps we can help then.
>     Did you create the WSDL by hand?
>     Greetings
>     Christian
>     Alexandre A. L. Costa schrieb:
>         Thanks for the tip.
>         There aren't much "abornal" details for this service. No
>         Exceptions to be thrown or Security Policy yet.  (Though in
>         near future we'll need to use SSL conection)
>         Just send an String and receive an String for response.
>         We have been doing same tests that make us think os problems
>         with client's SOAP message formation too.
>         The SOAP message sent by the Delphi client is kind wierd.
>         We already tried some "generic" client services on web (and
>         they function quite well).
>         Now we're focusing (as the sugestion) on proving that the
>         problem are on client side.
>         Thanks again.
>     -- 
>     Christian Schneider
>     ---


Christian Schneider

View raw message