Folks, Down at the bottom level of the SPI mechanism, the API accepts ClassLoader objects. However, the Directory API does not have methods that take a class loader, so, in practical terms, the SPI mechanism always uses the Thread Context Class Loader.
I just spent some time sorting out a muddle in an OSGi application using Lucene, eventually resolved by setting the TCCL correctly. I wonder what people think of the following possible activities: 1: add an explicit ClassLoader the Directory classes (and whatever below them) to allow applications to take advantage of the SPI's API. 2: add a bit of javadoc to the Directory classes that reminds people that these APIs consume the TCCL. 3: nothing. Meanwhile, I've been thinking about a proposal to make Lucene build OSGi bundles itself, rather than leaving the job to Apache Servicemix. The hard part here is the OSGi principle that every Java _package_ has a single home Jar file. I don't think I have the stomach lining to try to talk anyone around here into some sort of major refactoring to that end. The servicemix jars work around this adequately. One thing the servicemix jars don't deal with is lucene-codecs. I guess I'd like to start by asking how the dev community feels about the whole idea of getting native support for OSGi into Lucene. If there's a strong reaction of _ugh_, I won't push it. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
