accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Turner (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-756) Thrift API should be removed and abstracted
Date Mon, 17 Sep 2012 13:54:07 GMT


Keith Turner commented on ACCUMULO-756:

One problem with this ZooKeeperInstance.getConnector(AuthInfo auth).  This is a public method
thats part of the public API, your patch changed the package of AuthInfo so it will break
API compat.   I do not know why AuthInfo is in the public API, it should not be, but it is.
  The fact that it should not be there is one issue, but it is there and users are probably
using it so it should not change.

I create a little script to diff the API.  You can run this, its in test/compat/
  It will generate a diff of the public API.  I just ran it to compate 1.4 w/ trunk and saw
some issues unrelated to your change.   I did not apply your patch, I just took a glance at
it.  I was aware of the issue with AuthInfo being in the public API and caught that.  AuthInfo
being in the public API sorta annoys me because its a thrift object, I hope I am not the one
who did that :)
> Thrift API should be removed and abstracted
> -------------------------------------------
>                 Key: ACCUMULO-756
>                 URL:
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: dist, thrift
>            Reporter: Christopher Tubbs
>            Assignee: Christopher Tubbs
>              Labels: api, module, rpc, thrift
>             Fix For: 1.5.0
>         Attachments: ACCUMULO-756.patch
> 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
>  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:

View raw message