You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Veit Guna <ve...@gmx.de> on 2015/10/04 10:13:28 UTC

@...Param and client proxy

Hi.

I'm using Apache CXF 3.0.4 on client side against a Jersey based REST
service.
On client side I'm using the CXF client proxy using the server side
interface classes.

Now I encountered, that annotated fields (e.g. with @QueryParam) on
@BeanParam classes
are ignored when invoking a method passing the @BeanParam class.
Somewhere in a JIRA ticket,
I found the hint, that setters must be annotated instead. Doing so does
work indeed.

Is there a reason, why annotations on fields aren't supported? Isn't
this allowed based
on the JAX-RS spec? Since Jersey seems fine with it. The problem I have
is, that I would
have to change the server beans to be able to use the CXF client proxy.

Another thing I encountered is, that nested @BeanParam's doesn't seem to
be supported.

Having (pseudocode):

class A {
 B b;
 
 @BeanParam
 set(B b);
 B get();
}

class B {
 String bar;

 @QueryParam("foo")
 set(String bar);
 String get();
}

Interface {
 something(@BeanParam A a);
}

Invoking Jersey's endpoint manually giving the query params seem to work
without a problem.
I'm missing something?

Thanks
Veit




Re: @...Param and client proxy

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Veit

FYI, the nested BeanParams work OK now

Re a client proxy restriction that if you set @BeanParam on a field, 
setter/getter is still needed. As I mentioned - this is not needed on 
the server side, given that there are spec examples around of having the 
fields only, without method accessors, we just support it.
The client proxy side though is CXF specific and I think it is 
reasonable to expect a given bean to follow a typical bean style (fields 
are not public) - hence I'm tempted not to lift this restriction on the 
proxy side :-) as otherwise the proxy specific introspection cost would 
rise. Lets say the issue of lifting the restriction is still open :-)

Thanks Sergey

On 04/10/15 21:39, Sergey Beryozkin wrote:
> On 04/10/15 18:44, Veit Guna wrote:
>> Alright. Thanks for the quick feedback!
>>
>> May I create a ticket for that?
>>
> Sure, please do open JIRA tickets whenever you spot CXF client issues
>
> Cheers, Sergey
>
>> Thanks
>> Veit
>>
>> Am 04.10.2015 um 19:33 schrieb Sergey Beryozkin:
>>> Hi Veit
>>>
>>> The client proxy code apparently does not support nested BeanParams,
>>> so more work will need to be done
>>>
>>> Cheers, Sergey
>>> On 04/10/15 19:21, Veit Guna wrote:
>>>> Hi Sergey.
>>>>
>>>> I see. Any news about the nested @BeanParam :)?
>>>>
>>>> Cheers
>>>> Veit
>>>>
>>>> Am 04.10.2015 um 19:18 schrieb Sergey Beryozkin:
>>>>> Hi Veit
>>>>>
>>>>> The CXF server will also work the same way, the restriction is only on
>>>>> the client proxy side, I've just checked a code, it should be
>>>>> sufficient to have a setter - which is used to determine a possible
>>>>> field candidate without having to check all the fields - this is done
>>>>> on the proxy side because no caching is done so this optimization
>>>>> saves some time.
>>>>>
>>>>> I can investigate later on if dropping this optimization can work...
>>>>>
>>>>> Sergey
>>>>> On 04/10/15 11:12, Veit Guna wrote:
>>>>>> While working around the nested @BeanParam for now, I encountered the
>>>>>> fact,
>>>>>> that @...Param annotations work on fields now, but somehow
>>>>>> getter/setter
>>>>>> for that field
>>>>>> are still required. Leaving them out, will leave the value unset on
>>>>>> request.
>>>>>>
>>>>>> On the opposite, the Jersey server is fine with fields without
>>>>>> getter/setter.
>>>>>>
>>>>>> Is this by intention?
>>>>>>
>>>>>> Thanks
>>>>>> Veit
>>>>>>
>>>>>> Am 04.10.2015 um 10:25 schrieb Veit Guna:
>>>>>>> Ok, 3.0.5 seems to fix the field annotation issue - nice :).
>>>>>>>
>>>>>>> One to go...
>>>>>>>
>>>>>>> Am 04.10.2015 um 10:13 schrieb Veit Guna:
>>>>>>>> Hi.
>>>>>>>>
>>>>>>>> I'm using Apache CXF 3.0.4 on client side against a Jersey based
>>>>>>>> REST
>>>>>>>> service.
>>>>>>>> On client side I'm using the CXF client proxy using the server side
>>>>>>>> interface classes.
>>>>>>>>
>>>>>>>> Now I encountered, that annotated fields (e.g. with @QueryParam) on
>>>>>>>> @BeanParam classes
>>>>>>>> are ignored when invoking a method passing the @BeanParam class.
>>>>>>>> Somewhere in a JIRA ticket,
>>>>>>>> I found the hint, that setters must be annotated instead. Doing so
>>>>>>>> does
>>>>>>>> work indeed.
>>>>>>>>
>>>>>>>> Is there a reason, why annotations on fields aren't supported?
>>>>>>>> Isn't
>>>>>>>> this allowed based
>>>>>>>> on the JAX-RS spec? Since Jersey seems fine with it. The problem I
>>>>>>>> have
>>>>>>>> is, that I would
>>>>>>>> have to change the server beans to be able to use the CXF client
>>>>>>>> proxy.
>>>>>>>>
>>>>>>>> Another thing I encountered is, that nested @BeanParam's doesn't
>>>>>>>> seem to
>>>>>>>> be supported.
>>>>>>>>
>>>>>>>> Having (pseudocode):
>>>>>>>>
>>>>>>>> class A {
>>>>>>>>     B b;
>>>>>>>>
>>>>>>>>     @BeanParam
>>>>>>>>     set(B b);
>>>>>>>>     B get();
>>>>>>>> }
>>>>>>>>
>>>>>>>> class B {
>>>>>>>>     String bar;
>>>>>>>>
>>>>>>>>     @QueryParam("foo")
>>>>>>>>     set(String bar);
>>>>>>>>     String get();
>>>>>>>> }
>>>>>>>>
>>>>>>>> Interface {
>>>>>>>>     something(@BeanParam A a);
>>>>>>>> }
>>>>>>>>
>>>>>>>> Invoking Jersey's endpoint manually giving the query params seem to
>>>>>>>> work
>>>>>>>> without a problem.
>>>>>>>> I'm missing something?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Veit
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Re: @...Param and client proxy

Posted by Sergey Beryozkin <sb...@gmail.com>.
On 04/10/15 18:44, Veit Guna wrote:
> Alright. Thanks for the quick feedback!
>
> May I create a ticket for that?
>
Sure, please do open JIRA tickets whenever you spot CXF client issues

Cheers, Sergey

> Thanks
> Veit
>
> Am 04.10.2015 um 19:33 schrieb Sergey Beryozkin:
>> Hi Veit
>>
>> The client proxy code apparently does not support nested BeanParams,
>> so more work will need to be done
>>
>> Cheers, Sergey
>> On 04/10/15 19:21, Veit Guna wrote:
>>> Hi Sergey.
>>>
>>> I see. Any news about the nested @BeanParam :)?
>>>
>>> Cheers
>>> Veit
>>>
>>> Am 04.10.2015 um 19:18 schrieb Sergey Beryozkin:
>>>> Hi Veit
>>>>
>>>> The CXF server will also work the same way, the restriction is only on
>>>> the client proxy side, I've just checked a code, it should be
>>>> sufficient to have a setter - which is used to determine a possible
>>>> field candidate without having to check all the fields - this is done
>>>> on the proxy side because no caching is done so this optimization
>>>> saves some time.
>>>>
>>>> I can investigate later on if dropping this optimization can work...
>>>>
>>>> Sergey
>>>> On 04/10/15 11:12, Veit Guna wrote:
>>>>> While working around the nested @BeanParam for now, I encountered the
>>>>> fact,
>>>>> that @...Param annotations work on fields now, but somehow
>>>>> getter/setter
>>>>> for that field
>>>>> are still required. Leaving them out, will leave the value unset on
>>>>> request.
>>>>>
>>>>> On the opposite, the Jersey server is fine with fields without
>>>>> getter/setter.
>>>>>
>>>>> Is this by intention?
>>>>>
>>>>> Thanks
>>>>> Veit
>>>>>
>>>>> Am 04.10.2015 um 10:25 schrieb Veit Guna:
>>>>>> Ok, 3.0.5 seems to fix the field annotation issue - nice :).
>>>>>>
>>>>>> One to go...
>>>>>>
>>>>>> Am 04.10.2015 um 10:13 schrieb Veit Guna:
>>>>>>> Hi.
>>>>>>>
>>>>>>> I'm using Apache CXF 3.0.4 on client side against a Jersey based
>>>>>>> REST
>>>>>>> service.
>>>>>>> On client side I'm using the CXF client proxy using the server side
>>>>>>> interface classes.
>>>>>>>
>>>>>>> Now I encountered, that annotated fields (e.g. with @QueryParam) on
>>>>>>> @BeanParam classes
>>>>>>> are ignored when invoking a method passing the @BeanParam class.
>>>>>>> Somewhere in a JIRA ticket,
>>>>>>> I found the hint, that setters must be annotated instead. Doing so
>>>>>>> does
>>>>>>> work indeed.
>>>>>>>
>>>>>>> Is there a reason, why annotations on fields aren't supported? Isn't
>>>>>>> this allowed based
>>>>>>> on the JAX-RS spec? Since Jersey seems fine with it. The problem I
>>>>>>> have
>>>>>>> is, that I would
>>>>>>> have to change the server beans to be able to use the CXF client
>>>>>>> proxy.
>>>>>>>
>>>>>>> Another thing I encountered is, that nested @BeanParam's doesn't
>>>>>>> seem to
>>>>>>> be supported.
>>>>>>>
>>>>>>> Having (pseudocode):
>>>>>>>
>>>>>>> class A {
>>>>>>>     B b;
>>>>>>>
>>>>>>>     @BeanParam
>>>>>>>     set(B b);
>>>>>>>     B get();
>>>>>>> }
>>>>>>>
>>>>>>> class B {
>>>>>>>     String bar;
>>>>>>>
>>>>>>>     @QueryParam("foo")
>>>>>>>     set(String bar);
>>>>>>>     String get();
>>>>>>> }
>>>>>>>
>>>>>>> Interface {
>>>>>>>     something(@BeanParam A a);
>>>>>>> }
>>>>>>>
>>>>>>> Invoking Jersey's endpoint manually giving the query params seem to
>>>>>>> work
>>>>>>> without a problem.
>>>>>>> I'm missing something?
>>>>>>>
>>>>>>> Thanks
>>>>>>> Veit
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Re: @...Param and client proxy

Posted by Veit Guna <ve...@gmx.de>.
Alright. Thanks for the quick feedback!

May I create a ticket for that?

Thanks
Veit

Am 04.10.2015 um 19:33 schrieb Sergey Beryozkin:
> Hi Veit
>
> The client proxy code apparently does not support nested BeanParams,
> so more work will need to be done
>
> Cheers, Sergey
> On 04/10/15 19:21, Veit Guna wrote:
>> Hi Sergey.
>>
>> I see. Any news about the nested @BeanParam :)?
>>
>> Cheers
>> Veit
>>
>> Am 04.10.2015 um 19:18 schrieb Sergey Beryozkin:
>>> Hi Veit
>>>
>>> The CXF server will also work the same way, the restriction is only on
>>> the client proxy side, I've just checked a code, it should be
>>> sufficient to have a setter - which is used to determine a possible
>>> field candidate without having to check all the fields - this is done
>>> on the proxy side because no caching is done so this optimization
>>> saves some time.
>>>
>>> I can investigate later on if dropping this optimization can work...
>>>
>>> Sergey
>>> On 04/10/15 11:12, Veit Guna wrote:
>>>> While working around the nested @BeanParam for now, I encountered the
>>>> fact,
>>>> that @...Param annotations work on fields now, but somehow
>>>> getter/setter
>>>> for that field
>>>> are still required. Leaving them out, will leave the value unset on
>>>> request.
>>>>
>>>> On the opposite, the Jersey server is fine with fields without
>>>> getter/setter.
>>>>
>>>> Is this by intention?
>>>>
>>>> Thanks
>>>> Veit
>>>>
>>>> Am 04.10.2015 um 10:25 schrieb Veit Guna:
>>>>> Ok, 3.0.5 seems to fix the field annotation issue - nice :).
>>>>>
>>>>> One to go...
>>>>>
>>>>> Am 04.10.2015 um 10:13 schrieb Veit Guna:
>>>>>> Hi.
>>>>>>
>>>>>> I'm using Apache CXF 3.0.4 on client side against a Jersey based
>>>>>> REST
>>>>>> service.
>>>>>> On client side I'm using the CXF client proxy using the server side
>>>>>> interface classes.
>>>>>>
>>>>>> Now I encountered, that annotated fields (e.g. with @QueryParam) on
>>>>>> @BeanParam classes
>>>>>> are ignored when invoking a method passing the @BeanParam class.
>>>>>> Somewhere in a JIRA ticket,
>>>>>> I found the hint, that setters must be annotated instead. Doing so
>>>>>> does
>>>>>> work indeed.
>>>>>>
>>>>>> Is there a reason, why annotations on fields aren't supported? Isn't
>>>>>> this allowed based
>>>>>> on the JAX-RS spec? Since Jersey seems fine with it. The problem I
>>>>>> have
>>>>>> is, that I would
>>>>>> have to change the server beans to be able to use the CXF client
>>>>>> proxy.
>>>>>>
>>>>>> Another thing I encountered is, that nested @BeanParam's doesn't
>>>>>> seem to
>>>>>> be supported.
>>>>>>
>>>>>> Having (pseudocode):
>>>>>>
>>>>>> class A {
>>>>>>    B b;
>>>>>>
>>>>>>    @BeanParam
>>>>>>    set(B b);
>>>>>>    B get();
>>>>>> }
>>>>>>
>>>>>> class B {
>>>>>>    String bar;
>>>>>>
>>>>>>    @QueryParam("foo")
>>>>>>    set(String bar);
>>>>>>    String get();
>>>>>> }
>>>>>>
>>>>>> Interface {
>>>>>>    something(@BeanParam A a);
>>>>>> }
>>>>>>
>>>>>> Invoking Jersey's endpoint manually giving the query params seem to
>>>>>> work
>>>>>> without a problem.
>>>>>> I'm missing something?
>>>>>>
>>>>>> Thanks
>>>>>> Veit
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>>
>>
>


Re: @...Param and client proxy

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Veit

The client proxy code apparently does not support nested BeanParams, so 
more work will need to be done

Cheers, Sergey
On 04/10/15 19:21, Veit Guna wrote:
> Hi Sergey.
>
> I see. Any news about the nested @BeanParam :)?
>
> Cheers
> Veit
>
> Am 04.10.2015 um 19:18 schrieb Sergey Beryozkin:
>> Hi Veit
>>
>> The CXF server will also work the same way, the restriction is only on
>> the client proxy side, I've just checked a code, it should be
>> sufficient to have a setter - which is used to determine a possible
>> field candidate without having to check all the fields - this is done
>> on the proxy side because no caching is done so this optimization
>> saves some time.
>>
>> I can investigate later on if dropping this optimization can work...
>>
>> Sergey
>> On 04/10/15 11:12, Veit Guna wrote:
>>> While working around the nested @BeanParam for now, I encountered the
>>> fact,
>>> that @...Param annotations work on fields now, but somehow getter/setter
>>> for that field
>>> are still required. Leaving them out, will leave the value unset on
>>> request.
>>>
>>> On the opposite, the Jersey server is fine with fields without
>>> getter/setter.
>>>
>>> Is this by intention?
>>>
>>> Thanks
>>> Veit
>>>
>>> Am 04.10.2015 um 10:25 schrieb Veit Guna:
>>>> Ok, 3.0.5 seems to fix the field annotation issue - nice :).
>>>>
>>>> One to go...
>>>>
>>>> Am 04.10.2015 um 10:13 schrieb Veit Guna:
>>>>> Hi.
>>>>>
>>>>> I'm using Apache CXF 3.0.4 on client side against a Jersey based REST
>>>>> service.
>>>>> On client side I'm using the CXF client proxy using the server side
>>>>> interface classes.
>>>>>
>>>>> Now I encountered, that annotated fields (e.g. with @QueryParam) on
>>>>> @BeanParam classes
>>>>> are ignored when invoking a method passing the @BeanParam class.
>>>>> Somewhere in a JIRA ticket,
>>>>> I found the hint, that setters must be annotated instead. Doing so
>>>>> does
>>>>> work indeed.
>>>>>
>>>>> Is there a reason, why annotations on fields aren't supported? Isn't
>>>>> this allowed based
>>>>> on the JAX-RS spec? Since Jersey seems fine with it. The problem I
>>>>> have
>>>>> is, that I would
>>>>> have to change the server beans to be able to use the CXF client
>>>>> proxy.
>>>>>
>>>>> Another thing I encountered is, that nested @BeanParam's doesn't
>>>>> seem to
>>>>> be supported.
>>>>>
>>>>> Having (pseudocode):
>>>>>
>>>>> class A {
>>>>>    B b;
>>>>>
>>>>>    @BeanParam
>>>>>    set(B b);
>>>>>    B get();
>>>>> }
>>>>>
>>>>> class B {
>>>>>    String bar;
>>>>>
>>>>>    @QueryParam("foo")
>>>>>    set(String bar);
>>>>>    String get();
>>>>> }
>>>>>
>>>>> Interface {
>>>>>    something(@BeanParam A a);
>>>>> }
>>>>>
>>>>> Invoking Jersey's endpoint manually giving the query params seem to
>>>>> work
>>>>> without a problem.
>>>>> I'm missing something?
>>>>>
>>>>> Thanks
>>>>> Veit
>>>>>
>>>>>
>>>>>
>>>
>>
>>
>


Re: @...Param and client proxy

Posted by Veit Guna <ve...@gmx.de>.
Hi Sergey.

I see. Any news about the nested @BeanParam :)?

Cheers
Veit

Am 04.10.2015 um 19:18 schrieb Sergey Beryozkin:
> Hi Veit
>
> The CXF server will also work the same way, the restriction is only on
> the client proxy side, I've just checked a code, it should be
> sufficient to have a setter - which is used to determine a possible
> field candidate without having to check all the fields - this is done
> on the proxy side because no caching is done so this optimization
> saves some time.
>
> I can investigate later on if dropping this optimization can work...
>
> Sergey
> On 04/10/15 11:12, Veit Guna wrote:
>> While working around the nested @BeanParam for now, I encountered the
>> fact,
>> that @...Param annotations work on fields now, but somehow getter/setter
>> for that field
>> are still required. Leaving them out, will leave the value unset on
>> request.
>>
>> On the opposite, the Jersey server is fine with fields without
>> getter/setter.
>>
>> Is this by intention?
>>
>> Thanks
>> Veit
>>
>> Am 04.10.2015 um 10:25 schrieb Veit Guna:
>>> Ok, 3.0.5 seems to fix the field annotation issue - nice :).
>>>
>>> One to go...
>>>
>>> Am 04.10.2015 um 10:13 schrieb Veit Guna:
>>>> Hi.
>>>>
>>>> I'm using Apache CXF 3.0.4 on client side against a Jersey based REST
>>>> service.
>>>> On client side I'm using the CXF client proxy using the server side
>>>> interface classes.
>>>>
>>>> Now I encountered, that annotated fields (e.g. with @QueryParam) on
>>>> @BeanParam classes
>>>> are ignored when invoking a method passing the @BeanParam class.
>>>> Somewhere in a JIRA ticket,
>>>> I found the hint, that setters must be annotated instead. Doing so
>>>> does
>>>> work indeed.
>>>>
>>>> Is there a reason, why annotations on fields aren't supported? Isn't
>>>> this allowed based
>>>> on the JAX-RS spec? Since Jersey seems fine with it. The problem I
>>>> have
>>>> is, that I would
>>>> have to change the server beans to be able to use the CXF client
>>>> proxy.
>>>>
>>>> Another thing I encountered is, that nested @BeanParam's doesn't
>>>> seem to
>>>> be supported.
>>>>
>>>> Having (pseudocode):
>>>>
>>>> class A {
>>>>   B b;
>>>>
>>>>   @BeanParam
>>>>   set(B b);
>>>>   B get();
>>>> }
>>>>
>>>> class B {
>>>>   String bar;
>>>>
>>>>   @QueryParam("foo")
>>>>   set(String bar);
>>>>   String get();
>>>> }
>>>>
>>>> Interface {
>>>>   something(@BeanParam A a);
>>>> }
>>>>
>>>> Invoking Jersey's endpoint manually giving the query params seem to
>>>> work
>>>> without a problem.
>>>> I'm missing something?
>>>>
>>>> Thanks
>>>> Veit
>>>>
>>>>
>>>>
>>
>
>


Re: @...Param and client proxy

Posted by David Karlsen <da...@gmail.com>.
Maybe https://code.google.com/p/reflections/ could help?

2015-10-04 19:18 GMT+02:00 Sergey Beryozkin <sb...@gmail.com>:

> Hi Veit
>
> The CXF server will also work the same way, the restriction is only on the
> client proxy side, I've just checked a code, it should be sufficient to
> have a setter - which is used to determine a possible field candidate
> without having to check all the fields - this is done on the proxy side
> because no caching is done so this optimization saves some time.
>
> I can investigate later on if dropping this optimization can work...
>
> Sergey
> On 04/10/15 11:12, Veit Guna wrote:
>
>> While working around the nested @BeanParam for now, I encountered the
>> fact,
>> that @...Param annotations work on fields now, but somehow getter/setter
>> for that field
>> are still required. Leaving them out, will leave the value unset on
>> request.
>>
>> On the opposite, the Jersey server is fine with fields without
>> getter/setter.
>>
>> Is this by intention?
>>
>> Thanks
>> Veit
>>
>> Am 04.10.2015 um 10:25 schrieb Veit Guna:
>>
>>> Ok, 3.0.5 seems to fix the field annotation issue - nice :).
>>>
>>> One to go...
>>>
>>> Am 04.10.2015 um 10:13 schrieb Veit Guna:
>>>
>>>> Hi.
>>>>
>>>> I'm using Apache CXF 3.0.4 on client side against a Jersey based REST
>>>> service.
>>>> On client side I'm using the CXF client proxy using the server side
>>>> interface classes.
>>>>
>>>> Now I encountered, that annotated fields (e.g. with @QueryParam) on
>>>> @BeanParam classes
>>>> are ignored when invoking a method passing the @BeanParam class.
>>>> Somewhere in a JIRA ticket,
>>>> I found the hint, that setters must be annotated instead. Doing so does
>>>> work indeed.
>>>>
>>>> Is there a reason, why annotations on fields aren't supported? Isn't
>>>> this allowed based
>>>> on the JAX-RS spec? Since Jersey seems fine with it. The problem I have
>>>> is, that I would
>>>> have to change the server beans to be able to use the CXF client proxy.
>>>>
>>>> Another thing I encountered is, that nested @BeanParam's doesn't seem to
>>>> be supported.
>>>>
>>>> Having (pseudocode):
>>>>
>>>> class A {
>>>>   B b;
>>>>
>>>>   @BeanParam
>>>>   set(B b);
>>>>   B get();
>>>> }
>>>>
>>>> class B {
>>>>   String bar;
>>>>
>>>>   @QueryParam("foo")
>>>>   set(String bar);
>>>>   String get();
>>>> }
>>>>
>>>> Interface {
>>>>   something(@BeanParam A a);
>>>> }
>>>>
>>>> Invoking Jersey's endpoint manually giving the query params seem to work
>>>> without a problem.
>>>> I'm missing something?
>>>>
>>>> Thanks
>>>> Veit
>>>>
>>>>
>>>>
>>>>
>>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>



-- 
--
David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen

Re: @...Param and client proxy

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Veit

The CXF server will also work the same way, the restriction is only on 
the client proxy side, I've just checked a code, it should be sufficient 
to have a setter - which is used to determine a possible field candidate 
without having to check all the fields - this is done on the proxy side 
because no caching is done so this optimization saves some time.

I can investigate later on if dropping this optimization can work...

Sergey
On 04/10/15 11:12, Veit Guna wrote:
> While working around the nested @BeanParam for now, I encountered the fact,
> that @...Param annotations work on fields now, but somehow getter/setter
> for that field
> are still required. Leaving them out, will leave the value unset on request.
>
> On the opposite, the Jersey server is fine with fields without
> getter/setter.
>
> Is this by intention?
>
> Thanks
> Veit
>
> Am 04.10.2015 um 10:25 schrieb Veit Guna:
>> Ok, 3.0.5 seems to fix the field annotation issue - nice :).
>>
>> One to go...
>>
>> Am 04.10.2015 um 10:13 schrieb Veit Guna:
>>> Hi.
>>>
>>> I'm using Apache CXF 3.0.4 on client side against a Jersey based REST
>>> service.
>>> On client side I'm using the CXF client proxy using the server side
>>> interface classes.
>>>
>>> Now I encountered, that annotated fields (e.g. with @QueryParam) on
>>> @BeanParam classes
>>> are ignored when invoking a method passing the @BeanParam class.
>>> Somewhere in a JIRA ticket,
>>> I found the hint, that setters must be annotated instead. Doing so does
>>> work indeed.
>>>
>>> Is there a reason, why annotations on fields aren't supported? Isn't
>>> this allowed based
>>> on the JAX-RS spec? Since Jersey seems fine with it. The problem I have
>>> is, that I would
>>> have to change the server beans to be able to use the CXF client proxy.
>>>
>>> Another thing I encountered is, that nested @BeanParam's doesn't seem to
>>> be supported.
>>>
>>> Having (pseudocode):
>>>
>>> class A {
>>>   B b;
>>>
>>>   @BeanParam
>>>   set(B b);
>>>   B get();
>>> }
>>>
>>> class B {
>>>   String bar;
>>>
>>>   @QueryParam("foo")
>>>   set(String bar);
>>>   String get();
>>> }
>>>
>>> Interface {
>>>   something(@BeanParam A a);
>>> }
>>>
>>> Invoking Jersey's endpoint manually giving the query params seem to work
>>> without a problem.
>>> I'm missing something?
>>>
>>> Thanks
>>> Veit
>>>
>>>
>>>
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Re: @...Param and client proxy

Posted by Veit Guna <ve...@gmx.de>.
While working around the nested @BeanParam for now, I encountered the fact,
that @...Param annotations work on fields now, but somehow getter/setter
for that field
are still required. Leaving them out, will leave the value unset on request.

On the opposite, the Jersey server is fine with fields without
getter/setter.

Is this by intention?

Thanks
Veit

Am 04.10.2015 um 10:25 schrieb Veit Guna:
> Ok, 3.0.5 seems to fix the field annotation issue - nice :).
>
> One to go...
>
> Am 04.10.2015 um 10:13 schrieb Veit Guna:
>> Hi.
>>
>> I'm using Apache CXF 3.0.4 on client side against a Jersey based REST
>> service.
>> On client side I'm using the CXF client proxy using the server side
>> interface classes.
>>
>> Now I encountered, that annotated fields (e.g. with @QueryParam) on
>> @BeanParam classes
>> are ignored when invoking a method passing the @BeanParam class.
>> Somewhere in a JIRA ticket,
>> I found the hint, that setters must be annotated instead. Doing so does
>> work indeed.
>>
>> Is there a reason, why annotations on fields aren't supported? Isn't
>> this allowed based
>> on the JAX-RS spec? Since Jersey seems fine with it. The problem I have
>> is, that I would
>> have to change the server beans to be able to use the CXF client proxy.
>>
>> Another thing I encountered is, that nested @BeanParam's doesn't seem to
>> be supported.
>>
>> Having (pseudocode):
>>
>> class A {
>>  B b;
>>  
>>  @BeanParam
>>  set(B b);
>>  B get();
>> }
>>
>> class B {
>>  String bar;
>>
>>  @QueryParam("foo")
>>  set(String bar);
>>  String get();
>> }
>>
>> Interface {
>>  something(@BeanParam A a);
>> }
>>
>> Invoking Jersey's endpoint manually giving the query params seem to work
>> without a problem.
>> I'm missing something?
>>
>> Thanks
>> Veit
>>
>>
>>


Re: @...Param and client proxy

Posted by Veit Guna <ve...@gmx.de>.
Ok, 3.0.5 seems to fix the field annotation issue - nice :).

One to go...

Am 04.10.2015 um 10:13 schrieb Veit Guna:
> Hi.
>
> I'm using Apache CXF 3.0.4 on client side against a Jersey based REST
> service.
> On client side I'm using the CXF client proxy using the server side
> interface classes.
>
> Now I encountered, that annotated fields (e.g. with @QueryParam) on
> @BeanParam classes
> are ignored when invoking a method passing the @BeanParam class.
> Somewhere in a JIRA ticket,
> I found the hint, that setters must be annotated instead. Doing so does
> work indeed.
>
> Is there a reason, why annotations on fields aren't supported? Isn't
> this allowed based
> on the JAX-RS spec? Since Jersey seems fine with it. The problem I have
> is, that I would
> have to change the server beans to be able to use the CXF client proxy.
>
> Another thing I encountered is, that nested @BeanParam's doesn't seem to
> be supported.
>
> Having (pseudocode):
>
> class A {
>  B b;
>  
>  @BeanParam
>  set(B b);
>  B get();
> }
>
> class B {
>  String bar;
>
>  @QueryParam("foo")
>  set(String bar);
>  String get();
> }
>
> Interface {
>  something(@BeanParam A a);
> }
>
> Invoking Jersey's endpoint manually giving the query params seem to work
> without a problem.
> I'm missing something?
>
> Thanks
> Veit
>
>
>