[
https://issues.apache.org/jira/browse/SOLR-9569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15542199#comment-15542199
]
Noble Paul commented on SOLR-9569:
----------------------------------
bq.XML is richer and is legacy. So, the question is how we are going to deal
with that. I am not sure I understood the answer.
The richness is not necessarily a requirement. It is the legacy and I don't see
any other reason. The problem with xml is there is no 1:1 mapping between data
and the corresponding xml. This results is very complex code required to
read/edit/persist xml
bq.Right now, the /config against the core with default configuration returns:
_"commitWithin":
I don't see that. Can you tell me the steps to see that.
bq.I could not find a representative security.json in the codebase. Could you
point out the one you mean.
You may not find one in codebase. However you can see one in the documentation
https://cwiki.apache.org/confluence/display/solr/Rule-Based+Authorization+Plugin
. The point is more about how configuration of the component is delegated to
the component itself. We currently don't do round tripping from an API. We
expect users to fetch zk files and put it back exactly as it is. The best place
to add that functionality is to add it to the {{/admin/zookeeper}} endpoint.
Today, it returns the data wrapped in JSON.
bq.Just because something is achievable theoretically, does not mean we started
on the road in the right direction.
it is not theoretical. It is not done because it was not a requirement
> Moving to a unified solrconfig experience
> -----------------------------------------
>
> Key: SOLR-9569
> URL: https://issues.apache.org/jira/browse/SOLR-9569
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Noble Paul
> Assignee: Noble Paul
>
> * Any config API call will result in a collection reload. We should ensure
> that only the relevant component is reloaded. This will work only for
> components specified in the configoverlay.json
> * Move most commonly used paths to ImplicitPlugins
> * move their request parameters to params.json
> * Enhance the config API to expand show the params used for each
> requesthandler inline
> Today we use the solrconfig.xml as a place to document things. As we move
> more stuff off of solrconfig.xml let's point it to a ref guide page to
> discuss about all the requesthandlers available by default and their
> configuration
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
