cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Talbut <>
Subject Re: How to get a public jaxrs.xsd at org.apache.cxf support multiple CXF versions [romana]
Date Thu, 12 Jun 2014 06:20:36 GMT
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 []
>> 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
>> 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
>> is not a big deal really
>> 3. In CXF 3.0.1: update a shipped jaxrs.xsd to have a new target namespace,
>> "", 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).
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.


View raw message