Thanks. The immediate cause was a stupid mistake of mine, but it's good to know about this.
On Thu, Aug 27, 2015 at 12:55 PM, Sergey Beryozkin <[email protected]> wrote: > One thing that did change in CXF 3.1.2 is now documented here: > > https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS#JAX-RS-CXF3.1.2ProviderSortingChanges > > (just did a minor update to refer to exception mappers too). > > We discussed it at length with Romain but basically up until 3.1.2 CXF was > not entirely compliant with respect to sorting custom and the default > providers which was highlighted by a number of CXF JIRAs relayed to 2.0 TCK > tests. > > That mostly affects some wildcard custom MBR or MBW. > > CXF ships a default WebApplicationExceptionMapper only so I've no idea, > without seeing how your GenericExceptionMapper is implemented why you you > are seeing side-effects. I have probably 10 various Generic mapper > variations in tests and it all works. If they did not catch something then > well we need to fix it, right ? > > Can you paste the GenericExceptionMapper signature here ? > > And what was the other old code that stopped working, can you remind me > please ? > > Sergey > > > > > On 27/08/15 17:21, Benson Margulies wrote: >> >> This is another example of code that worked fine in an older version >> and changes in behavior in 3.1.2. >> >> On Thu, Aug 27, 2015 at 12:00 PM, Benson Margulies <[email protected]> >> wrote: >>> >>> Has the process of installing an exception mapper changed? My mappers >>> aren't being invoked. >>> >>> sf.setProvider(new JacksonJaxbJsonProvider(JsonUtils.getObjectMapper(), >>> JacksonJaxbJsonProvider.DEFAULT_ANNOTATIONS)); >>> sf.setProvider(new JsonExceptionMapper()); >>> sf.setProvider(new WebApplicationExceptionMapper()); >>> sf.setProvider(new GenericExceptionMapper()); > >
