Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ACCUMULO-4170 Clarify ClientConfiguration javadocs #307

Closed
wants to merge 3 commits into from
Closed

ACCUMULO-4170 Clarify ClientConfiguration javadocs #307

wants to merge 3 commits into from

Conversation

jmark99
Copy link
Contributor

@jmark99 jmark99 commented Oct 12, 2017

ACCUMULO-4170 Clarify ClientConfiguration javadocs

Updated the javadoc information with the ClientConfiguration class.
Specifically reworked the default search path information to be
displayed as a list rather than inline, thereby easing readability.

Reworded a few of the sentences and moved the path order up to the class
level rather than the method level.

classv18

methodv18

Updated the javadoc information with the ClientConfiguration class.
Specifically reworked the default search path information to be
displayed as a list rather than inline, thereby easing readability.

Reworded a few of the sentences and moved the path order up to the class
level rather than the method level.
@keith-turner
Copy link
Contributor

Is this the same change as #306? We usually make the change in the oldest branch and then merge it forward.

@jmark99
Copy link
Contributor Author

jmark99 commented Oct 12, 2017

The change for 1.8 is slightly different than for 1.7. Although the 1.8 and 2.0 changes are identical so the #307 could be merged forward. I wasn't sure how that situation was handled so I ended up creating a pull request for master as well.

Reverted default search path information back to method level versus
class level.
Copy link
Member

@ctubbsii ctubbsii left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good to me. Thanks for taking a look and fixing the docs. Looking at this, though, I'm realizing that our current mechanism for handling client-side configuration is pretty awful. I'm wondering what we can do about that. I think in future, maybe we should consider less "magical" behavior, and more APIs which require explicit input from the caller to create the configuration the caller requires.

Re-introduced some documentation to the loadDefaults() methods that had
inadvertently been overlooked in a previos commit.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants