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?
The down side of option 3 is that you will have some duplicated type definitions in two namespaces, no? 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 > > > >
