You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Steve Rowe (JIRA)" <ji...@apache.org> on 2014/03/10 16:49:46 UTC

[jira] [Updated] (SOLR-5653) Create a RESTManager to provide REST API endpoints for reconfigurable plugins

     [ https://issues.apache.org/jira/browse/SOLR-5653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steve Rowe updated SOLR-5653:
-----------------------------

    Attachment: SOLR-5653.patch

Patch, building on Tim's patch. 

 Left to do:
* init args should be moved to {{NamedList}} (typed nested values) instead of the current String->String map, to support {{solrconfig.xml}} plugin init args
* javadocs should be added where there are none

This patch has some minor cleanups, as well as the following changes:

* Renamed {{SolrRestApi}} -> {{SolrSchemaRestApi}}
* Enabled short-form {{"solr.classname"}} class lookup for {{o.a.s.rest.schema.analysis}} (e.g. {{"solr.ManagedWordSetResource"}})
* Finished the {{BaseSchemaResource}} -> {{BaseSolrResource}} renaming by executing {{svn mv \[...\]/BaseSchemaResource \[...\]/BaseSolrResource}} (to retain svn history) and making all classes extending {{BaseSchemaResource}} extend {{BaseSolrResource}} instead
* Removed {{DefaultSchemaResource.java}}; unknown URI paths under {{/schema}} and {{/config}} are now handled by {{RestManager.ManagedEndpoint}}
* {{RestManager.Registry}} now protects against registration of resourceId-s that are already in use by the Schema REST API - protecting {{/config/managed}} and {{/schema/managed}} is now handled via this general mechanism
* {{TestRestManager}}:
** added tests that already-spoken-for REST API endpoints can't be registered
** added tests for switching {{ignoreCase}} of {{ManagedWordSetResource}}
** added XML response format test

* {{ManagedWordSetResource.updateInitArgs()}}:
** compare current/updated {{ignoreCase}} vals as booleans, instead of as string args
** throw an exception if current {{ignoreCase}} = true and updated {{ignoreCase}} = false, since change this is not permitted
* In {{RestManager.addManagedResource()}}, now {{assert}}'ing that the resourceId validation result from {{matches()}} is true, rather than throwing away the result; {{registry.registerManagedResource()}}, called earlier in {{addManagedResource()}}, already ensures that the regex matches against the resourceId.


> 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
>
>
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org