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 <els...@apache.org> wrote:
On 12/5/17 3:28 PM, Keith Turner wrote:
On Tue, Dec 5, 2017 at 2:53 PM, Josh Elser<els...@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).
