[LUCENE-7883] Remove references to Thread#getContextClassLoader() from Lucene/Solr codebase

• Type: Improvement
• Status: Resolved
• Priority: Critical
• Resolution: Fixed
• Fix Version/s: 7.0
• Lucene Fields: New
• Assignee: Uwe Schindler
• Reporter: Uwe Schindler
• Created: 20/Jun/17 10:32
• Updated: 28/Aug/22 15:16
• Resolved: 22/Jun/17 18:23

Description

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.

Issue Links

• is related to: LUCENE-7873 Remove context classloader from SPI lookups by default
• relates to: LUCENE-7870 Use cl.loadClass(...) instead of Class.forName(..., cl) in SPIClassIterator