[
https://issues.apache.org/jira/browse/SOLR-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14349197#comment-14349197
]
Noble Paul commented on SOLR-7073:
----------------------------------
Thanks for the comments
bq.I don't like that delete-runtimelib has just the name and not a json body.
In future if we want to delete old versions of jars,
There is one an only one version of a given jar that you can add to a
collection. So, you can either delete or update
bq.Minor typos in JarRepository - s/decerease/decrease and
s/getSytemCollReplica/getSystemCollReplica.
sure
bq.We should check for liveness as well inside getSystemCollReplica
sure
bq.RecoveryStrategy has some code commented out. Is it not necessary anymore?
We no more have those Lazy Wrappers . What we have is {{LazyPluginHolder}} .
When you do a {{get()}} for a plugin, you get a live instance. fully
instantiated
bq.The patch removes the disableExternalLib flag from RequestHandlers. Is that
not needed anymore?
That is moved to {{PluginRegistry}} where it assumes a new name
{{enable.runtime.lib}}
bq.Can we please rename SolrConfig.clsVsInfo to classVsInfo? and LazyRHHolder
to LazyRequestHandlerHolder?
sure
bq.Why is LazyRHHolder required?
It was required because of the feature we released in 5.0 for a per request
handler classloader. I'm going to remove that
bq.RequestHandlers.initHandlersFromConfig used to call init on the handlers. I
can't find where they are being initialized now.
It all goes into {{PluginsRegistry}} . Initialization is done inside there
> Add an API to add a jar to a collection's classpath
> ---------------------------------------------------
>
> Key: SOLR-7073
> URL: https://issues.apache.org/jira/browse/SOLR-7073
> Project: Solr
> Issue Type: Sub-task
> Reporter: Noble Paul
> Assignee: Noble Paul
> Attachments: SOLR-7073.patch, SOLR-7073.patch, SOLR-7073.patch
>
>
> The idea of having separate classloaders for each component may be counter
> productive. This aims to add a jar dependency to the collection itself and
> each core belonging to that collection will have the jar in the classpath
> As we load everything from the .system collection , we cannot make the core
> loading delayed till .system is fully loaded and is available .
> There is a new set of config commands to manage the dependencies on a
> collection level. It is possible to have more than one jar as a dependency.
> The "lib" attribute is same as the blob name that we use in the blob store API
> example:
> {code}
> curl http://localhost:8983/solr/collection1/config -H
> 'Content-type:application/json' -d '{
> "add-runtimelib" : {"name": "jarname" , "version":2 },
> "update-runtimelib" :{"name": "jarname" ,"version":3},
> "delete-runtimelib" :"jarname"
> }'
> {code}
> The same is added to the overlay.json .
> The default SolrResourceLoader does not have visibility to these jars .
> There is a classloader that can access these jars which is made available
> only to those components which are specially annotated
> Every pluggable component can have an optional extra attribute called
> {{runtimeLib=true}}, which means, these components are not be loaded at core
> load time. They are tried to be loaded on demand and if all the dependency
> jars are not available at the component load time an error is thrown .
> example of registering a valueSourceParser which depends on the runtime
> classloader
> {code}
> curl http://localhost:8983/solr/collection1/config -H
> 'Content-type:application/json' -d '{
> "create-valuesourceparser" : {"name": "nvl" ,
> "runtimeLib": true,
> "class":"solr.org.apache.solr.search.function.NvlValueSourceParser ,
> "nvlFloatValue":0.0 }
> }'
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
