Hi Aki,
thanks for the comments,
On 06/06/14 16:32, Aki Yoshida wrote:
Hi Sergey,
Maybe, I am not getting the down side of option 1 right. Option 1
means, the schema contains some definitions that are no longer used. I
don't know if this is really bad. A component can decide which part to
implement and which part to ignore, no?
Right, yes, that is the case, the public jaxrs.xsd schema, available
only at org.apache.cxf/schemas, will have the 'client' element only to
support the CXF 2.x clients which use jaxrs:client and expecting it to
be in jaxrs.xsd, but no longer used by the CXF 3.x code which will use a
"client" in jaxrs-client.xsd instead. CXF 3.x itself ships jaxrs.xsd
without "client".
So it would be the simplest option. The only downside is that a CXF 3/x
user who is browsing the public schemas may get confused, knowing that
jaxrs-client.xsd also has a 'client' element. I guess I can simply add
the comments to the public jaxrs.xsd clarifying which consumers can work
with the "client" in the public jaxrs.xsd
The down side of option 3 is that you will have some duplicated type
definitions in two namespaces, no?
The option 3 is about having jaxrs.xsd and jaxrs3x.xsd at
org.apache.cxf. The former will have a target namespace ending with
"/jaxrs", as it is at the moment for all the CXF consumers. The latter
will have a targetNamespace ending with "/jaxrs3x" and all CXF clients
starting from 3.0.1 will be expected to use it when defining
jaxrs:server endpoints. So the public jaxrs.xsd will keep supporting CXF
2.x and CXF 3.0.0, jaxrs3x.xsd - CXF 3.0.1 and higher. CXF 3.0.1 will
ship jaxrs.xsd only except that its target namespace will be ending with
"/jaxrs3x"
Cheers, Sergey
regards, aki
2014-06-06 11:57 GMT+02:00 Sergey Beryozkin <[email protected]>:
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
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
