You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Noble Paul (JIRA)" <ji...@apache.org> on 2015/02/04 10:06:35 UTC
[jira] [Updated] (SOLR-7073) Add an API to add a jar to a
collection's classpath
[ https://issues.apache.org/jira/browse/SOLR-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Noble Paul updated SOLR-7073:
-----------------------------
Description:
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-runtime-lib" : {"lib": "jarname" , "version":2 },
"update-runtime-lib" :{"lib": "jarname" ,"version":3},
"delete-runtime-lib" :"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}
was:
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 .
So, we have the following set of 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-runtime-lib" : {"lib": "jarname" , "version":2 },
"update-runtime-lib" :{"lib": "jarname" ,"version":3},
"delete-runtime-lib" :"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}
> 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
>
> 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-runtime-lib" : {"lib": "jarname" , "version":2 },
> "update-runtime-lib" :{"lib": "jarname" ,"version":3},
> "delete-runtime-lib" :"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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org