[jira] [Comment Edited] (ACCUMULO-4753) Update to commons-configuration2

["Christopher Tubbs (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ACCUMULO-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16277694#comment-16277694 ] 

Christopher Tubbs edited comment on ACCUMULO-4753 at 12/4/17 10:50 PM:
-----------------------------------------------------------------------

bq. Best as I could tell (investigated briefly last night), this isn't possible. The difference in beanutil versions between commons-config(1) and commons-config2 would preclude us from making one or the other work.

:(

bq. Another solution would be to shade commons-configuration (and its dependencies) into an Accumulo jar, but shading is generally met with opposition in Accumulo 

Shading wouldn't fix the problem here. The reason we can't move away from commons-configuration is that it is used in a public API method. It was short-sighted advice I gave a while back when the Sqrrl folks were contributing the SSL RPC features and needed to add client-side configuration. We can fix this in our 2.0, but only by breaking API without a minor release with the deprecation. I don't think this can be helped, but I think it's probably worth it for 2.0 to work with Hadoop 3, and to move to commons-configuration2 entirely for our own configs.



was (Author: ctubbsii):
bq. Best as I could tell (investigated briefly last night), this isn't possible. The difference in beanutil versions between commons-config(1) and commons-config2 would preclude us from making one or the other work.

:(

bq. Another solution would be to shade commons-configuration (and its dependencies) into an Accumulo jar, but shading is generally met with opposition in Accumulo 

Shading wouldn't fix the problem here. The reason we can't move away from commons-configuration is that it is used in a public API method. It was short-sighted advice I gave a while back when the Sqrl folks were contributing the SSL RPC features and needed to add client-side configuration. We can fix this in our 2.0, but only by breaking API without a minor release with the deprecation. I don't think this can be helped, but I think it's probably worth it for 2.0 to work with Hadoop 3, and to move to commons-configuration2 entirely for our own configs.


> Update to commons-configuration2
> --------------------------------
>
>                 Key: ACCUMULO-4753
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4753
>             Project: Accumulo
>          Issue Type: Task
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> I'm looking at what it would take to get Accumulo working against Hadoop 3.
> Thankfully, the only issue seems to be around the commons-configuration2 update that Hadoop has changed to. With our use of commons-configuration (1) for ClientConfiguration and others, this brings in multiple versions of commons-beanutils artifacts which result in exceptions at runtime.
> I think the quickest solution is to just upgrade ourselves to use commons-configuration2. The "long-term" solution is to try to switch over to the shaded jars that Hadoop is publishing (but I'm reticent to sign up for that right now :P).
> I think we need to have a discussion about where we want to land this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)