cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <elak...@gmail.com>
Subject Re: How to get a public jaxrs.xsd at org.apache.cxf support multiple CXF versions
Date Fri, 06 Jun 2014 15:32:52 GMT
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 <sberyozkin@gmail.com>:
> 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
>
>
>
>

Mime
View raw message