Hi Uwe, You're right. Although using the analysis package won't hurt the index, this case is evidence that it's a bad thing, especially if no backport is made. I'll port my code to use the updated API of 5.0.
Thanks guys, Markus -----Original message----- > From:Uwe Schindler <u...@thetaphi.de> > Sent: Thursday 30th January 2014 14:48 > To: java-user@lucene.apache.org > Subject: RE: LUCENE-5388 AbstractMethodError > > Hi Markus, > > Lucene trunk has a backwards incompatible API, so Analyzers compiled with > Lucene 4.6 cannot be used on Lucene trunk. The change in the Analysis API > will not be backported, because this would cause the same problem for users > updating from Lucene 4.6 to Lucene 4.7. In Lucene 4, we try to keep as much > backwards compatibility as possible. If you Analyzers are correct you can use > them almost in any 4.x version, but no longer with Lucene trunk. > > If you want to User Lucene trunk, you have to recompile your Analyzers with > trunk, too, and change their code to use the newest API (otherwise they won't > compile). Analyzers is not the only change, Lucene trunk has many more > changes affecting other parts of Lucene, like StoredDocument/IndexDocument > difference, so mixing those JARs is completely impossible. These other > changes may not have you affected until now, because Analyzers do not use the > Lucene Document and Index APIs, but it's still the wrong thing to do. > > Uwe > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > > -----Original Message----- > > From: Markus Jelsma [mailto:markus.jel...@openindex.io] > > Sent: Thursday, January 30, 2014 12:52 PM > > To: java-user@lucene.apache.org > > Subject: RE: LUCENE-5388 AbstractMethodError > > > > Hi Uwe, > > > > The bug occurred only after LUCENE-5388 was committed to trunk, looks like > > its the changes to Analyzer and friends. The full stack trace is not much > > more > > helpful: > > > > java.lang.AbstractMethodError > > at > > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:140) > > at > > io.openindex.lucene.analysis.util.QueryDigest.unigrams(QueryDigest.java:19 > > 6) > > at > > io.openindex.lucene.analysis.util.QueryDigest.calculate(QueryDigest.java:13 > > 5) > > at > > io.openindex.solr.handler.QueryDigestRequestHandler.handleRequestBody( > > QueryDigestRequestHandler.java:56) > > at > > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandl > > erBase.java:135) > > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1915) > > at > > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:785 > > ) > > at > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418 > > ) > > at > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:203 > > ) > > at > > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandle > > r.java:1419) > > at > > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455) > > at > > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java: > > 137) > > at > > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557) > > at > > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.ja > > va:231) > > at > > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.j > > ava:1075) > > at > > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384) > > at > > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.jav > > a:193) > > at > > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.ja > > va:1009) > > at > > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java: > > 135) > > at > > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHa > > ndlerCollection.java:255) > > at > > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection. > > java:154) > > at > > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.ja > > va:116) > > at org.eclipse.jetty.server.Server.handle(Server.java:368) > > at > > org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHtt > > pConnection.java:489) > > at > > org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHtt > > pConnection.java:53) > > at > > org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractH > > ttpConnection.java:942) > > at > > org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerCo > > mplete(AbstractHttpConnection.java:1004) > > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640) > > at > > org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) > > at > > org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnec > > tion.java:72) > > at > > org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(Socke > > tConnector.java:264) > > at > > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.j > > ava:608) > > at > > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.ja > > va:543) > > at java.lang.Thread.run(Thread.java:724) > > > > Here's what happens at the consumer code and where the exception begins: > > TokenStream stream = analyzer.tokenStream(null, new > > StringReader(input)); > > > > We test trunk with our custom stuff as well, but all our custom stuff is > > nicely > > built with Maven against the most recent release of Solr and/or Lucene. If > > that stays a problem we may have to build stuff against branch_4x instead. > > > > Thanks, > > Markus > > > > -----Original message----- > > > From:Uwe Schindler <u...@thetaphi.de> > > > Sent: Thursday 30th January 2014 11:18 > > > To: java-user@lucene.apache.org > > > Subject: RE: LUCENE-5388 AbstractMethodError > > > > > > Hi, > > > > > > Can you please post your complete stack trace? I have no idea what > > LUCENE-5388 has to do with that error? > > > > > > Please make sure that all your Analyzers and all of your Solr > > > installation only > > uses *one set* of Lucen/Solr JAR files from *one* version. Mixing > > Lucene/Solr JARs and mixing with Factories compiled against older versions > > does not work. You have to keep all in sync, and then all should be fine. > > > > > > Uwe > > > > > > ----- > > > Uwe Schindler > > > H.-H.-Meier-Allee 63, D-28213 Bremen > > > http://www.thetaphi.de > > > eMail: u...@thetaphi.de > > > > > > > > > > -----Original Message----- > > > > From: Markus Jelsma [mailto:markus.jel...@openindex.io] > > > > Sent: Thursday, January 30, 2014 10:50 AM > > > > To: java-user@lucene.apache.org > > > > Subject: LUCENE-5388 AbstractMethodError > > > > > > > > Hi, > > > > > > > > Apologies for cross posting; i got no response on the Sorl list. > > > > > > > > We have a developement environment running trunk but have custom > > > > analyzers and token filters built on 4.6.1. Now the constructors > > > > have changes somewhat and stuff breaks. Here's a consumer trying to > > > > get a TokenStream from an Analyzer object doing TokenStream stream = > > > > analyzer.tokenStream(null, new StringReader(input)); throwing: > > > > > > > > Caused by: java.lang.AbstractMethodError > > > > at > > > > org.apache.lucene.analysis.Analyzer.tokenStream(Analyzer.java:140) > > > > > > > > Changing the constructors won't work either because on 4.x we must > > > > override that specific method: analyzer is not abstract and does not > > > > override abstract method createComponents(String,Reader) in Analyzer > > > > :) > > > > > > > > So, any hints on how to deal with this thing? Wait for 4.x backport > > > > of 5388, or do something clever like <...> fill in the blanks. > > > > > > > > Many thanks, > > > > Markus > > > > > > > > -------------------------------------------------------------------- > > > > - To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > > > > For additional commands, e-mail: java-user-h...@lucene.apache.org > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > > > For additional commands, e-mail: java-user-h...@lucene.apache.org > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > > For additional commands, e-mail: java-user-h...@lucene.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
