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:58:53 GMT
Another potential suggestion I forgot about: we try to just move to the 
Hadoop shaded artifacts. This would invalidate the need to do more, but 
I have no idea how "battle-tested" those artifacts are.

On 12/5/17 3:52 PM, Keith Turner wrote:
> If we do the following.
> 
>   * Drop ZooKeeperInstance.ZooKeeperInstance(Configuration config) method.
>   * Drop extends from ClientConfig
>   * Add a method ZooKeeperInstance.ZooKeeperInstance(ClientConfig config)
> 
> Then this will not be binary compatible, so it will still be painful
> in many cases.   It may be source compatible.
> 
> For example the following will be source (but not binary) compatible.
> 
>    ClientConfiguration cc = new ClientConfiguration(file);
>    //when compiled against older version of Accumulo will bind to
> method with commons config signature
>    //when recompiled will bind to clientconfig version of method
>    ZooKeeperInstance zki = new ZooKeeperInstance(cc);
> 
> The following would not be source or binary compatible.
> 
>    Configuration cc = new ClientConfiguration(file);
>    ZooKeeperInstance zki = new ZooKeeperInstance(cc);
> 
> 
> On Tue, Dec 5, 2017 at 3:40 PM, Josh Elser <elserj@apache.org> wrote:
>>
>>
>> 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