覆盖 CXF 错误处理 [英] Override CXF error handling

问题描述

我正在开发一些基于 Web 服务的应用程序，我有一个关于 Apache CXF 解组的问题.在我们的项目中，我们使用 CXF 2.4.1 版本.

I am working on some web-services based application and I have a question about Apache CXF unmarshalling. In our project we use CXF 2.4.1 version.

当某些 SOAP 请求不正确(例如，某些字段是文本而不是数字)时，CXF 会抛出标准的 SOAPFaultException 并且 SOAP 响应是使用标准字段构建的，例如:

When some SOAP request is incorrect (e.g. some field is text instead of numeric) CXF throws standard SOAPFaultException and SOAP response is built up with standard fields like:

<soap:Fault>
    <faultcode>soap:Client</faultcode>
    <faultstring>Unmarshalling Error: some field missing</faultstring>
</soap:Fault>

项目需求说，如果出现任何故障系统需要以其他格式响应，例如:

Project requirements says that in case of any fault system need to respond in other format, like:

<soap:body>
    <ResponseState>
        <ErrorCode>2732</ErrorCode>
        <ErrorMessage>Unmarshalling Error: some field missing</ErrorMessage>
        <ErrorDetails> some details </ErrorDetails>
        <some other fields>
        ...
    </ResponseState>
</soap:body>

所以问题是:如何以某种方式覆盖此错误处理并以我的格式而不是默认格式进行响应?

So the question is: how can I override somehow this error handling and respond in my format, not default?

提前致谢.

附言我试图研究一些 ValidationEventHandler 主体，但它在 CXF 2.0 及更高版本中以其他方式工作.

P.S. I tried to look into some ValidationEventHandler principals, but it works in some other way in CXF 2.0 and higher.

推荐答案

好的，经过大量研究，我找到了一些处理 CXF 错误的方法.

OK, So after lot of research I've found some ways of CXF error handling.

*.ValidationEventHandler 使您可以抛出自己的异常而不是标准异常.但是您无法更改响应行为，也无法更改 SOAP 响应格式.

*. ValidationEventHandler gives you possibility to throw your own exception instead of standard one. BUT you can't change responding behavior and you can't change SOAP response format.

*.另一种改变错误处理的方法是创建你自己的拦截器.CXF 工作流建立在拦截器链上.拦截器有 4 种类型:inInterceptor、outInterceptor、inFaultInterceptor 和 outFaultInterceptor.

*. Another way to alter error handling is to create your own interceptor. CXF workflow is built on chain of interceptors. There's 4 type of interceptors: inInterceptor, outInterceptor, inFaultInterceptor and outFaultInterceptor.

使用一些聪明的技巧，您可以通过创建自己的拦截器(将其添加到链中)来更改工作流程，并从链中删除标准拦截器(如果您知道它的类名).所以你实际上可以做任何你需要的事情.

Using some smart hacks you can change workflow through creating your own interceptor (with adding it to chain), and remove standard interceptor from chain (if you know it's class name). So you can actually do anything you need.

但就所有这些拦截器手动编组响应(xmlWriter.writeStartElement() 等)而言，为每个流程阶段编写自己的拦截器可能是一个巨大的挑战.这可能需要大量的工作.

BUT as far as all these interceptors marshall response manually (xmlWriter.writeStartElement() etc) it could be a great challenge to write your own interceptors for each flow phase. It could be real huge bunch of work.

很遗憾，我还没有找到关于 CXF 拦截器的好的参考资料.

Unfortunately, I haven't found good reference about CXF interceptors.

另一件事 - 如果您需要返回常规响应而不是 SOAPFaultException，您可能需要其他信息，例如:返回此响应的实际服务、请求中传递的服务参数等.我没有在拦截器的可访问参数中找到此信息.而且，当然，通过这样做，您欺骗了将返回 OK 而不是真正的异常的客户端代码.

Another thing - if you need to return regular response instead of SOAPFaultException you may need additional information like: actual service that return this response, service parameters passed in request etc. I haven't found this info in accessible parameters in interceptors. And, surely, by doing so you cheat client code that will return OK instead of real exception.

*.使用所有参数作为文本设计 wsdl 可能不是很好的解决方案:

*. Designing your wsdl's with all params as text may be very not very good solution:

一个.如果 wsdl 中没有数据类型和验证规则，您的服务的使用者可能真的会感到困惑.

a. Consumer of your services may be really confused if no data types and validation rules in wsdl.

B.您需要重新发明轮子"进行验证.我的意思是你需要编写自己的验证器，这对于一些复杂的规则来说可能非常困难.同时，XSD 已实施所有这些验证并经过良好测试.

b. You'll need to 'reinvent the wheel' for validation. I mean that you'll need to code your own validator that could be very difficult with some complicated rules. At the same time XSD has all of this validations implemented and good tested.

最后关于我的情况:我们与需求经理讨论了这个问题，并决定允许 CXF 在请求中违反 XML 模式要求时抛出它自己的标准异常.这是一个很好的解决方案，因为现在我们正在使用 XSD 验证的所有功能，不要将时间浪费在复杂和无用的工作上.

And finally about my situation: we discussed it with requirement manager and decided to allow CXF throw it's own standard exceptions if XML schema requirements violated in request. It's good solution because now we are using all the power of XSD validation and don't waste our time on complicated and useless work.

非常感谢@ericacm 的回答.

Great thanks to @ericacm for answer.

这篇关于覆盖 CXF 错误处理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！