On 13/12/12 17:48, Sergey Beryozkin wrote:
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.
Please see
https://cwiki.apache.org/confluence/display/CXF20DOC/JAXRS+Services+Configuration#JAXRSServicesConfiguration-Sharingprovidersbetweenmultipleendpoints
This will be available in CXF 2.6.5/2.7.2
I think it can be quite handy to get the providers registered on the bus
and shared across all the endpoints to which this bus is related;
Right now it is somewhat limited is that only single (bus-) global
exception mapper, MBR or MBW can be registered per bus - going forward
it will be possible to register all the providers on the bus, I'll just
need to come up with some convention on how a single property can
identify a collection of exception mappers, or message body readers,
etc, - this is not critical right now though.
Thanks, Sergey
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.
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
