[
https://issues.apache.org/jira/browse/SOLR-9565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048884#comment-16048884
]
Noble Paul commented on SOLR-9565:
----------------------------------
bq.This is also the case for analysis plugins. After you have installed a new
3rd party token filter, you can address it in Lucene using its well-known SPI
name
But how do we do it in Solr? There is no such plugin registration mechanism
bq. There is no point in supporting some config for some URPs, and inventing a
new parsing method for each seems sub optimal.
In general I'm concerned about the ugliness/inconvenience of passing json in
request parameters. IMHO The dot separated convention is much better than
sending a full json
I would rather want to create a more generic json payload to be created using
the params API and reference it in a given request.
> Make every UpdateRequestProcessor available implicitly
> ------------------------------------------------------
>
> Key: SOLR-9565
> URL: https://issues.apache.org/jira/browse/SOLR-9565
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Noble Paul
>
> Now that we can 'construct' the URP chains through request parameters, we
> should make all the URPs available automatically. The next challenge is to
> make them read the configuration from request parameters as well
> to access {{HTMLStripFieldUpdateProcessorFactory}} the parameter could be
> {{processor=HTMLStripField}} (The UpdateProcessorFactory part is
> automatically appended )
> The next step is to make the URPs accept request parameters instead of just
> configuration parameters e.g:
> {{processor=HTMLStripField&HTMLStripField.fieldName=<some-field>}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
