cxf-dev mailing list archives

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

CXF 3.x itself can ship also the jaxrs.xsd with the "unused" client
definition with the comment that you described below, no?

> 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 "/jaxrs3x"

Does this mean, your beans.xml for 2.7.x/3.0.0 needs to be updated for
3.0.1 to use the ".../jaxrs3x" namespace?
And if you want to make the old beans.xml also work for 3.0.1, you
will need duplicated code to handle both namespaces.

And this was not clear to me. Maybe, I don't know the difference
between those non-client schema part of "…/jaxrs" and ".../jaxrs3x"
schemas whether there is some incompatible structural changes or
somehow the difference is compatibly shared. I'll look at them to get
a better understanding.

regards, aki
> 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
> Blog:

View raw message