Re: [Discuss][SAGA] MicroProfile LRA
There is a pdf file for the LRA specification [1] for reviewing. [1] https://github.com/eclipse/microprofile-lra/files/2546285/microprofile-lra-spec.pdf Zheng Feng 于2018年11月2日周五 上午9:30写道： > Well, it is a good idea and I will try my best to compare two of them. > > Willem Jiang 于2018年11月1日周四 下午5:14写道： > >> Hi Zheng >> >> Thanks for the information. As you know the specification has lots of >> information. >> Could you break down it into smaller section and we could do some >> comparison with current Saga implementation? >> For example, the LRA is based on the Restful Service and the >> Transaction ID is passed through the HTTP headers. The LRA Client API >> is much like our Omega API, but we don't expose much of the detail >> from the client side. >> >> Currently we are thinking about to do some enhancement on the Saga >> protocol by helping user to release the lock once the Saga transaction >> is finished[1]. I think we may contribute this use case back to the >> lra specification by starting the discussion first. >> >> [1]https://issues.apache.org/jira/browse/SCB-1006 >> >> Willem Jiang >> >> Twitter: willemjiang >> Weibo: 姜宁willem >> On Thu, Nov 1, 2018 at 3:56 PM Zheng Feng wrote: >> > >> > Hi all, >> > >> > I think we need to have the eyes on this specification. The LRA (Long >> > Running Action) [1] tries to introduce some Saga like APIs in the micro >> > services. These are similar to our omega and alpha APIs currently. Now >> they >> > are going to ask the community for some input [2], and I think we can >> > contribute some ideas from our side especially with the coordinate >> service >> > design. >> > >> > Thanks, >> > Zheng Feng >> > >> > [1] https://github.com/eclipse/microprofile-lra >> > [2] https://groups.google.com/forum/#!topic/microprofile/vWM0eXE8gYc >> >
?????? [Discuss][JavaChassis] about customization ofvertxorg.apache.servicecomb.transport.rest.vertx.RestBodyHandler
Yes you are right. My understanding is that "the request method XXX is not allowed in upload", so that it can be used. We are thinking about PR to vert.x, maybe we can create a PR for them to review. -- -- ??: "yhs0092"; : 2018??11??5??(??) 10:21 ??: "dev@servicecomb.apache.org"; : Re: [Discuss][JavaChassis] about customization ofvertxorg.apache.servicecomb.transport.rest.vertx.RestBodyHandler Hi @bi...@qq.com , I've searched for the descriptions about HTTP status 405, but the description[1] seems to indicate that this status is for those cases that request method is wrong, e.g. the request method is GET but the server only accept POST. So is it proper to use 405 in this scenario? If there is no proper HTTP status, maybe we can use 500? And I've create a task[2] to track this issue. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/405 [2] https://issues.apache.org/jira/browse/SCB-1010 Yours sincerely Yao Haishi yhs0...@163.com On 11/5/2018 20:24??bismy wrote?? Maybe we can send a 405 Method Not Allowed message. -- -- ??: "yhs0092"; : 2018??11??1??(??) 8:56 ??: "dev@servicecomb.apache.org"; : Re: [Discuss][JavaChassis] about customization of vertxorg.apache.servicecomb.transport.rest.vertx.RestBodyHandler Hi, I've tried to remove ServiceComb exceptions from RestBodyHandler today. Technically, it is feasible. In my test, I replace the ServiceComb exceptions with IllegalArgumentException in the case that upload directory is not specified and replace with 413 status code in the case that uploaded file is too large. In GlobalRestFailureHandler I recognize the exception and status code and then return corresponding response. This solution seems working well, but there are still some details need to be discussed. The first one is whether it's proper to use IllegalArgumentException in this situation. I use it because I cannot find other Exception more accurately express the meaning "upload directory is not specified". The other one is that the logic to convert the exceptions into error response is set in GlobalRestFailureHandler. It seems not elegant, but I still don't find any better solution. Yours sincerely Yao Haishi yhs0...@163.com On 10/31/2018 17:54??yhs0092 wrote?? Hi, one of the JavaChassis exception wrapped in RestBodyHandler is added by me. I will try to remove the JavaChassis exceptions in RestBodyHandler and see whether it can works well. Yours sincerely Yao Haishi yhs0...@163.com On 10/31/2018 09:00??wjm wjm wrote?? currently we customized org.apache.servicecomb.transport.rest.vertx.RestBodyHandler 1.disable upload feature when uploadDir is null, this is a general requirement 2.wrap some exceptions to JavaChassis exception?? this is not a general requirement if there is only customization 1, maybe we can try to raise a PR to vertx otherwise we always forget to merge latest vertx logic to our code. maybe we can confirm if customization 2 is necessary.
Re: [Discuss][JavaChassis] about customization of vertxorg.apache.servicecomb.transport.rest.vertx.RestBodyHandler
Hi @bi...@qq.com , I've searched for the descriptions about HTTP status 405, but the description[1] seems to indicate that this status is for those cases that request method is wrong, e.g. the request method is GET but the server only accept POST. So is it proper to use 405 in this scenario? If there is no proper HTTP status, maybe we can use 500? And I've create a task[2] to track this issue. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/405 [2] https://issues.apache.org/jira/browse/SCB-1010 Yours sincerely Yao Haishi yhs0...@163.com On 11/5/2018 20:24??bismy wrote?? Maybe we can send a 405 Method Not Allowed message. -- -- ??: "yhs0092"; : 2018??11??1??(??) 8:56 ??: "dev@servicecomb.apache.org"; : Re: [Discuss][JavaChassis] about customization of vertxorg.apache.servicecomb.transport.rest.vertx.RestBodyHandler Hi, I've tried to remove ServiceComb exceptions from RestBodyHandler today. Technically, it is feasible. In my test, I replace the ServiceComb exceptions with IllegalArgumentException in the case that upload directory is not specified and replace with 413 status code in the case that uploaded file is too large. In GlobalRestFailureHandler I recognize the exception and status code and then return corresponding response. This solution seems working well, but there are still some details need to be discussed. The first one is whether it's proper to use IllegalArgumentException in this situation. I use it because I cannot find other Exception more accurately express the meaning "upload directory is not specified". The other one is that the logic to convert the exceptions into error response is set in GlobalRestFailureHandler. It seems not elegant, but I still don't find any better solution. Yours sincerely Yao Haishi yhs0...@163.com On 10/31/2018 17:54??yhs0092 wrote?? Hi, one of the JavaChassis exception wrapped in RestBodyHandler is added by me. I will try to remove the JavaChassis exceptions in RestBodyHandler and see whether it can works well. Yours sincerely Yao Haishi yhs0...@163.com On 10/31/2018 09:00??wjm wjm wrote?? currently we customized org.apache.servicecomb.transport.rest.vertx.RestBodyHandler 1.disable upload feature when uploadDir is null, this is a general requirement 2.wrap some exceptions to JavaChassis exception?? this is not a general requirement if there is only customization 1, maybe we can try to raise a PR to vertx otherwise we always forget to merge latest vertx logic to our code. maybe we can confirm if customization 2 is necessary.
?????? [Discuss][JavaChassis] about customization of vertxorg.apache.servicecomb.transport.rest.vertx.RestBodyHandler
Maybe we can send a 405 Method Not Allowed message. -- -- ??: "yhs0092"; : 2018??11??1??(??) 8:56 ??: "dev@servicecomb.apache.org"; : Re: [Discuss][JavaChassis] about customization of vertxorg.apache.servicecomb.transport.rest.vertx.RestBodyHandler Hi, I've tried to remove ServiceComb exceptions from RestBodyHandler today. Technically, it is feasible. In my test, I replace the ServiceComb exceptions with IllegalArgumentException in the case that upload directory is not specified and replace with 413 status code in the case that uploaded file is too large. In GlobalRestFailureHandler I recognize the exception and status code and then return corresponding response. This solution seems working well, but there are still some details need to be discussed. The first one is whether it's proper to use IllegalArgumentException in this situation. I use it because I cannot find other Exception more accurately express the meaning "upload directory is not specified". The other one is that the logic to convert the exceptions into error response is set in GlobalRestFailureHandler. It seems not elegant, but I still don't find any better solution. Yours sincerely Yao Haishi yhs0...@163.com On 10/31/2018 17:54??yhs0092 wrote?? Hi, one of the JavaChassis exception wrapped in RestBodyHandler is added by me. I will try to remove the JavaChassis exceptions in RestBodyHandler and see whether it can works well. Yours sincerely Yao Haishi yhs0...@163.com On 10/31/2018 09:00??wjm wjm wrote?? currently we customized org.apache.servicecomb.transport.rest.vertx.RestBodyHandler 1.disable upload feature when uploadDir is null, this is a general requirement 2.wrap some exceptions to JavaChassis exception?? this is not a general requirement if there is only customization 1, maybe we can try to raise a PR to vertx otherwise we always forget to merge latest vertx logic to our code. maybe we can confirm if customization 2 is necessary.
