Yeah, I was a little surprised that manipulating the MessageContentsList
directly didn't confuse the underlying layers. Seemed like I might have
been potentially "pulling the rug out from underneath" the lower layers.
Glad it worked.
As for the validation sequence, although it seems as though
Thanks.
By the way, I wonder if the fix in CXF will need to be different after
all. See the JAXRS out interceptor validates the JAX-RS *method
response*, and if the validation fails and the custom Response is
created and the out chain is run again, the out validating interceptor
now still
Slight mod to what you have:
JAXRSUtils.getCurrentMessage().setContent(List.class, new
MessageContentsList(resp));
Using the "put" method did not work but the above code works just fine and I
was able to see the original outbound violations in an error response.
Thanks.
--
View this message
Right, in that case please try JAXRSBeanvalidationInvoker, or, may be
even better, try to add this line in your exception mapper:
JAXRSUtils.getCurrentMessage().put(List.class, new
MessageContentsList(newResponse));
You will be able to remove this line once CXF-7091 gets resolved
Thanks,
Tried the BeanValidationInInterceptor and BeanValidationOutInterceptor with
the the Out interceptor configured like this:
BeanValidationOutInterceptor bean = new BeanValidationOutInterceptor();
bean.setProvider(new BeanValidationProvider(new
HibernateBeanValidationProviderResolver()));
Or try JAXRSBeanValidationInvoker (register it with jaxrs:invoker)
Sergey
On 14/10/16 22:17, Sergey Beryozkin wrote:
Hi
See
https://issues.apache.org/jira/browse/CXF-7091
We are voting for a 3.1.8 release right now, so I can only guess at this
stage that 3.1.9 will be out by the end of Dec or
Hi
See
https://issues.apache.org/jira/browse/CXF-7091
We are voting for a 3.1.8 release right now, so I can only guess at this
stage that 3.1.9 will be out by the end of Dec or early January.
Please try CXF interceptors in meantime
Cheers, Sergey
On 14/10/16 21:59, tomstark wrote:
Hi
Hi Sergey,
Thanks for the info. I'll try your suggestion.
Do you have a time frame for when 3.1.9 would be released? Also, can you
reply with the bug number so I can track it? Depending on timing, I may
have to wait to pick up the fix until our next release.
Thanks.
--
View this message
Hi
Yes, the response filters are expected to be run again after an
exception has been mapped. The fact that the abstract CXF filter sees
the original value on the 2nd run is a bug, in most case the default
mapper which only creates an HTTP error is sufficient. So I guess this
is why this
