I submit a PR here: https://github.com/apache/incubator-servicecomb-java-chassis/pull/827
I tried one solution, this solution violates the constraints that when Response is failed state the result content should be Throwable. wjm have add some suggestions and I will try that. ------------------ ???????? ------------------ ??????: "willem.jiang"<[email protected]>; ????????: 2018??7??20??(??????) ????2:58 ??????: "dev"<[email protected]>; ????: Re: Regarding to java-chassis Resonse is failed logic OK , after read the question twice, I got your point. If you proposal two different solution?? you may need to compare these two solutions. Willem Jiang Twitter: willemjiang Weibo: ????willem On Fri, Jul 20, 2018 at 11:55 AM, bismy <[email protected]> wrote: > Sorry, your reply is not related to my problem. > For your problem, java-chassis have same mechanism, ExceptionConverter is > supported. > > > My problem related to internal error processing and I think it's a bug, > but the solution may have two ways. I'll create a PR for this to better > understand this problem. > > > ------------------ ???????? ------------------ > ??????: "willem.jiang"<[email protected]>; > ????????: 2018??7??20??(??????) ????11:46 > ??????: "dev"<[email protected]>; > > ????: Re: Regarding to java-chassis Resonse is failed logic > > > > It could cause some security issue if we just through the exception back to > the client. > In JAXRS there are exception mapping mechanism[1], maybe we can consider > add this kind of feature here. > > [1]https://docs.oracle.com/javaee/7/api/javax/ws/rs/ext/ > ExceptionMapper.html > > > Willem Jiang > > Twitter: willemjiang > Weibo: ????willem > > On Fri, Jul 20, 2018 at 11:41 AM, bismy <[email protected]> wrote: > > > Currently we support the following interface definition, but there are > > some problem in handler. When error code is 400 or 500, handler taking > this > > error code as error, and will throw exception. For example using > bizkeeper > > handler we have this code. This code will give a cast case exeception > since > > result is not Throwable. > > > > > > Any suggestions for this scenario? Change bizkeeper code to check if > > result if Throwable or change our logic to taking when Resonse.isFailed > to > > be true? > > > > > > --bizkeeper code: > > if (isFailedResponse(resp)) { > > // e should implements toString > > LOG.warn("bizkeeper command {} failed due to {}", invocation. > > getInvocationQualifiedName(), > > resp.getResult()); > > f.onError(resp.getResult()); > > FallbackPolicyManager.record(type, invocation, resp, false); > > } > > > > > > > > ---service definition: > > @Path("/usingCSEResponse2") > > @POST > > @ApiResponses({ > > @ApiResponse(code = 200, response = MultiResponse200.class, > > message = ""), > > @ApiResponse(code = 400, response = MultiResponse400.class, > > message = ""), > > @ApiResponse(code = 500, response = MultiResponse500.class, > > message = "")}) > > @ResponseHeaders({@ResponseHeader(name = "x-code", response = > > String.class)}) > > public Response usingCSEResponse2(MultiRequest request) { > > Response response = new Response(); > > if (request.getCode() == 400) { > > MultiResponse400 r = new MultiResponse400(); > > r.setName("400"); > > response.setStatus(javax.ws.rs.core.Response.Status.BAD_ > > REQUEST); > > response.setResult(r); > > response.getHeaders().addHeader("x-code", "400"); > > > > > > } else if (request.getCode() == 500) { > > MultiResponse500 r = new MultiResponse500(); > > r.setName("500"); > > response.setStatus(javax.ws.rs.core.Response.Status.BAD_ > > REQUEST); > > response.setResult(r); > > response.getHeaders().addHeader("x-code", "500"); > > } else { > > MultiResponse200 r = new MultiResponse200(); > > r.setName("200"); > > response.setStatus(javax.ws.rs.core.Response.Status.BAD_ > > REQUEST); > > response.setResult(r); > > response.getHeaders().addHeader("x-code", "200"); > > } > > return response; > > } >
