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
