![]() > to switch from Class.forName(.) to ClassLoader.loadClass(.), so that > concluding that the best fix was to ask upstream projects (like Lucene) > This problem was discussed a decade ago in Bug 127963, with Thomas Watson (In reply to Andreas Sewe from comment #0) ![]() The bundle has no imports, so no inbound wire can be wrong. Unlike many other class-loading issues, this has nothing to do with (the lack of) uses constraints. AFAICT, Lucene 3.5.0 happily coexists with Lucene 6.x. But it could just as well have affected the start-up of the Automated Error Reporting ServerConnection (see the stack trace above), as both Code Search and AERI performs start up tasks. After the restart, you will (likely, due to timing) see "An Problem Occurred" dialog: Could not initialize class .Codec$Holder Install the Ctrlflow Code Search Professional third-party plugin from (includes Lucene 5.1.0 from Orbit) Create a new Java project called "Test" Install Oxygen RC2 Eclipse IDE for Java Developers from (includes Lucene 6.1.0 from Orbit) This problem was discussed a decade ago in Bug 127963, with Thomas Watson concluding that the best fix was to ask upstream projects (like Lucene) to switch from Class.forName(.) to ClassLoader.loadClass(.), so that ContextFinder can do its magic.īut for Oxygen, this is too late in the game, so we should really discuss workaround, as any third-party plugin may introduce a different version of and then cause failures, depending on the timing, in either itself or Eclipse Oxygen. Thus, it *will* find the correct Lucene50PostingsFormat, namely the one defined by _6.2.1.Īlas, Class.forName(.) caches the mapping from ".lucene50.Lucene50PostingsFormat" to the Lucene50PostingsFormat.class defined by _5.1.0, simply because that version happened to be loaded earlier. Now the current thread's context class loader is the (singleton) instance of .framework.ContextFinder, which was specifically designed to take care of such situations:ĬontextFinder will search for .lucene50.Lucene50PostingsFormat using only the class loaders "on" the current calls stack (in the above case: the class loaders of _6.2.1, .aeri.ide_2.0.5, and _21.0.0). The problem is that clazz is the PostingsFormat.class loaded by the class loader of the _6.2.1 bundle, whereas the instance of Lucene50PostingsFormat was defined by the class loader of _5.1.0. Return Class.forName(c, false, loader).asSubclass(clazz) And here's the problem: Depending on whether a Codec has already been created for a different version of Lucene (say Lucene 5.1.0, which is also in Orbit), SPIClassIterator.next() will fail in this line with a ClassCastException: The above stack trace was taken when the Eclipse Automated Error Reporting client (which uses Lucene 6.2.1) starts up. ServerConnection.createRestBasedProblemsHistory(File) line: 183 RestBasedProblemsHistory.(ServerConfiguration, File) line: 83 LuceneHttpCacheStorage.(Directory) line: 69 IndexWriterConfig(LiveIndexWriterConfig).(Analyzer) line: 111 NamedSPILoader.(Class, ClassLoader) line: 49 NamedSPILoader.reload(ClassLoader) line: 70 Ĭreating a new Codec like this ultimately performs a Class.forName(.) call with the current thread's context class loader:Ĭlass.forName(String, boolean, ClassLoader) line: 360 The relevant classes performing the loading are PostingFormat.Holder, NamedSPILoader, and SPIClassIterator. In the above, Lucene uses its own service loader implementation to look for the implementation class registered in META-INF/services/.PostingsFormat. Private final PostingsFormat defaultFormat = PostingsFormat.forName("Lucene50") Some of these subformats (e.g., PostingsFormat) are loaded using a service-loader approach : Each codec consists of several subformats, e.g., the format for postings. These are called codec (e.g., Lucene62Codec ). ![]() Lucene can support different formats for its index. (This means that this is *not* a wiring issue.) Which version will break depends on timing the version loading a certain class first wins. ![]() If two versions of the bundle are present, then only one of the versions will work the other will fail with a NoClassDefFoundError caused by an ExceptionInInitializerError caused by a ClassCastException. I am currently investigating a class-loading bug (steps to reproduce at the end) that potentially affects all users of Lucene 5.x or 6.x (the later will be included with Oxygen and used by at least the Eclipse Help and the Automated Error Reporting client):
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |