Hi
On 12/06/14 07:20, Jim Talbut wrote:
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:sberyoz...@gmail.com]
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).
As Aki pointed out, schema may contain elements not all of the consumers
will use. In fact jaxrs.xsd used by CXF 2.7.x has such characteristics,
some use jaxrs:server only, some - jaxrs:client with both elements being
part of that schema.
We also do not expect that CXF frontend schemas will be processed by JAXB.
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.
Right, option 3 is the 'purest' option as far as the best practice is
concerned.
To be honest, I'd like to avoid changing the original target namespace
for CXF 3.0.0 consumers a lot given how stable the schema has been and
is. For example, CXF 3.0.1 users who do not even use jaxrs:client would
still have to update target namespaces if we go with Option 3.
Option 2 would allow us to minimize side-effects, but I'd like to keep
the option of RS clients not having to depend on all of the server
frontend open :-).
Option 1 with the solution suggested by Dan is worth exploring. After
that I guess I'm more inclined toward going with Option 3. If Option 1
works then Option 3 can be introduced in 3.1.0, to minimize the
migration effort from CXF 2.x to 3.0.x, if not then well, option 3 would
have to be done for 3.0.1.
Cheers, Sergey
Jim
