[jira] [Updated] (SOLR-14688) first party package implementation design

["Noble Paul (Jira)" <ji...@apache.org>]

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

Noble Paul updated SOLR-14688:
------------------------------
    Summary: first party package implementation design  (was: Make Streaming expressions a first party package)

> first party package implementation design
> -----------------------------------------
>
>                 Key: SOLR-14688
>                 URL: https://issues.apache.org/jira/browse/SOLR-14688
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Noble Paul
>            Priority: Major
>
> This will be an implicit package. What it means is, that the package will be preinstalled and the streaming handler will be registered implicitly as it is done today. Behind the scenes it will be loaded from a package.
> h1. How do we achieve this?
> h2. step 1
> Ensure that the classes of streaming expressions are packaged into a jar of its own.
> h2. step 2
> These jars should be put into a directory {{<SOLR_HOME>/files/\_trusted_/solr-jars}} in our distro
> h2. step 3
> add an  {{implicit-packages.json}} as follows. This will be present in our solr core jar itself. The {{packages.json}} in ZK will be merged with the implicit one to get the final one. for instance. if the {{packages.json}} in ZK has a package called {{expressible/8.7}} it will override the implicit one. But I assume that the newly configured ones will have  newer versions (say {{8.7.1}} etc)
> {code:java}
> {
>   "packages" : {
>     "expressible" : [ {
>       "version" : "8.7",
>       "files": ["/_trusted_/solr-jars/streaming-expressions-8.7.jar"]
>     }]
>   }
> }
> {code}
> h2. step 4
> change our {{ImplicitPlugins.json}} and modify the section for /stream as follows
> {code:java}
>    {"/stream": {
>       "class": "expressible:org.apache.solr.handler.StreamHandler",
>       "useParams":"_STREAM",
>       "invariants": {
>         "distrib": false
>       }
>     },
>  "/sql": {
>       "class": "expressible:org.apache.solr.handler.SQLHandler",
>       "useParams":"_SQL",
>       "invariants": {
>         "distrib": false
>       }
> }
> {code}
> This ensures that the {{StreamHandler}} is always loaded from the package {{expressible}}
> h2. What happens to users who are upgrading from {{8.6}} ?
> There are no external changes to any configuration anywhere, all the changes are internal. So, if a user switch to {{8.7}} everything will continue to work as if nothing has changed.
> h2. So what's the point?
> A user will be able to install a new versions of {{expressible}} package to their cluster using the package manager. So, the {{packages.json}} in ZK will look as follows.
> {code:java}
> {
>   "packages" : {
>     "expressible" : [ {
>       "version" : "8.7.1",
>       "files": ["/expressible/streaming-expressions-8.7.1.jar"]
>     },{
>       "version" : "8.8",
>       "files": ["/expressible/streaming-expressions-8.8.jar"]
>     },{
>       "version" : "8.9",
>       "files": ["/expressible/streaming-expressions-8.9.jar"]
>     }
>     ]
>   }
> }
> {code}
> This means the user has the choice of installing and using {{8.7}} or {{8.7.1}} or even more versions. Also note that the jars are living under a folder {{/expressible}}. This means it's is not a specially trusted jar. It should be published with a proper signature and the user should trust those keys by adding a repository
> h2. does the package loading system need to change?
> Yes, we should stop requiring a signature for any jars under {{\_trusted_/solr-jars}} directory.
> h2. how do users install custom {{<expressible>}} plugins?
> There will be no difference to that as well. register your expressible in {{solrconfig.xml}} to be loaded from their own package and it will work just fine



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org