Hi Aki,
On 06/06/14 17:08, Aki Yoshida wrote:
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?
That in itself will not give us anything but adding a redundant 'client'
element into CXF 3.x jaxrs.xsd that we ship, right ? Unless we want to
go to option 2 I described earlier.
At the moment this redundant element is only in the public jaxrs.xsd at
org.apache,cxf to keep CXF 2.x clients happy, CXF 3.x clients don't need
it per se in there.
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.
No, not really, if we go for option 3 then only CXF 3.0.1 clients and
above will have to start using /jaxrs3x.
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.
Sounds good, thanks for the feedback so far
Cheers, Sergey
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
