Hi Francesco, thanks for the confirmation,
@BeanParam refers to a bean which captures parameters like query, path,
header, matrix or any of JAX-RS contexts, but not the actual body.
Cheers, Sergey
On 10/06/15 14:57, Francesco Chicchiriccò wrote:
On 09/06/2015 15:34, Francesco Chicchiriccò wrote:
On 09/06/2015 15:17, Sergey Beryozkin wrote:
Hi Francesco
See https://issues.apache.org/jira/browse/CXF-6447,
So you'd be able to optimize the signature if still preferred, the
server code would stay completely portable, though only CXF proxies
would likely to work with such signatures in the short term at least
Wow, cool stuff :-)
I'll check with CXF 3.1.2-SNAPSHOT and let you know how it goes.
I confirm it works like a charm; at first I had troubles because I was
using
@PUT
@Path("{key}")
void update(@BeanParam ResourceTO bean);
but then I checked again and changed to
@PUT
@Path("{key}")
void update(ResourceTO bean);
Thanks again.
Regards.
On 08/06/15 10:43, Sergey Beryozkin wrote:
Sorry, that will not work with the proxies as they won't be able to
resolve the {key} :-), with webclients only...
I wonder if we can explore your idea on the client side and try to
resolve a variable if the body bean is available...I'll try to
experiment a bit later on
Thanks, Sergey
On 08/06/15 10:40, Sergey Beryozkin wrote:
Hi Francesco,
By the way, it is fine to have something like this:
@PUT
@Path("{key}")
public void update(ResourceTo bean) {}
That can actually be the optimal signature, if the bean contains
the key
then it can be taken from the bean and if not - then from UriInfo by
analyzing the path value. Often a Path variable is also represented
with PathParam but it is not a requirement
Cheers, Sergey
On 08/06/15 10:32, Francesco Chicchiriccò wrote:
Hi Sergey,
thanks for your response.
On 08/06/2015 11:16, Sergey Beryozkin wrote:
Hi Francesco
Sure, you can try:
@PUT
@Consumes({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON })
void update(@NotNull ResourceTO resourceTO);
Omitting the extra @Path completely and getting the key out of
ResourceTo bean:
PUT /resources
<Resource>
<key>1</key>
<!- the rest of the representation -->
</Resource>
given that the key is available there.
That said, if we were to abstract away from the the redundant proxy
code where the key is specified twice during the invocation, one can
say PUT targets an individual resource representation which is
indeed
identified as /resources/{key}. Optimizing the {key} away would lead
to a slightly unbalanced space:
// GET the 1st resource
GET /resources/1
// Update the 1st resource
PUT /resources
(the representation with the key)
My opinion has always been that ultimately the more practical it is
the better as opposed to the purer the better. It might be
reasonable
to support both styles:
PUT /resources/1
POST /resources
as POST is usually deals with the collection of resources and I
guess
it may be reasonable to suggest that POSTing to a collection which
already contains an element with the same key means the actual
update.
I'd agree to keep
PUT /resources/1
which definitely makes sense; I thought there was some "magic" JAX-RS
annotation to identify an argument as request body so that I could
write
@PUT
@Path("{key}")
@Consumes({ MediaType.APPLICATION_XML,
MediaType.APPLICATION_JSON })
void update(@BeanParam @RequestBody ResourceTO resourceTO);
Given the considerations above, I'd say we'll probably leave things
unchanged.
Regards.
On 08/06/15 07:05, Francesco Chicchiriccò wrote:
Hi,
we have several "update" methods in our JAX-RS services, with
similar
signature:
@PUT
@Path("{key}")
@Consumes({ MediaType.APPLICATION_XML,
MediaType.APPLICATION_JSON })
void update(@NotNull @PathParam("key") String key, @NotNull
ResourceTO resourceTO);
For various reasons, the key value is already contained in the
ResourceTO bean; this leads to kind of redundant invocations
like as
resourceService.update(resourceTO.getKey(), resourceTO);
I was wondering whether this situation can be improved by using
@BeanParam:
void update(@BeanParam ResourceTO resourceTO);
by annotating ResourceTO#setKey() with @Path("{key}").
It seems that with such setup only "key" is evaluated, e.g. the
rest of
ResourceTO instance is left empty.
Am I missing something? Any suggestion to fix the original problem?
Thanks for your support.
Regards.
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
