I can clarify it.
It is because I don't want to right a new WSDL to reproduce your case, I
just removed the method for the SEI which generate from the original wsdl.
?wsdl 's wsdl just equals to the older wsdl in your case, and the original
wsdl equals newer wsdl in your case.
Willem.
Christian Vest Hansen wrote:
>
> I recall seing a stack trace like that, which prompted my query.
>
> But if it, in this particular use case, always works if the client
> refer directly to the ?wsdl from the online service, then it's just
> something to keep in mind when creating clients.
>
> However, this confuses me:
>
>> I think if you still use the old wsdl to create the service , the client
>> can still work.
> (...)
>> On the client side if I use the ?wsdl which is generated by CXF to
>> create the service ,
>> the client can still work.
>
> This sounds contradictory to me, given that one of thos scenarios
> resulted in the stack trace you provided.
> Could you clarify?
>
> 2007/10/25, Willem Jiang <[EMAIL PROTECTED]>:
>> Hi Christian,
>>
>> I think if you still use the old wsdl to create the service , the client
>> can still work.
>>
>> I just did a quick test for your case by remove the WSDL2Java generated
>> SEI's method.
>> It can reproduce your case.
>> On the client side if I use the ?wsdl which is generated by CXF to
>> create the service ,
>> the client can still work. But if I specified the orginal WSDL , I got
>> the below exception.
>>
>> Caused by: org.apache.cxf.service.factory.ServiceConstructionException:
>> Could not find a matching method for operation
>> {http://apache.org/hello_world_soap_http}greetMeOneWay
>> at
>> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeWSDLOperations(ReflectionServiceFactoryBean.java:323)
>> at
>> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.initializeWSDLOperations(JaxWsServiceFactoryBean.java:184)
>> at
>> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:214)
>> at
>> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:269)
>> at
>> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:146)
>> at
>> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:91)
>> at
>> org.apache.cxf.frontend.AbstractEndpointFactory.createEndpoint(AbstractEndpointFactory.java:94)
>> at
>> org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:50)
>> at
>> org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:89)
>> at org.apache.cxf.jaxws.ServiceImpl.createPort(ServiceImpl.java:372)
>> at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:271)
>>
>> Any thoughts?
>>
>> Willem.
>>
>> Christian Vest Hansen wrote:
>> > If you generate a java client from a wsdl, and then add an operation
>> > to the wsdl but forget to update the client code - how does CXF handle
>> > that situation?
>> >
>> > Will the client crash or blissfully hum along (but withut being able
>> > to invoke the new operation)?
>> >
>> > I'm asking because it might influence decisions and policies one might
>> > define for managing change and backwards compatibility when working
>> > with CXF web services and clients.
>> >
>> >
>>
>
>
> --
> Venlig hilsen / Kind regards,
> Christian Vest Hansen.
>
>
--
View this message in context:
http://www.nabble.com/how-clients-handle-changing-wsdls-tf4684521.html#a13407403
Sent from the cxf-user mailing list archive at Nabble.com.
