Hi
In CXF 3.0.0 we've had a "client" element used to be defined in
jaxrs.xsd shipped with the rt/frontend/jaxrs module moved out (alongside
with the code supporting Client API) to a new jaxrs-client.xsd (with a
new target namespace http://cxf.apache.org/jaxrs-client) now shipped
with the rt/rs/client module.
This is documented in the migration guide.
Note that I've updated a target namespace for a 'client' element not for
some design reasons but only due to the fact that I came to the
conclusion it was not possible to have a shared/single target namespace
for schemas shipped in multiple modules.
So, after 3.0.0 has been released I've pushed a new jaxrs.xsd schema
without the 'client' element to org.apache.cxf. And we've started
getting reports of CXF 2.x clients using jaxrs:client getting the
validation issues.
So I wonder what would should the best strategy be for supporting
multiple CXF versions validating against a public jaxrs schema be,
without having to introduce the numbers or dates into target schema
namespace (just for the sake of simplicity, given that the schemas are
in themselves are very stable now, with only very attributes or optional
elements possibly added in the future).
I can think of 4 options:
1. The current workaround has been to restore the old 'client' element
only in the public jaxrs.xsd at org.apache.cxf/schemas just to keep CXF
2.x clients using jaxrs:client getting the validation working.
If it works and will have no side-effects over a some period of time
then may be we can settle with this solution, even though it's
effectively a hack.
2. Revert the migration of 'client' into a new target namespace
"jaxrs-client", have "client" restored in jaxrs.xsd, and either
'include' jaxrs.xsd or use it directly in rt/rs/client. The downside: we
will never be able to break a link between RS client and RS frontend
modules, which is on the map, at the moment only the RS frontend has
benefited from getting the client code moved out of it, while the client
code is still depending on all of the frontend RS; may it is not a big
deal really
3. In CXF 3.0.1: update a shipped jaxrs.xsd to have a new target
namespace, "http://cxf.apache.org/jaxrs3x", restore the old jaxrs.xsd at
org.apache.cxf and redirect "/jaxrs3x" requests to a new jaxrs3x.xsd file.
This is probably the best solution as far as the best practice is concerned.
4. Add jaxrs2x.xsd file to org.apache.cxf and advise CXF 2.x clients
working with jaxrs:client update schemaLocation elements accordingly.
This will work but kind of not cool, breaking the validation for the
existing working clients is not good, even though it is a tiny change.
Any comments please ?
Right now I'd like to see if 1. works and open to doing 3. in CXF 3.0.1
Thanks, Sergey