[
https://issues.apache.org/jira/browse/SOLR-5653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13931113#comment-13931113
]
Timothy Potter commented on SOLR-5653:
--------------------------------------
Looking good Steve ...
I like the conversion over to using NamedList<?> for managedInitArgs in
general. However, I think we should serialize into a JSON Map when returning
initArgs in the API. Apparently, a NamedList converts to JSON as a list and not
a map, ie.
"wordSet":{ "initArgs":["ignoreCase","true"], ...
This seems like an awkward format for exposing to client applications consuming
the API. I think a map representation of initArgs seems better, i.e.
"wordSet":{ "initArgs":{ "ignoreCase":true, ... } }
To address this, can you add the following method to ManagedResource:
/**
* Converts a NamedList<Object> into a sorted Map for returning as JSON.
*/
protected Map<String,Object> convertNamedListToMap(NamedList<Object> args) {
Map<String,Object> argsMap = new TreeMap<String,Object>();
if (args != null && args.size() > 0) {
Iterator<Map.Entry<String,Object>> argIter = args.iterator();
while (argIter.hasNext()) {
Map.Entry<String,Object> entry = argIter.next();
argsMap.put(entry.getKey(), entry.getValue());
}
}
return argsMap;
}
And then change the buildMapToStore method to call it:
toStore.put(INIT_ARGS_JSON_FIELD, convertNamedListToMap(managedInitArgs));
Also, previously, the ManagedResource would return default values of the
initArgs, but the conversion over to NamedList<?> has made that go away
somehow. In other words, this test now fails when doing a GET against the
initial state of the stop word resource because the default value for
ignoreCase is not returned with the initial state of the resource anymore:
assertJQ(endpoint,
"/wordSet/initArgs/ignoreCase==\"false\"", <<< This now fails
"/wordSet/managedList==[]");
I think the initial state of a resource should return the default values for
initArgs if the default is not null so that this test case would pass.
If you can post an updated patch with these changes, I can finish the patches
for SOLR-5655 and 5654.
Thanks.
> Create a RESTManager to provide REST API endpoints for reconfigurable plugins
> -----------------------------------------------------------------------------
>
> Key: SOLR-5653
> URL: https://issues.apache.org/jira/browse/SOLR-5653
> Project: Solr
> Issue Type: Sub-task
> Reporter: Steve Rowe
> Attachments: SOLR-5653.patch, SOLR-5653.patch, SOLR-5653.patch,
> SOLR-5653.patch, SOLR-5653.patch
>
>
> It should be possible to reconfigure Solr plugins' resources and init params
> without directly editing the serialized schema or {{solrconfig.xml}} (see
> Hoss's arguments about this in the context of the schema, which also apply to
> {{solrconfig.xml}}, in the description of SOLR-4658)
> The RESTManager should allow plugins declared in either the schema or in
> {{solrconfig.xml}} to register one or more REST endpoints, one endpoint per
> reconfigurable resource, including init params. To allow for multiple plugin
> instances, registering plugins will need to provide a handle of some form to
> distinguish the instances.
> This RESTManager should also be able to create new instances of plugins that
> it has been configured to allow. The RESTManager will need its own
> serialized configuration to remember these plugin declarations.
> Example endpoints:
> * SynonymFilterFactory
> ** init params: {{/solr/collection1/config/syns/myinstance/options}}
> ** synonyms resource:
> {{/solr/collection1/config/syns/myinstance/synonyms-list}}
> * "/select" request handler
> ** init params: {{/solr/collection1/config/requestHandlers/select/options}}
> We should aim for full CRUD over init params and structured resources. The
> plugins will bear responsibility for handling resource modification requests,
> though we should provide utility methods to make this easy.
> However, since we won't be directly modifying the serialized schema and
> {{solrconfig.xml}}, anything configured in those two places can't be
> invalidated by configuration serialized elsewhere. As a result, it won't be
> possible to remove plugins declared in the serialized schema or
> {{solrconfig.xml}}. Similarly, any init params declared in either place
> won't be modifiable. Instead, there should be some form of init param that
> declares that the plugin is reconfigurable, maybe using something like
> "managed" - note that request handlers already provide a "handle" - the
> request handler name - and so don't need that to be separately specified:
> {code:xml}
> <requestHandler name="/select" class="solr.SearchHandler">
> <managed/>
> </requestHandler>
> {code}
> and in the serialized schema - a handle needs to be specified here:
> {code:xml}
> <fieldType name="text_general" class="solr.TextField"
> positionIncrementGap="100">
> ...
> <analyzer type="query">
> <tokenizer class="solr.StandardTokenizerFactory"/>
> <filter class="solr.SynonymFilterFactory" managed="english-synonyms"/>
> ...
> {code}
> All of the above examples use the existing plugin factory class names, but
> we'll have to create new RESTManager-aware classes to handle registration
> with RESTManager.
> Core/collection reloading should not be performed automatically when a REST
> API call is made to one of these RESTManager-mediated REST endpoints, since
> for batched config modifications, that could take way too long. But maybe
> reloading could be a query parameter to these REST API calls.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
