2014-06-06 17:44 GMT+02:00 Sergey Beryozkin <[email protected]>: > 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. Thanks. regards, aki > > Cheers, Sergey > > >> regards, aki >> >> >> 2014-06-06 11:57 GMT+02:00 Sergey Beryozkin <[email protected]>: >>> >>> 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 http://cxf.apache.org/jaxrs-client) 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, >>> "http://cxf.apache.org/jaxrs3x";, 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 > http://coders.talend.com/ > > Blog: http://sberyozkin.blogspot.com
