You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Tom Weber <to...@rtl.lu> on 2006/07/26 15:19:34 UTC
Recompilation of latest lucene seems to break update of Solr
Hello,
jhust compiled the latest version of lucene (), updated the
webapps/solr/WEB-INF/lib/ with the 3 jar files:
lucene-core-2.0.1-dev.jar
lucene-snowball-2.0.1-dev.jar
lucene-highlighter-2.0.1-dev.jar
Restarted solr, The Admin interface of solr is still running, but
trying to send updates to solr gives me the following error:
java.lang.NoClassDefFoundError: org/apache/lucene/document/Fieldable
at org.apache.solr.core.SolrCore.update(SolrCore.java:673)
at org.apache.solr.servlet.SolrUpdateServlet.doPost
(SolrUpdateServlet.java:52)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service
(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process
(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol
$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket
(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt
(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool
$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
I read in the mailinglists of lucene that they changed the
Fieldable into Field:
LUCENE-545 that was recently committed breaks backward compatibility
with
Document.getField(), a non-expert level API that is *very* widely used.
Something simple like
Field x = mydoc.getField("x");
no longer compiles (and neither do other methods with Field in the
signature).
Is this intentional?
If not, uses of "Field" in unit tests should not have been changed to
Fieldable.
Anybody an idea how to solve my problem. I jhust want to change
some stuff in the lucene itself and replace the jar files on solr
with the newly created (compiled) ones
Thanks
tom
Re: Recompilation of latest lucene seems to break update of Solr
Posted by Yonik Seeley <ys...@gmail.com>.
Hi Tom,
I had fixed the LUCENE-545 backward incompatability in Lucene here:
http://issues.apache.org/jira/browse/LUCENE-609
Although it shouldn't be neccessary, maybe it would work if you put
the new lucene libs in solr's lib dir and rebuild solr?
-Yonik
On 7/26/06, Tom Weber <to...@rtl.lu> wrote:
> Hello,
>
> jhust compiled the latest version of lucene (), updated the
> webapps/solr/WEB-INF/lib/ with the 3 jar files:
> lucene-core-2.0.1-dev.jar
> lucene-snowball-2.0.1-dev.jar
> lucene-highlighter-2.0.1-dev.jar
> Restarted solr, The Admin interface of solr is still running, but
> trying to send updates to solr gives me the following error:
>
> java.lang.NoClassDefFoundError: org/apache/lucene/document/Fieldable
> at org.apache.solr.core.SolrCore.update(SolrCore.java:673)
> at org.apache.solr.servlet.SolrUpdateServlet.doPost
> (SolrUpdateServlet.java:52)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
> (ApplicationFilterChain.java:252)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter
> (ApplicationFilterChain.java:173)
> at org.apache.catalina.core.StandardWrapperValve.invoke
> (StandardWrapperValve.java:213)
> at org.apache.catalina.core.StandardContextValve.invoke
> (StandardContextValve.java:178)
> at org.apache.catalina.core.StandardHostValve.invoke
> (StandardHostValve.java:126)
> at org.apache.catalina.valves.ErrorReportValve.invoke
> (ErrorReportValve.java:105)
> at org.apache.catalina.core.StandardEngineValve.invoke
> (StandardEngineValve.java:107)
> at org.apache.catalina.connector.CoyoteAdapter.service
> (CoyoteAdapter.java:148)
> at org.apache.coyote.http11.Http11Processor.process
> (Http11Processor.java:869)
> at org.apache.coyote.http11.Http11BaseProtocol
> $Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
> at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket
> (PoolTcpEndpoint.java:527)
> at
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt
> (LeaderFollowerWorkerThread.java:80)
> at org.apache.tomcat.util.threads.ThreadPool
> $ControlRunnable.run(ThreadPool.java:684)
> at java.lang.Thread.run(Thread.java:595)
>
> I read in the mailinglists of lucene that they changed the
> Fieldable into Field:
>
> LUCENE-545 that was recently committed breaks backward compatibility
> with
> Document.getField(), a non-expert level API that is *very* widely used.
>
> Something simple like
> Field x = mydoc.getField("x");
> no longer compiles (and neither do other methods with Field in the
> signature).
>
> Is this intentional?
> If not, uses of "Field" in unit tests should not have been changed to
> Fieldable.
>
>
> Anybody an idea how to solve my problem. I jhust want to change
> some stuff in the lucene itself and replace the jar files on solr
> with the newly created (compiled) ones
>
> Thanks
>
> tom