You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Sergey Beryozkin <sb...@gmail.com> on 2014/06/06 11:57:25 UTC
How to get a public jaxrs.xsd at org.apache.cxf support multiple
CXF versions
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
Re: How to get a public jaxrs.xsd at org.apache.cxf support multiple CXF versions
Posted by Daniel Kulp <dk...@apache.org>.
On Jun 6, 2014, at 4:44 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi Dan
> On 06/06/14 17:14, Daniel Kulp wrote:
>>
>>
>> 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...
>
Well, the other thing that happens is that if you use an XML editor that does syntax completion along with the validation, when editing an XML file, you would see the jaxrs:client element in the namespace and think “this should work, it’s in the schema” even though it currently won’t work in 3.0. That’s more why I made the above suggestion. If it’s in the “public” schema, it would be good if we can get it to work. Basically, it allows your “#1” option to completely work.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: How to get a public jaxrs.xsd at org.apache.cxf support multiple
CXF versions
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Dan
On 06/06/14 17:14, Daniel Kulp wrote:
>
> On Jun 6, 2014, at 11:44 AM, Sergey Beryozkin <sb...@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
Re: How to get a public jaxrs.xsd at org.apache.cxf support multiple CXF versions
Posted by Daniel Kulp <dk...@apache.org>.
On Jun 6, 2014, at 11:44 AM, Sergey Beryozkin <sb...@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.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: How to get a public jaxrs.xsd at org.apache.cxf support multiple
CXF versions
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Aki,
On 06/06/14 17:08, Aki Yoshida wrote:
> 2014-06-06 17:44 GMT+02:00 Sergey Beryozkin <sb...@gmail.com>:
>> 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 <sb...@gmail.com>:
>>>>
>>>> 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
Re: How to get a public jaxrs.xsd at org.apache.cxf support multiple
CXF versions
Posted by Aki Yoshida <el...@gmail.com>.
2014-06-06 17:44 GMT+02:00 Sergey Beryozkin <sb...@gmail.com>:
> 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 <sb...@gmail.com>:
>>>
>>> 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
Re: How to get a public jaxrs.xsd at org.apache.cxf support multiple
CXF versions
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
> 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"
Cheers, Sergey
> regards, aki
>
>
> 2014-06-06 11:57 GMT+02:00 Sergey Beryozkin <sb...@gmail.com>:
>> 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
Re: How to get a public jaxrs.xsd at org.apache.cxf support multiple
CXF versions
Posted by Aki Yoshida <el...@gmail.com>.
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?
The down side of option 3 is that you will have some duplicated type
definitions in two namespaces, no?
regards, aki
2014-06-06 11:57 GMT+02:00 Sergey Beryozkin <sb...@gmail.com>:
> 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
>
>
>
>
Re: How to get a public jaxrs.xsd at org.apache.cxf support multiple
CXF versions [romana]
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 12/06/14 07:20, Jim Talbut wrote:
> On 09/06/2014 18:15, Andrei Shakirin wrote:
>> Hi Sergei,
>>
>> I am also a bit concerned about autocomplete feature actively used in
>> IDEs (mentioned by Dan). Keeping unsupported element in schema can be
>> a bit confusing because of that.
>> Therefore if handling the client in the old namespace via the
>> transformation feature will be too complicated in option (1), I would
>> prefer option (2) with keeping dependency client -> frontend.
>>
>> Regards,
>> Andrei.
>>
>>> -----Original Message-----
>>> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>>> Sent: Freitag, 6. Juni 2014 11:57
>>> To: CXF Dev
>>> Subject: How to get a public jaxrs.xsd at org.apache.cxf support
>>> multiple CXF
>>> versions
>>>
>>> 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
>>>
> Having superfluous elements in the schema is confusing and inefficient
> (if something like JAXB is run against the schema it will generate
> invalid members).
As Aki pointed out, schema may contain elements not all of the consumers
will use. In fact jaxrs.xsd used by CXF 2.7.x has such characteristics,
some use jaxrs:server only, some - jaxrs:client with both elements being
part of that schema.
We also do not expect that CXF frontend schemas will be processed by JAXB.
> Please go for option 3.
> Any change to a schema should result in a new namespace; and any
> incompatible change must result in a new namespace.
>
Right, option 3 is the 'purest' option as far as the best practice is
concerned.
To be honest, I'd like to avoid changing the original target namespace
for CXF 3.0.0 consumers a lot given how stable the schema has been and
is. For example, CXF 3.0.1 users who do not even use jaxrs:client would
still have to update target namespaces if we go with Option 3.
Option 2 would allow us to minimize side-effects, but I'd like to keep
the option of RS clients not having to depend on all of the server
frontend open :-).
Option 1 with the solution suggested by Dan is worth exploring. After
that I guess I'm more inclined toward going with Option 3. If Option 1
works then Option 3 can be introduced in 3.1.0, to minimize the
migration effort from CXF 2.x to 3.0.x, if not then well, option 3 would
have to be done for 3.0.1.
Cheers, Sergey
> Jim
Re: How to get a public jaxrs.xsd at org.apache.cxf support multiple
CXF versions [romana]
Posted by Jim Talbut <jt...@spudsoft.co.uk>.
On 09/06/2014 18:15, Andrei Shakirin wrote:
> Hi Sergei,
>
> I am also a bit concerned about autocomplete feature actively used in IDEs (mentioned by Dan). Keeping unsupported element in schema can be a bit confusing because of that.
> Therefore if handling the client in the old namespace via the transformation feature will be too complicated in option (1), I would prefer option (2) with keeping dependency client -> frontend.
>
> Regards,
> Andrei.
>
>> -----Original Message-----
>> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>> Sent: Freitag, 6. Juni 2014 11:57
>> To: CXF Dev
>> Subject: How to get a public jaxrs.xsd at org.apache.cxf support multiple CXF
>> versions
>>
>> 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
>>
Having superfluous elements in the schema is confusing and inefficient
(if something like JAXB is run against the schema it will generate
invalid members).
Please go for option 3.
Any change to a schema should result in a new namespace; and any
incompatible change must result in a new namespace.
Jim
RE: How to get a public jaxrs.xsd at org.apache.cxf support
multiple CXF versions
Posted by Andrei Shakirin <as...@talend.com>.
Hi Sergei,
I am also a bit concerned about autocomplete feature actively used in IDEs (mentioned by Dan). Keeping unsupported element in schema can be a bit confusing because of that.
Therefore if handling the client in the old namespace via the transformation feature will be too complicated in option (1), I would prefer option (2) with keeping dependency client -> frontend.
Regards,
Andrei.
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> Sent: Freitag, 6. Juni 2014 11:57
> To: CXF Dev
> Subject: How to get a public jaxrs.xsd at org.apache.cxf support multiple CXF
> versions
>
> 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
>
>
>