[
https://issues.apache.org/jira/browse/SOLR-10105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15991563#comment-15991563
]
James Dyer commented on SOLR-10105:
-----------------------------------
Would it be acceptable to just check for a "solr-core" key on the context, then
if it exists, access the appropriate method via reflextion? This would allow
us to keep this class outside of core but have access to the shared lib dir,
without having to have SolrCore implement a new interface just for this
purpose.
But also, I am not so sure what the design goal here is, how important it is to
keep streams out of core. It seems odd we'd have all of this as part of SolrJ.
Maybe just moving JDBCStream to core is the right answer?
> JDBCStream should be able to load driver from runtime lib
> ---------------------------------------------------------
>
> Key: SOLR-10105
> URL: https://issues.apache.org/jira/browse/SOLR-10105
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Parallel SQL
> Reporter: Noble Paul
> Assignee: Kevin Risden
> Priority: Minor
> Attachments: SOLR-10105.patch
>
>
> Currently the JDBCStream uses Class.forName() to load the driver class. This
> should be improved to try to use the classloader from runtimeLib and the blob
> store API like SOLR-10087. It may be possible to do something like
> Class.forName(driverClassName, true, core.getMemClassLoader()) just need to
> figure out how to get a reference to the core.
> The relevant code is here:
> https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/JDBCStream.java#L180
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
