On Thursday, June 07, 2012 04:04:06 PM rouble wrote:
> If I have a java first we service:
>
> package com.example.v1;
>
> @WebService
> FooMethods {
> foo1();
> foo2();
> }
>
> And in version 2 of the same service, we add one method - we add one
> method - which is a backwards compatible change, but we also change the
> package and therefore namespace (as suggested in the best common
> practices of WSDL versioning):
I've never really subscribed to that theory of best practice... By changing
the namespace, it is, by definition, not compatible. But that's me. As
an example, look at all the CXF configuration schemas. We've made TONS of
changes to the schemas, but always backword compatible so we maintained the
namespace.
As Freeman said, the Transformation feature can definitely handle this.
Dan
> package com.example.v2;
>
> @WebService
> FooMethods {
> foo1();
> foo2();
> foo3();
> }
>
> Now, clients that were written against the version 1 of the service will
> fail against the new web service - even for methods that existed in
> version 1 of the web service (foo1 and foo2). This is because the older
> clients come in looking for {http://v1.example.com}foo1 whereas on the
> server we now have {http://v2.example.com}foo1
>
> What is the right way to fix this? Write an interceptor to modify the
> incoming namespace on the old URLs?
>
> Versioning in the namespace is a very common practice, so I am hoping this
> is a common problem that there is a good fix for. Let me know if I am
> doing something unorthodox.
>
> tia,
> rouble
--
Daniel Kulp
[email protected] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
