[
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: [email protected]
For additional commands, e-mail: [email protected]
