cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: How to get a public jaxrs.xsd at org.apache.cxf support multiple CXF versions
Date Fri, 06 Jun 2014 20:44:35 GMT
Hi Dan
On 06/06/14 17:14, Daniel Kulp wrote:
>
> 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.
>
>
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

Mime
View raw message