On Mon, Jul 6, 2015 at 4:32 PM, Uwe Schindler <u...@thetaphi.de> wrote:
> Hi,
>
> It could be the reason for this is your classpath:
>
> If you load all Lucene Versions into the same classloader (but with different
> package names - I assume you use Maven Shade plugin to do this), Lucene 3
> will load perfectly, yes; Lucene 4 will also load perfectly, yes! But when it
> tries to load Lucene 5, it will fail to load all shipped codecs. Codecs are
> not identified by their Java package name, but by the symbolic name (like
> "Lucene50") as written into the index. The SPI interface of Lucene will load
> all codecs from classpath and save them in a lookup map based on the symbolic
> name. If the Lucene 4 JAR file are placed before Lucene 5 JARs, the "slots"
> for codec names are already taken (because the Lucene 5 loader will see the
> Lucene 4 codecs first), so loading Lucene 5 variants of old codecs is a
> no-op. This may cause those problems, because Lucene 5 ships with "modified"
> versions of the old Lucene 4 codecs - but they are not identical.
>
> You can only workaround by loading the Lucene JARs into completely different
> classloaders (don't forget to also set context classloader!). In that case
> you would not even need to change package names!
Actually, because I did prefix the names, the SPI filenames are also
prefixed too. So I have the file:
META-INF/services/org.trypticon.luceneupgrader.lucene4.internal.lucene.codecs.Codec
And then inside that:
org.trypticon.luceneupgrader.lucene4.internal.lucene.codecs.lucene40.Lucene40Codec
org.trypticon.luceneupgrader.lucene4.internal.lucene.codecs.lucene40.Lucene3xCodec
...
And of course, for Lucene 4, this is being loaded by
org.trypticon.luceneupgrader.lucene4.internal.lucene.util.NamedSPILoader.
So maybe they won't clash after all.
If I found Lucene using "org.apache.lucene" in string constants, I
could have updated that as well. :)
I did identify some other problems during the day:
- segment-less indices don't get upgraded. (raised LUCENE-6658)
- I had a logic flip bug in the version determination code. (explained
one of those cases where it said it didn't upgrade it, but not all of
them.)
- segment info version bumped to 5 which I had treated as an error,
but oh well, I decided to stay on the side of safety with that.
I'm hoping that the segment-less index issue is the underlying cause
of the few remaining failures on my end.
TX
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
