accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Fuchs (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (ACCUMULO-729) refactor core to reduce client application dependency version conflicts
Date Wed, 15 Aug 2012 16:38:38 GMT

     [ 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

        

Mime
View raw message