[
https://issues.apache.org/jira/browse/SQOOP-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14379991#comment-14379991
]
Jarek Jarcec Cecho commented on SQOOP-2266:
-------------------------------------------
Thanks for creating this follow up JIRA [~richard_zhou]. Very nice summary!
I've introduced the exception propagation from server to client couple of years
back as a way to show user what went wrong on the server. It was merely a
better debugging tool then a real part of the protocol where users of the API
could depend on the error codes to perform certain actions. I do see the use
case of good error propagation, so I agree that we should do something about
that.
I do not feel that the {{ErrorCodes}} are the best way to achieve this though.
The way we've designed {{SqoopException}} and the {{ErrorCode}} is to easily
add/change additional error codes to see what exactly and where went wrong in
the code. By design Sqoop is highly pluggable (almost every part is a plugin)
and we are expecting that users will take advantage of this pluggability - if
nothing else, I'm fully expecting that users will be dumping in new third party
connectors that will certainly bring their own {{ErrorCode}} classes that won't
be known to our client.
As we can't guarantee that client will always have all {{ErrorCodes}}
available, I'm thinking that the better solution is to make a parallel system
to the current one. We can define some common errors in the protocol itself
(whatever way we see fit), but in addition to that we should allow unknown
{{ErrorCodes}} to be sent across the wire as well. I'm wondering what others
think about it?
> Sqoop2: Solution of communication between client and server about ErrorCode
> ---------------------------------------------------------------------------
>
> Key: SQOOP-2266
> URL: https://issues.apache.org/jira/browse/SQOOP-2266
> Project: Sqoop
> Issue Type: Bug
> Components: sqoop2-client
> Affects Versions: 1.99.5
> Reporter: Richard
> Fix For: 2.0.0
>
>
> When the client receives the response with throwable bean from the server, it
> will try to reflect the exception class. However, if the {{ErrorCode}} class
> is in {{sqoop-core}} or other module instead of {{sqoop-common}}, {{NPE}}
> will be throw (SQOOP-2054). So [~abec] and me moved all {{ErrorCode}} to
> {{sqoop-core}} (SQOOP-2054, SQOOP-2172). Several time passed, on the other
> hand, [~jarcec] fixed {{NPE}} with avoid throwing exception (SQOOP-2225), and
> then moved several {{ErrorCode}} back to their own modules (SQOOP-2248,
> SQOOP-2249, SQOOP-2251 and SQOOP-2247). But this solution does not solve the
> problem that client could not reflect the exception class from server, which
> is needed in {{Authorization}} part. (The client need to identify the
> exception type to decide which message should be shown in the CLI).
> This JIRA is to address this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
