cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: How to get a public jaxrs.xsd at org.apache.cxf support multiple CXF versions
Date Fri, 06 Jun 2014 16:14:09 GMT

On Jun 6, 2014, at 11:44 AM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:

> 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

We *might* be able to get 3.x to handle the client in the old namespace as well via the transformation
feature.   During the parsing of the element (either spring or blueprint), we could take the
element and use the transform to change all the namespaces.  Then call back into the blueprint/spring
container to have it parse/process that new element.  


-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message