Hi Veit
Thanks for being positive, well, if it won't work in your case then we
will fix it :-)
Cheers, Sergey
On 19/10/15 10:55, Veit Guna wrote:
Hi Sergey.
Didn't find time yet to test it, but I'm confident that it will work :).
Thanks!
Veit
Gesendet: Freitag, 09. Oktober 2015 um 13:35 Uhr
Von: "Sergey Beryozkin" <sberyoz...@gmail.com>
An: users@cxf.apache.org
Betreff: Re: @...Param and client proxy
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/