I just committed a fix for this on trunk. It logs a warning for each
unavailable operation, then removes the operations from the ServiceModel
so they won't be invokable.
Dan
On Monday 29 October 2007, Daniel Kulp wrote:
There's a JIRA logged someplace about this:
There's a JIRA logged someplace about this:
http://issues.apache.org/jira/browse/CXF-940
I'd like to get it logged on client side, but fail on server side.
That's a bit more complicated since the code in question is completely
shared between the two and it really doesn't know what it's
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
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
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.
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
If you just add an operation, it will/should not failed the client,
you can modify the hello_world demo in cxf samples, and give it a try
(Before you run the client after you modify the wsdl, make sure to
remove the depends=build in the client target, so it'll not generate
the client code)
