On 13/12/12 17:08, Ivan.Latysh wrote:
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.
No - the spec requires a preference be given to mappers typed on more
specific scopes.
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.
Not possible - simply register a custom mapper if you need to handle WAE
exceptions differently.
The only issue for me at the moment is how to make it less tedious to
get custom WAE mappers registered globally, say via the bus.
Sergey
--
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.
