Sergey Beryozkin-5 wrote
> First the default mapper is there to be overridden (as I said - register 
> it as jaxrs:provider), and if it were not there then WAEs would escape 
> completely and the users would be forced to use out fault interceptors 
> and manually serialize the errors...
> 
> ...
> 
>> And as before I can not register custom ExceptionMapper for the bus.
>>
> 
> That is not possible because ExceptionMappers are not part of the CXF 
> interceptor model.
> 
> I see though the possible limitation with the fact that if you have a 
> simple exception mapper then you have to manually register which becomes 
> tedious if you have n+ number of endpoints.
> 
> Auto-discovery of the providers (something I've been postponing looking 
> into) will possibly help in simple cases. Also as I said before, I will 
> consider adding a utility fault out interceptor which will be able to 
> map the exceptions even with the help of exception mappers - I'll keep 
> you up to date on this one

That is the problem, I have multiple jaxrs:server across multiple modules,
so I need a unified exception trap. I can not rely on every jaxrs:server to
have an ExceptionMapper.
I can register it on the shared factory


But than "ExceptionMapperComparator" class in "ProviderFactory" always
select the default one.

*Is it possible to update ClassComparator.compareClasses(Object o1, Object
o2):*
from:


to:


to give preference to a broader mapper.


Sergey Beryozkin-5 wrote
> Now, please explain what is being stripped by the default mapper, what 
> were you expecting that is not possible now (with the default mapper) ?
> ...
> If not and if the mapper "addMessageToResponse" is set then the extra 
> info which is created by the default mapper will be reported.
> 
> This is optional because one may not always wants to report WAE details, 
> example, for the security reasons, or simply to get the faster 
> processing time, or to be very HTTP compliant - many HTTP errors are 
> actually expected to be returned with no extra payloads
> 
> So you can customize it - simple configure the default mapper explicitly 
> by setting "addMessageToResponse" to true or replace it by registering 
> your own custom provider

  I would expect that original exception with a cause to be available for an
entire chain. How it will rendered to the client is a totally different
issue.
  But at the moment WebApplicationExceptionMapper.toResponse() strip
exception and the best case provide a cause message.
  I would suggest to include entire exception stack to the response object,
and than on the render stage render only a message. This way every
interceptor has the full exception stack and can react appropriately.




--
View this message in context: 
http://cxf.547215.n5.nabble.com/Intercepting-exceptions-on-the-server-side-tp5719964p5720232.html
Sent from the cxf-user mailing list archive at Nabble.com.

Reply via email to