[
https://issues.apache.org/jira/browse/THRIFT-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14380765#comment-14380765
]
Iker Jimenez edited comment on THRIFT-2157 at 3/25/15 9:04 PM:
---------------------------------------------------------------
[~dvdreddy] I guess it depends on how you are planning to change the code
generator :)
I tried to make it return a TException instead of TBase but that wouldn't be
correct either. The problem is with the call to
AsyncProcessFunction.sendResponse, which currently only takes a TBase.
In the current implementation all that is required is for the submitted object
to implement a write method. We have actually patched it that way ourselves
(make TApplicationException implement TBase but just provide an implementation
for the write method) until a permanent fix for this issue is released.
So, you would need:
1. Change code generator to not cast TApplicationException to TBase
2. Overload sendResponse to take also a TApplicationException (or a superclass)
3. Somewhere in the hierarchy of TApplicationException (probably on the same
class that you take in the overloaded sendResponse) implement at least a write
method.
High level this is how I see this other approach, which is not that different
from making TApplicationException implement TBase...
A bit unrelated, but would it make more sense for TException to implement TBase
instead of TApplicationException?
Iker.
was (Author: iker.jimenez):
[~dvdreddy]I guess it depends on how you are planning to change the code
generator :)
I tried to make it return a TException instead of TBase but that wouldn't be
correct either. The problem is with the call to
AsyncProcessFunction.sendResponse, which currently only takes a TBase.
In the current implementation all that is required is for the submitted object
to implement a write method. We have actually patched it that way ourselves
(make TApplicationException implement TBase but just provide an implementation
for the write method) until a permanent fix for this issue is released.
So, you would need:
1. Change code generator to not cast TApplicationException to TBase
2. Overload sendResponse to take also a TApplicationException (or a superclass)
3. Somewhere in the hierarchy of TApplicationException (probably on the same
class that you take in the overloaded sendResponse) implement at least a write
method.
High level this is how I see this other approach, which is not that different
from making TApplicationException implement TBase...
A bit unrelated, but would it make more sense for TException to implement TBase
instead of TApplicationException?
Iker.
> generated code would cause ClassCastException
> ---------------------------------------------
>
> Key: THRIFT-2157
> URL: https://issues.apache.org/jira/browse/THRIFT-2157
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler
> Affects Versions: 0.9.1
> Reporter: Dave Brosius
> Priority: Trivial
>
> Looking at the thrift generated code for cassandra, i'm seeing
> msg = (org.apache.thrift.TBase)new
> org.apache.thrift.TApplicationException(org.apache.thrift.TApplicationException.INTERNAL_ERROR,
> e.getMessage());
> as seen here
> https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob;f=interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java;h=837acfc0e964249fd62720420e8f1f85d966f1a3;hb=8f202895ab9e17c3d6bd4965924fd5f1ffc27f94#l6095
> i don't see how TApplicationException can be cast to TBase, and so i'd expect
> a ClassCastException there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
