Hi Dan
On 06/06/14 17:14, Daniel Kulp wrote:
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.
That sounds like a pretty cool idea in itself :-). But I'm not sure yet
when we'd apply it, the only issue right now that I'm aware of is that
CXF 2.x clients using jaxrs:client (and running in IDE, etc) have their
beans.xml failing to validate against the public jaxrs.xsd at
org.apache.cxf, with the workaround in place...
Are you thinking of CXF 3.x deployments picking up CXF 2.x beans.xml ?
Yeah, that is possible and I guess your idea may save it there... I'll
def keep in mind...
Thanks, Sergey
