cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Shakirin <ashaki...@talend.com>
Subject RE: How to get a public jaxrs.xsd at org.apache.cxf support multiple CXF versions
Date Mon, 09 Jun 2014 17:15:46 GMT
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:sberyozkin@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
> 
> 
> 


Mime
View raw message