You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by "Adam Fuchs (JIRA)" <ji...@apache.org> on 2012/08/14 21:43:38 UTC

[jira] [Created] (ACCUMULO-729) refactor core to reduce client application dependency version conflicts

Adam Fuchs created ACCUMULO-729:
-----------------------------------

             Summary: refactor core to reduce client application dependency version conflicts
                 Key: ACCUMULO-729
                 URL: https://issues.apache.org/jira/browse/ACCUMULO-729
             Project: Accumulo
          Issue Type: Improvement
          Components: client
            Reporter: Adam Fuchs
            Assignee: Billie Rinaldi


Accumulo client applications often include things like thrift servers. If the client application uses a different version of a library (like libthrift) than the Accumulo client library uses then baby Jesus cries (and it doesn't work).

Version conflicts have been common among our users for the following libraries:
 * log4j/slf4j
 * thrift
 * zookeeper
 * hadoop

This problem is solvable with a moderate amount of effort. The Accumulo client library should create a separate classloader to load its dependencies. We can then separate the core code into interfaces and implementations. For example, the following methods can load the implementations through reflection, and all of their dependencies can be contained in that ClassLoader:
 * Instance.getConnector(...)
 * Instance.getConfiguration(...)
 * Instance.*
 * Connector.createScanner(...)
 * Connector.createBatchScanner(...)
 * Connector.createBatchWriter(...)
 * Connector.tableOperations(...)
 * Connector.securityOperations(...)
 * Connector.instanceOperations(...)

This exercise would also make the Accumulo client API more explicit, which would improve accessibility and reduce the false sense of continuity that may be perceived around some of the classes in core.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (ACCUMULO-729) refactor core to reduce client application dependency version conflicts

Posted by "Adam Fuchs (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ACCUMULO-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adam Fuchs updated ACCUMULO-729:
--------------------------------

    Description: 
Accumulo client applications often include things like thrift servers. If the client application uses a different version of a library (like libthrift) than the Accumulo client library uses then baby Jesus cries (and it doesn't work).

Version conflicts have been common among our users for the following libraries:
 * log4j/slf4j
 * thrift
 * zookeeper
 * hadoop

This problem is solvable with a moderate amount of effort. The Accumulo client library should create a separate classloader to load its dependencies. We can then separate the core code into interfaces and implementations. For example, the following methods can load the implementations through reflection, and all of their dependencies can be contained in that ClassLoader:
 * Instance.getConnector(...)
 * Instance.getConfiguration(...)
 * Instance.*

It's probably only the Instance methods that need to do the reflection trick, since everything else is loaded from a connector, whose implementation would be loaded from the other ClassLoader.

This exercise would also make the Accumulo client API more explicit, which would improve accessibility and reduce the false sense of continuity that may be perceived around some of the classes in core.


  was:
Accumulo client applications often include things like thrift servers. If the client application uses a different version of a library (like libthrift) than the Accumulo client library uses then baby Jesus cries (and it doesn't work).

Version conflicts have been common among our users for the following libraries:
 * log4j/slf4j
 * thrift
 * zookeeper
 * hadoop

This problem is solvable with a moderate amount of effort. The Accumulo client library should create a separate classloader to load its dependencies. We can then separate the core code into interfaces and implementations. For example, the following methods can load the implementations through reflection, and all of their dependencies can be contained in that ClassLoader:
 * Instance.getConnector(...)
 * Instance.getConfiguration(...)
 * Instance.*
 * Connector.createScanner(...)
 * Connector.createBatchScanner(...)
 * Connector.createBatchWriter(...)
 * Connector.tableOperations(...)
 * Connector.securityOperations(...)
 * Connector.instanceOperations(...)

This exercise would also make the Accumulo client API more explicit, which would improve accessibility and reduce the false sense of continuity that may be perceived around some of the classes in core.


    
> refactor core to reduce client application dependency version conflicts
> -----------------------------------------------------------------------
>
>                 Key: ACCUMULO-729
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-729
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: client
>            Reporter: Adam Fuchs
>            Assignee: Billie Rinaldi
>
> Accumulo client applications often include things like thrift servers. If the client application uses a different version of a library (like libthrift) than the Accumulo client library uses then baby Jesus cries (and it doesn't work).
> Version conflicts have been common among our users for the following libraries:
>  * log4j/slf4j
>  * thrift
>  * zookeeper
>  * hadoop
> This problem is solvable with a moderate amount of effort. The Accumulo client library should create a separate classloader to load its dependencies. We can then separate the core code into interfaces and implementations. For example, the following methods can load the implementations through reflection, and all of their dependencies can be contained in that ClassLoader:
>  * Instance.getConnector(...)
>  * Instance.getConfiguration(...)
>  * Instance.*
> It's probably only the Instance methods that need to do the reflection trick, since everything else is loaded from a connector, whose implementation would be loaded from the other ClassLoader.
> This exercise would also make the Accumulo client API more explicit, which would improve accessibility and reduce the false sense of continuity that may be perceived around some of the classes in core.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira