Back !

After some struggling setting classpath, I've ran successfully wsdl2java ant
tasks within maven with -exsh option set to true, I think there may be some
problem in cxf-codegen plugin since it seems ok with ant and ko with maven.

Code generation is running fine but calling the web service is not, an
exception is thrown, here's the stack trace :

13 nov. 2007 11:47:58
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromWSDL
INFO: Creating Service {http://anpe.fr/DirectoryServices/}StructureServices
from WSDL:
file:/D:/bea_dev/SocleSapiens/StructureServices/src/main/resources/structureservices.wsdl
11:47:58,596 [main] ERROR structures.StructureServicesImpl  - Erreur lors de
l'initialisation du client web service StructureServices 
javax.xml.ws.WebServiceException:
org.apache.cxf.service.factory.ServiceConstructionException
        at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:263)
        at javax.xml.ws.Service.getPort(Service.java:94)
        at
fr.anpe.directoryservices.StructureServices.getStructureServicesHttpGet(StructureServices.java:77)
        at
fr.anpe.sapiens.services.structures.StructureServicesImpl.getStructureServicesWebServiceProxy(StructureServicesImpl.java:190)
        at
fr.anpe.sapiens.services.structures.StructureServicesImpl.getMailAddress(StructureServicesImpl.java:85)
        at
fr.anpe.sapiens.services.structures.StructureServicesTest.testGetMailAddress(StructureServicesTest.java:51)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at junit.framework.TestCase.runTest(TestCase.java:154)
        at junit.framework.TestCase.runBare(TestCase.java:127)
        at junit.framework.TestResult$1.protect(TestResult.java:106)
        at junit.framework.TestResult.runProtected(TestResult.java:124)
        at junit.framework.TestResult.run(TestResult.java:109)
        at junit.framework.TestCase.run(TestCase.java:118)
        at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
        at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
        at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
        at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
        at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
        at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: org.apache.cxf.service.factory.ServiceConstructionException
        at
org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:57)
        at
org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:89)
        at org.apache.cxf.jaxws.ServiceImpl.createPort(ServiceImpl.java:356)
        at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:261)
        ... 21 more
Caused by: org.apache.cxf.BusException: No binding factory for namespace
http://schemas.xmlsoap.org/wsdl/http/ registered.
        at
org.apache.cxf.binding.BindingFactoryManagerImpl.getBindingFactory(BindingFactoryManagerImpl.java:78)
        at
org.apache.cxf.frontend.AbstractEndpointFactory.createEndpoint(AbstractEndpointFactory.java:100)
        at
org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:50)
        ... 24 more

I have encountered this problem once, Dan suggested me to try 2.0.2 or
2.0.3-SNAPSHOT version, I have tried both with the same exception ! (the
stack trace shown above was gotten with 2.0.3-SNAPSHOT version)

I must add that the web service I'm calling is a secure one as I'm not sure
about how to configure CXF to call a secure web service, it may be the cause
of my problem(s)

Regards,

Joel


JoCosti wrote:
> 
> 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#a13723765
Sent from the cxf-user mailing list archive at Nabble.com.

Reply via email to