[
https://issues.apache.org/jira/browse/SOLR-14067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17219380#comment-17219380
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14067:
------------------------------------------------------
The rename can still be done in a backwards compatible way, right? If we:
1) Rename {{StatelessScriptUpdateProcessorFactory}} ->
{{ScriptUpdateProcessorFactory}}
2) Create a new {{StatelessScriptUpdateProcessorFactory}} that extends
{{ScriptUpdateProcessorFactory}} and delegates everything to it (maybe also log
a warning)
3) Mark {{StatelessScriptUpdateProcessorFactory}} as deprecated, in favor of
{{ScriptUpdateProcessorFactory}}
That should allow upgrades without changing configs (and even if someone is
extending {{StatelessScriptUpdateProcessorFactory}} it would work, plus they'd
get the deprecation warning). I'd argue that we may want to keep that in 9 too,
if we want to support rolling upgrades from 8.x.
Regarding moving to a contrib, is that something that needs to wait for 9? If
we don't, someone upgradeing to 8.8 would just have to make sure the
"script-update-processor" jar is in the classpath, but no changes to config if
we keep the same package name. It can just be an upgrade note, right? or am I
missing something?
> Deprecate StatelessScriptUpdateProcessor and disabled by default
> ----------------------------------------------------------------
>
> Key: SOLR-14067
> URL: https://issues.apache.org/jira/browse/SOLR-14067
> Project: Solr
> Issue Type: Improvement
> Reporter: Ishan Chattopadhyaya
> Assignee: David Eric Pugh
> Priority: Major
> Fix For: 8.7
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> We should eliminate all scripting capabilities within Solr. Let us start with
> the StatelessScriptUpdateProcessor deprecation/removal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
