accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <els...@apache.org>
Subject Re: [DISCUSS] Hadoop3 support target?
Date Tue, 05 Dec 2017 20:40:51 GMT


On 12/5/17 3:28 PM, Keith Turner wrote:
> On Tue, Dec 5, 2017 at 2:53 PM, Josh Elser<elserj@apache.org>  wrote:
>> Interesting. What makes you want to deprecate ClientConfig entirely?
>>
>> I'd be worried about removing without sufficient thought of replacement
>> around. It would be a bit "churn-y" to introduce yet another way that
>> clients have to connect (since it was introduced in 1.6-ish?). Working
>> around the ClientConfig changes was irritating for the downstream
>> integrations (Hive, most notably).
> Ok maybe thats a bad idea, not looking to cause pain.  Here were some
> of my goals.
> 
>   * Remove commons config from API completely via deprecation cycle.
>   * Introduce API that supports putting all props needed to connect to
> Accumulo in an API.
> 
> I suppose if we want to keep ClientConfig class in API, then there is
> no way to remove commons config via a deprecation cycle??  We can't
> deprecate the extension of commons config, all we can do is just drop
> it at some point.
> 

My line of thinking is that the majority of the time, we're creating a 
ClientConfiguration by one of:

* ClientConfiguration#loadDefault()
* new ClientConfiguration(String)
* new ClientConfiguration(File)

Granted, we also inherit/expose a few other things (notably extending 
CompositeConfiguration and throwing ConfigurationException). I would be 
comfortable with dropping those w/o deprecation. I have not seen 
evidence from anyone that they are widely in use by folks (although I've 
not explicitly asked, either).

Mime
View raw message