You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sqoop.apache.org by Jarek Cecho <ja...@apache.org> on 2016/02/06 00:21:25 UTC

Review Request 43273: SQOOP-2823: Sqoop2: RESTiliency: Remove repetitive try-catch block for accessing POST and PUT request

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/43273/
-----------------------------------------------------------

Review request for Sqoop and Jarek Cecho.


Bugs: SQOOP-2823
    https://issues.apache.org/jira/browse/SQOOP-2823


Repository: sqoop-sqoop2


Description
-------

I've noticed that we have quite a few repetition of code like this one:

{code}
     RoleBean bean = new RoleBean();

    try {
      JSONObject json = JSONUtils.parse(ctx.getRequest().getReader());
      bean.restore(json);
    } catch (IOException e) {
      throw new SqoopException(ServerError.SERVER_0003, "Can't read request content", e);
    }
{code}

It's relatively a lot of code just because {{ctx.getRequest()}} can throw an exception. I would like to propose to create a method in our {{ctx}} wrapper to provide the {{getReader}} method without any exception, which will simplify the code to:

{code}
    bean.restore(JSONUtils.parse(ctx.getReader()));
{code}

We'll of course throw an exception on failure - but using our {{SqoopException}} mechanism.


Diffs
-----

  server/src/main/java/org/apache/sqoop/handler/AuthorizationRequestHandler.java 6cd77e9 
  server/src/main/java/org/apache/sqoop/handler/JobRequestHandler.java 9dfcb0b 
  server/src/main/java/org/apache/sqoop/handler/LinkRequestHandler.java 7d7f1de 
  server/src/main/java/org/apache/sqoop/server/RequestContext.java 2beac2b 

Diff: https://reviews.apache.org/r/43273/diff/


Testing
-------


Thanks,

Jarek Cecho


Re: Review Request 43273: SQOOP-2823: Sqoop2: RESTiliency: Remove repetitive try-catch block for accessing POST and PUT request

Posted by Abraham Fine <ab...@abrahamfine.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/43273/#review118258
-----------------------------------------------------------


Ship it!




Ship It!

- Abraham Fine


On Feb. 5, 2016, 11:21 p.m., Jarek Cecho wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43273/
> -----------------------------------------------------------
> 
> (Updated Feb. 5, 2016, 11:21 p.m.)
> 
> 
> Review request for Sqoop and Jarek Cecho.
> 
> 
> Bugs: SQOOP-2823
>     https://issues.apache.org/jira/browse/SQOOP-2823
> 
> 
> Repository: sqoop-sqoop2
> 
> 
> Description
> -------
> 
> I've noticed that we have quite a few repetition of code like this one:
> 
> {code}
>      RoleBean bean = new RoleBean();
> 
>     try {
>       JSONObject json = JSONUtils.parse(ctx.getRequest().getReader());
>       bean.restore(json);
>     } catch (IOException e) {
>       throw new SqoopException(ServerError.SERVER_0003, "Can't read request content", e);
>     }
> {code}
> 
> It's relatively a lot of code just because {{ctx.getRequest()}} can throw an exception. I would like to propose to create a method in our {{ctx}} wrapper to provide the {{getReader}} method without any exception, which will simplify the code to:
> 
> {code}
>     bean.restore(JSONUtils.parse(ctx.getReader()));
> {code}
> 
> We'll of course throw an exception on failure - but using our {{SqoopException}} mechanism.
> 
> 
> Diffs
> -----
> 
>   server/src/main/java/org/apache/sqoop/handler/AuthorizationRequestHandler.java 6cd77e9 
>   server/src/main/java/org/apache/sqoop/handler/JobRequestHandler.java 9dfcb0b 
>   server/src/main/java/org/apache/sqoop/handler/LinkRequestHandler.java 7d7f1de 
>   server/src/main/java/org/apache/sqoop/server/RequestContext.java 2beac2b 
> 
> Diff: https://reviews.apache.org/r/43273/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Jarek Cecho
> 
>