[
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
