[ https://issues.apache.org/jira/browse/LUCENE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16057907#comment-16057907 ]
Uwe Schindler commented on LUCENE-7883: --------------------------------------- I did some live test with the standalone techproducts example. I have seen no issues, so I think this should be fine to commit. I will add a CHANGES entry in both Lucene and Solr, because this affects both projects. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org