[
https://issues.apache.org/jira/browse/CXF-7267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15897038#comment-15897038
]
Sergey Beryozkin edited comment on CXF-7267 at 3/6/17 10:21 AM:
----------------------------------------------------------------
Hi, what you qualified as a workaround is a preferred solution. On the client
side there must be a setter available for a given bean param property, having a
bean with some private property without the setter which would set it is not a
proper Java bean style, and when you have the setter then either set the
annotation on this setter or if you prefer set them on the fields then make
sure there is a match - IDEs do that so there's nothing unusual in the fact
that a match is sought.
Note on the server side I'm not enforcing it, but having to start deeply
iterating over filelds and start reflectively injecting them on *every* client
proxy call is expensive, the basic match constraint in case of the annotations
being only on the fields was all about the optimization and with the client
proxy API being not standard it is reasonable IMHO
was (Author: sergey_beryozkin):
Hi, what you qualified as a workaround is a preferred solution. On the client
side there must be a setter available for a given bean param property, having a
bean with some private property without the setter which would set it is not a
proper Java bean style, and when you have a the setter then either set the
annotation on this setter or if you prefer set them on the fields then make
sure there is a match - IDEs do that so there's nothing unusual in the fact
that a match is sought.
Note on the server side I'm not enforcing it, but having to start deeply
iterating over filelds and start reflectively injecting them on *every* client
proxy call is expensive, the basic match constraint in case of the annotations
being only on the fields was all about the optimization and with the client
proxy API being not standard it is reasonable IMHO
> Member names must match bean attribute for BeanParam to work
> ------------------------------------------------------------
>
> Key: CXF-7267
> URL: https://issues.apache.org/jira/browse/CXF-7267
> Project: CXF
> Issue Type: Bug
> Affects Versions: 3.1.4
> Reporter: Daniel H. Peger
> Priority: Minor
>
> I just ran into this problem on my first attempt to use {{@BeanParam}} and
> got this exception:
> {noformat}
> java.lang.IllegalArgumentException: Unresolved variables; only 0 value(s)
> given for 2 unique variable(s)
> at
> org.apache.cxf.jaxrs.impl.UriBuilderImpl.substituteVarargs(UriBuilderImpl.java:285)
> at
> org.apache.cxf.jaxrs.impl.UriBuilderImpl.doBuildUriParts(UriBuilderImpl.java:121)
> ...
> {noformat}
> My parameter bean looked like this:
> {code}package com.recommind.common.rest;
> import javax.ws.rs.PathParam;
> public final class ApplicationIdentifierParameter
> {
> @PathParam("applicationId")
> private String mApplicationId;
> @PathParam("projectId")
> private String mProjectId;
> public String getApplicationId()
> {
> return mApplicationId;
> }
> public void setApplicationId(String aApplicationId)
> {
> mApplicationId = aApplicationId;
> }
> public String getProjectId()
> {
> return mProjectId;
> }
> public void setProjectId(String aProjectId)
> {
> mProjectId = aProjectId;
> }
> }
> {code}
> I debugged {{UriBuilderImpl}} and found that in {{ClientProxyImpl:514}} the
> to be evaluated members are identified by the names of the corresponding
> setters.
> I think this is wrong - or at least inconvenient - as it is totally valid for
> a bean's internals fields to have different names than the corresponding bean
> attribute. To my knowledge the Bean spec only requires setters and getters to
> match and does not care about the internal representation of the attributes.
> Rather than looking at the setters {{ClientProxyImpl}} should iterate over
> the bean's fields, look for fields annotated with {{@PathParam}} and update
> the field using reflection.
> *Workaround:*
> Annotate the setters with the {{@XXXParam}} annotations.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
