Yes, I was looking into the test and since your changes make the CXF interceptor to not be invoked the test doesn’t make much sense now.
The only situation when this is valid is if we want to have some kind of interceptor on a 404 and return something else. This might be a breaking change, since we don’t know how everyone else is developing their apps and we don’t know if someone is doing something similar :) I don’t see an easy answer on this one. Maybe lets just assume the break and see if someone complains :) They could always use a Filter to do the same thing. I’ll say to just comment the test for now and see how the build looks like. Thank you! Cheers, Roberto > On 12 Feb 2019, at 16:01, j4fm <[email protected]> wrote: > > Have a remaining test issue but not sure on it's validity. Would like to get > your thoughts on the JAX-RS NotFound test. > > arquillian\arquillian-tomee-tests\arquillian-tomee-jaxrs-tests\src\test\java\org\apache\openejb\arquillian\tests\jaxrs\notfound\NotFoundTest.java > > This test basically intercepts when CXF itself returns a 404 using a > customhandler (CXF out interceptor). > > Now with my enhancement the filter only invokes CXF if it's actually a valid > CXF resource. So CXF itself never gets to respond with a 404. > > This causes the test to fail because although a 404 is returned, it doesn't > come from CXF. It comes from the standard servlet. > > So while I think the test is still valid for testing for a 404, I think it's > implementation should be changed to be not tied to CXF itself. (My view > this is a good thing). > > This test is not really for testing CXF out interceptors... if it is it > should be split into it's own test and not based on a 404 error. > > Appreciate your input!? > > > > -- > Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
