Guys... it looks like there is a bug in ProviderFactory$ClassComparator. Given two mappers it always ends up comparing them as if both mappers were ExceptionMapper<Throwable>. There must be a problem in the way the interfaces and "actual types" are derived (which is done in the InjectionUtils class).
-Mike On Tue, Oct 21, 2014 at 1:24 PM, Lambert, Michael < [email protected]> wrote: > Hello gentleman! > > My impression was that when implementing ExceptionMapper that the mapper > of the nearest superclass of an exception would be used if an exact > exceptionmapper match to the exception didnt exist. > > For example if I created a FooException which extended BarException I > would only have to create a BarExceptionMapper to catch and map both types > of exceptions; the BarExceptionMapper would be used when a FooException was > thrown. > > The red hat docs seem to reinforce this opinion: > > > - > > When any exception other than a WebApplicationException exception, or > one of its subclasses, is thrown, the runtime will check for an appropriate > exception mapper. An exception mapper is selected if it handles the > specific exception thrown. If there is not an exception mapper for the > specific exception that was thrown, the exception mapper for the nearest > superclass of the exception is selected. > > > > https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.1/html/Apache_CXF_Development_Guide/files/RESTExceptionMapper.html > > The reality is different for us however. In fact, if we create a custom > WebApplicationExceptionMapper ClientErrorExceptions are not caught by the > mapper. CXF seems to default to attempt to use whichever Mapper is the > first one we registered (e.g. if we defined a FooExceptionMapper and > registered it, CXF would attempt to use that and throw an error rather than > try to use the WebApplicationExceptionMapper). > > Can someone tell me what the expected behavior is? Is my question clear? > > We are using CXF version 2.7.11. > > Thanks! > > Mike >
