[
https://issues.apache.org/jira/browse/SOLR-14688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17166867#comment-17166867
]
Ishan Chattopadhyaya commented on SOLR-14688:
---------------------------------------------
I think this description has too much unnecessary implementation details and
two important idea mixed together:
# How first party package should be (which should be a separate epic),
# How to separate out current streaming expressions into a package
Let's have two separate JIRAs with design overview and usecases, not
implementation details right now.
> Make Streaming expressions a first party package
> ------------------------------------------------
>
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
