On 09/06/2014 18:15, Andrei Shakirin wrote:
Hi Sergei,
I am also a bit concerned about autocomplete feature actively used in IDEs
(mentioned by Dan). Keeping unsupported element in schema can be a bit
confusing because of that.
Therefore if handling the client in the old namespace via the transformation
feature will be too complicated in option (1), I would prefer option (2) with
keeping dependency client -> frontend.
Regards,
Andrei.
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: Freitag, 6. Juni 2014 11:57
To: CXF Dev
Subject: How to get a public jaxrs.xsd at org.apache.cxf support multiple CXF
versions
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
Having superfluous elements in the schema is confusing and inefficient
(if something like JAXB is run against the schema it will generate
invalid members).
Please go for option 3.
Any change to a schema should result in a new namespace; and any
incompatible change must result in a new namespace.
Jim
