On Jun 6, 2014, at 11:44 AM, Sergey Beryozkin <[email protected]> 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 [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
