cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: How to get a public jaxrs.xsd at org.apache.cxf support multiple CXF versions
Date Fri, 06 Jun 2014 15:44:42 GMT
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 

Cheers, Sergey

> regards, aki
> 2014-06-06 11:57 GMT+02:00 Sergey Beryozkin <>:
>> 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 it 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

Sergey Beryozkin

Talend Community Coders


View raw message