[
https://issues.apache.org/jira/browse/LUCENE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16057316#comment-16057316
]
Dawid Weiss commented on LUCENE-7883:
-------------------------------------
Looks good to me. I'll check why the context classloader is required in
clustering later on. I think the case was that clustering was under shared
libraries and resources loaded per-core couldn't figure where to load classes
from.
> Remove references to Thread#getContextClassLoader() from Lucene/Solr codebase
> -----------------------------------------------------------------------------
>
> Key: LUCENE-7883
> URL: https://issues.apache.org/jira/browse/LUCENE-7883
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Priority: Critical
> Fix For: master (7.0)
>
> Attachments: LUCENE-7883.patch
>
>
> As discussed in LUCENE-7873, the use of
> {{Thread.currentThread().getContextClassLoader()}} is in most cases a bug
> caused by sloppy usage of ClassLoader APIs and should be replaced by
> {{getClass().getClassLoader()}}.
> In Lucene we only have the ClassPathResourceLoader, but this one can be
> solved by removing the "default" constructor. It only affects CustomAnalyzer,
> that should also be extended in Lucene 7.
> The uses in Solr and its test are all to be replaced by
> {{getClass().getClassLoader()}} (except some workaround with clustering using
> a try-finally). This is in most cases historical code, when Solr was a web
> application to workaround some buggy webapp containers. In the current state,
> the code is "just wrong".
> Finally, we should add {{java.lang.Thread#getContextClassLoader()}} to
> forbidden-apis.
> I'd like to get this into Lucene 7, as it affects some APIs in Lucene.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
