You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Mark Miller (JIRA)" <ji...@apache.org> on 2014/11/04 00:45:34 UTC

[jira] [Commented] (SOLR-6698) Solr is not consistent wrt ZkCredentialsProvider / ZkCredentialProvider

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

Mark Miller commented on SOLR-6698:
-----------------------------------

+1. I think this is new enough and likely with little enough use that we should mention it in the top upgrade level of changes, but simply fix it. I really should have marked the API's as experimental for a release or two, but we are generally fairly lenient on java API backcompat currently anyway. As long as we have a good fail message, I think it's fine.

> Solr is not consistent wrt ZkCredentialsProvider / ZkCredentialProvider
> -----------------------------------------------------------------------
>
>                 Key: SOLR-6698
>                 URL: https://issues.apache.org/jira/browse/SOLR-6698
>             Project: Solr
>          Issue Type: Bug
>          Components: SolrCloud
>            Reporter: Gregory Chanan
>            Priority: Minor
>
> Solr uses ZkCredentialsProvider / ZkCredentialProvider in inconsistent ways.
> For example, in the configs it's referred to as zkCredentialProvider
> https://github.com/apache/lucene-solr/blob/6dd0103c8130e6207151fa5c2f9ccfcfe9500c59/solr/core/src/java/org/apache/solr/core/ConfigSolrXml.java#L168
> but the cloud scripts show it as zkCredentialsProvider (wrong):
> https://github.com/apache/lucene-solr/blob/6dd0103c8130e6207151fa5c2f9ccfcfe9500c59/solr/cloud-dev/solrcloud-start.sh#L7
> The implementations refer to ZkCredentialsProvider, i.e.:
> https://github.com/apache/lucene-solr/blob/6dd0103c8130e6207151fa5c2f9ccfcfe9500c59/solr/solrj/src/java/org/apache/solr/common/cloud/ZkCredentialsProvider.java
> it would be good to be consistent here.  I don't have a preference for which name to use.  Unless we want to put in some code to handle old versions, it seems like we need to break compatibility (i.e. either rename the config names or the names of the implementing classes).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org