[
https://issues.apache.org/jira/browse/SOLR-14688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-14688:
------------------------------
Description:
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 say 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
was:
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 say 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
> 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 say 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
