[
https://issues.apache.org/jira/browse/ACCUMULO-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449353#comment-13449353
]
Christopher Tubbs commented on ACCUMULO-756:
--------------------------------------------
I quickly modified the POM files and moved the generated code around to put the
thrift stuff in a separate module to see how easy this would be. There are some
issues:
1. I don't have commit access yet, so I can't "svn mv" to keep svn history
during refactoring (so I'll need to work with a committer to reproduce those in
a sequence of commits, or else we lose that info in the patch I would otherwise
provide).
2. I don't have a sense of what the abstraction would look like, except
possibly just looking at the thrift definitions and creating Java interfaces
that match. Without that, I can simply move the thrift stuff aside and update
the dependencies in the build (which would still be useful on its own), so
we'll need some work on creating the interfaces for the abstraction.
3. We need a name for the sub-modules. I was originally going to call it
"accumulo-api", with "accumulo-api-thrift" as the artifactId for the
abstraction and thrift implementation, respectively. However, "api" is
misleading, because somebody might think this contains the public API, which is
actually in the "accumulo-core" artifact (should probably be in a
"accumulo-client" one, but that's a separate concern). "accumulo-rpc" was
suggested (with "accumulo-rpc-thrift" being an implementation).
4. This is not useful to consider yet, because there is only one
implementation, but at some point, some consideration is going to need to be
made to decide how to swap out implementations. This could be done with an
annotation scanning framework with drop-in jars, a configuration change with
classes being available on the classpath, or a build-time configuration. This
is a future consideration, though. Not relevant for this ticket... just
documenting to put it on record.
> Thrift API should be removed and abstracted
> -------------------------------------------
>
> Key: ACCUMULO-756
> URL: https://issues.apache.org/jira/browse/ACCUMULO-756
> Project: Accumulo
> Issue Type: Improvement
> Components: dist, thrift
> Affects Versions: 1.5.0
> Reporter: Christopher Tubbs
> Assignee: John Vines
> Labels: api, module, rpc, thrift
> Fix For: 1.5.0
>
>
> The thrift API for communication between components should be abstracted out
> and made more generic, so we can plug in different communications mechanisms.
> The thrift code generation and the generated code should be moved to a
> specific implementation of this abstraction, and put in a separate sub-module.
> This can help with:
> 1. Making full mocking support easier (ACCUMULO-14) with an in-process "RPC"
> implementation.
> 2. Testing alternative protocols, like Avro, Protocol Buffers, SSL, etc.
> 3. Minimizing dependencies and isolating thrift generated code from code
> that is maintained (ACCUMULO-493).
> 4. Wire compatibility (ACCUMULO-751).
> 5. More?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
