On 15/10/14 12:04, shisholik wrote:
I switched to CXF 3.0.1 and ParamConverterProvider works fine with simple
parameters. But how work with more complex structures? For example:
public class UpdateNotificationsResource implements NotificationResource {
private Boolean changes;
private Boolean news;
@Override
public Boolean getChanges() {
return changes;
}
@Override
public void setChanges(Boolean changes) {
this.changes = changes;
}
@Override
public Boolean getNews() {
return news;
}
@Override
public void setNews(Boolean news) {
this.news = news;
}
}
@Path("/notifications")
@PUT
public SuccessResult updateNotification(@QueryParam("")
UpdateNotificationsResource notifications) {
...
}
PUT /notifications?changes=qwe
In this case BooleanConverterProvider receives only @QueryParam("")
annotation and I can't get more information. I thought that I can set
annotation on a getter, but no, it doesn't work.
You'd need to use JAX-RS 2.0 @BeanParam:
@PUT
public SuccessResult updateNotification(@BeanParam
UpdateNotificationsResource notifications)
and have individual UpdateNotificationsResource setters annotated with
QueryParam
Sergey
2014-10-15 16:09 GMT+06:00 Sergey Beryozkin [via CXF] <
[email protected]>:
On 15/10/14 07:19, shisholik wrote:
Thank you so much for your answer! I will switch to CXF 3.0.1 and try
ParamConverterProvider with Boolean, Integer and Enums.
I think no need to create a specific exception for integers.
I was not suggesting to an exception for the integer specific format
issues, but rather to have an exception which one would be able to check
in JAX-RS ExceptionMapper and extract the name of the parameter which
caused the exception. However it would make the mapper code
non-portable, so I guess I'd just drop this idea.
Yes, using ParamConverterProvider would be the right way to go. FYI it
is supported in CXF 2.7.13 too, but if you can then migrating to 3.0.2
(just released) would be a better move
Maybe better
way will be is make exception for deserialization errors.
These are captured as WebApplicationException cause and can be analyzed
in the exception mappers
Sergey
--
View this message in context:
http://cxf.547215.n5.nabble.com/Getting-parameter-name-from-exception-tp5749870p5749901.html
Sent from the cxf-user mailing list archive at Nabble.com.
------------------------------
If you reply to this email, your message will be added to the discussion
below:
http://cxf.547215.n5.nabble.com/Getting-parameter-name-from-exception-tp5749870p5749906.html
To unsubscribe from Getting parameter name from exception, click here
<http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5749870&code=c2VyZ2V5QHNoaXNob2xpay5jb218NTc0OTg3MHwtNDUzMzU0MzMw>
.
NAML
<http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
