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




Reply via email to