Hi Dan,
I'm always happy to be helpful for discovering bug !
Well maybe there is another bug concerning cxf-codegen-plugin/wsdl2java
maven plugin, adding "-exsh true" option to the plugin leads to a
NullPointerException when generating code.
(note that without "-exsh true" there is no NPE).
Here's the plugin configuration section in my pom.xml :
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>${cxf.version}</version>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<configuration>
<sourceRoot>${project.build.directory}/generated-sources/</sourceRoot>
<wsdlOptions>
<wsdlOption>
<wsdl>${basedir}/src/main/resources/structureservices.wsdl</wsdl>
<extraargs>
<extraarg>-client</extraarg>
<extraarg>-exsh</extraarg>
<extraarg>true</extraarg>
</extraargs>
</wsdlOption>
</wsdlOptions>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
</plugin>
I will try calling directly ant tasks from maven instead of using
cxf-codegen plugin to see if the problem is in the maven plugin or in
wsdl2java code.
I'll keep you informed of my investigation.
Regards,
Joel
dkulp wrote:
>
>
> Joel,
>
> Thanks for sending the WSDL. I can confirm this is a CXF problem.
> It's related to the out of band header. The HolderOutInterceptor is
> expecting the out of band header to have a part in the parameter list if
> it's an in/out header, but by default, it wasn't generated. It's a bug
> in the HolderOutInterceptor.
>
> Good news: I have a possible workaround. When you run wsdl2java to
> generate the code, if you add "-exsh true" to the flags, it will change
> the method signature to have the header as a third parameter.
>
> Dan
>
> On Monday 12 November 2007, JoCosti wrote:
>> Thanks Glenn for the quick and developed answer, I do appreciate a lot
>> since I'm a newbie concerning web services and particularly jax-ws.
>>
>> Concerning your remarks :
>>
>> 1) I think it's doc/literal, here's a part of binding section
>>
>> <wsdl:binding name="StructureServicesSoap"
>> type="tns:StructureServicesSoap">
>> <soap:binding transport="http://schemas.xmlsoap.org/soap/http";
>> style="document" />
>> <wsdl:operation name="GetMailAddress">
>> <soap:operation
>> soapAction="http://anpe.fr/DirectoryServices/GetMailAddress";
>> style="document" />
>> <wsdl:input>
>> <soap:body use="literal" />
>> <soap:header
>> message="tns:GetMailAddressStructureMailAddressHeader"
>> part="StructureMailAddressHeader"
>> use="literal" />
>> </wsdl:input>
>> <wsdl:output>
>> <soap:body use="literal" />
>> <soap:header
>> message="tns:GetMailAddressStructureMailAddressHeader"
>> part="StructureMailAddressHeader"
>> use="literal" />
>> </wsdl:output>
>> </wsdl:operation>
>>
>> Can you confirm that it should be possible to consume this web service
>> with a jax-ws client ?
>> I have uploaded the complete wsdl (hope you can have a look at it,
>> it's the first time I'm using the upload facility in this mailing
>> list).
>>
>> For 2) I need to have a look at your work, I'm using maven2 to
>> generate my web service client, I hope I can use your approach with
>> maven.
>>
>> Finally, here's a the code I have written to call the web service :
>>
>> the JUnit test part
>>
>> public void testGetMailAddress() throws TechniqueException {
>> String mailStructure =
>> getStructureServices().getMailAddress(APPLICATION_NOM, "92053");
>> assertEquals("[EMAIL PROTECTED]", mailStructure);
>> }
>>
>> Where getStructureServices() calls the following code (I've just put
>> the interesting part for clarity sake)
>>
>> // I need to access StructureServices in HTTPS, note sure if it's the
>> right way but that's what I've found with googling ...
>> Authenticator.setDefault(new AnpeAuthenticator());
>> // instanciate the web service client generated by codegen maven
>> plugin fr.anpe.directoryservices.StructureServices structureServices =
>> new fr.anpe.directoryservices.StructureServices();
>> // get web service port called StructureServicesSoap
>> structureServicesWebServiceConsumer =
>> structureServices.getStructureServicesSoap();
>>
>> One last thing, in my wsdl, I have the same name
>> (StructureServicesSoap) for a port and a binding, is that correct ?
>>
>> binding section :
>> <wsdl:binding name="StructureServicesSoap"
>> type="tns:StructureServicesSoap">
>> <soap:binding transport="http://schemas.xmlsoap.org/soap/http";
>> style="document" />
>> <wsdl:operation name="GetInformation">
>> <soap:operation
>> soapAction="http://anpe.fr/DirectoryServices/GetInformation";
>> style="document" />
>>
>> port section :
>> <wsdl:service name="StructureServices">
>> <wsdl:port name="StructureServicesSoap"
>> binding="tns:StructureServicesSoap">
>> <soap:address
>> location="https://annuairews-int.tempo.anpe.fr/directoryservices/struc
>>tureservices.asmx" />
>> </type filter textwsdl:port>
>>
>> Regards,
>>
>> Joel
>>
>> Glen Mazza-2 wrote:
>> > More detective work is needed here:
>> >
>> > 1.) Are you using an rpc/encoded web service, instead of doc/lit or
>> > rpc/lit (Can you show us a part of the wsdl:binding section, that's
>> > where you can determine that)--if so, that is not supported by
>> > jax-ws. For rpc/encoded, you'll need to use the Dispatch object or
>> > SAAJ instead.
>> >
>> > An RPC/encoded sample using Dispatch object is here:
>> > http://www.jroller.com/gmazza/date/20071102
>> >
>> > 2.) You may wish to use both Metro and CXF when working with SOAP
>> > clients, because, depending on whether or not it fails on both
>> > stacks, that helps pinpoint if the problem is (1) with the web
>> > service stack or (2) your own code. If (2), frequently different
>> > error messages are given by the two stacks, which can help greatly
>> > in troubleshooting the problem with the client code.
>> >
>> > The "run-client" target of step 5 here[1] shows how this can be
>> > done. All that is needed is to switch the <path refid.../> between
>> > "cxf.classpath" and "metro.classpath" to activate the different web
>> > service stack. Recompiling is not necessary, because JAX-WS
>> > artifacts are interoperable between web service stacks.
>> >
>> > [1] http://www.jroller.com/gmazza/date/20070817
>> >
>> > HTH,
>> > Glen
>> >
>> > Am Montag, den 12.11.2007, 04:44 -0800 schrieb JoCosti:
>> >> Hi there,
>> >>
>> >> I'm using 2.0.2 version to generate the client side of an existing
>> >> web service.
>> >> I have already managed to write a client with another framework
>> >> using jax-rpc technology, I nowwant to migrate to jax-ws with CXF
>> >> framework
>> >>
>> >> When running the client web service, I'm facing the following
>> >> exception :
>>
>> http://www.nabble.com/file/p13706890/structureservices.wsdl
>> structureservices.wsdl
>
>
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> [EMAIL PROTECTED]
> http://www.dankulp.com/blog
>
>
--
View this message in context:
http://www.nabble.com/classCastExcception-in-web-service-client-generated-with-CXF-tf4790840.html#a13722300
Sent from the cxf-user mailing list archive at Nabble.com.
