Warum kann Solr 1.3.0 nicht mit CentOS, Plesk 9.2.1 und Tomcat 5.5 installiert werden?

Question

Ok, ich habe gerade einen dedizierten Server für meinen Kunden über seinen Hosting-Anbieter eingerichtet. Sie haben dort Plesk installiert (Version 9.2.1) und einer der Nachteile dieses dedizierten Servers ist, dass sie bei jeder Aufgabe außerhalb des Kontrollpanels (z.B. SSH verwenden) keine Unterstützung für diese Softwarekomponente garantieren. Das ist in Ordnung, denn ich würde sowieso lieber das Kontrollpanel verwenden, um es zu tun, da ich nur eine WAR-Datei hochladen muss, um das Servlet zu installieren.

Hier ist jedoch das Problem: Nach der Installation der neuesten Version von Solr (1.3.0) habe ich ein Warnsymbol in Plesk bekommen und es gab mir einen vagen Fehler wie "Der tatsächliche Zustand der Anwendung stimmt nicht mit dem Status überein, der aus der Datenbank abgerufen wurde."

Hier ist der Log-Eintrag:

17. August 2009 23:16:15 org.apache.solr.servlet.SolrDispatchFilter init
INFO: SolrDispatchFilter.init()
17. August 2009 23:16:15 org.apache.solr.core.SolrResourceLoader
locateInstanceDir
INFO: Verwendung von JNDI solr.home: /usr/share/solr
17. August 2009 23:16:15
org.apache.solr.core.CoreContainer$Initializer initialize
INFO: Suche nach solr.xml: /usr/share/solr/solr.xml
17. August 2009 23:16:15 org.apache.solr.core.SolrResourceLoader 
INFO: Solr-Startverzeichnis auf '/usr/share/solr/' festgelegt
17. August 2009 23:16:15 org.apache.solr.core.SolrResourceLoader
createClassLoader
INFO: Verwenden des übergeordneten Classloaders
17. August 2009 23:16:15 org.apache.solr.servlet.SolrDispatchFilter init
SEVERE: SOLR konnte nicht gestartet werden. Überprüfen Sie die solr/home-Eigenschaft
java.lang.ExceptionInInitializerError
       bei org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:117)
       bei org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:69)
       bei org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:221)
       bei org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:302)
       bei org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:78)
       bei org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3635)
       bei org.apache.catalina.core.StandardContext.start(StandardContext.java:4222)
       bei org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
       bei org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
       bei org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
       bei org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
       bei org.apache.catalina.core.StandardService.start(StandardService.java:448)
       bei org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
       bei org.apache.catalina.startup.Catalina.start(Catalina.java:552)
       bei sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       bei sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
       bei sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
       bei java.lang.reflect.Method.invoke(Method.java:616)
       bei org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
       bei org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
Ursache: java.lang.RuntimeException: XPathFactory#newInstance()
konnte keine XPathFactory für das Standardobjektmodell erstellen:
http://java.sun.com/jaxp/xpath/dom mit der
XPathFactoryConfigurationException:
javax.xml.xpath.XPathFactoryConfigurationException: Keine XPathFactory
Implementierung gefunden für das Standardobjektmodell:
http://java.sun.com/jaxp/xpath/dom
       bei javax.xml.xpath.XPathFactory.newInstance(Unbekannter Quelle)
       bei org.apache.solr.core.Config.(Config.java:41)
       ... 20 weitere
17. August 2009 23:16:15 org.apache.catalina.core.StandardContext filterStart
SEVERE: Ausnahme beim Starten des Filters SolrRequestFilter
java.lang.NoClassDefFoundError: Konnte die Klasse nicht initialisieren
org.apache.solr.core.SolrConfig
       bei org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:76)
       bei org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:221)
       bei org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:302)
       bei org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:78)
       bei org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3635)
       bei org.apache.catalina.core.StandardContext.start(StandardContext.java:4222)
       bei org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
       bei org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
       bei org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
       bei org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
       bei org.apache.catalina.core.StandardService.start(StandardService.java:448)
       bei org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
       bei org.apache.catalina.startup.Catalina.start(Catalina.java:552)
       bei sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       bei sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
       bei sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
       bei java.lang.reflect.Method.invoke(Method.java:616)
       bei org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
       bei org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
17. August 2009 23:16:15 org.apache.catalina.core.StandardContext start
SEVERE: Fehler filterStart
17. August 2009 23:16:15 org.apache.catalina.core.StandardContext start
SEVERE: Der Start des Kontexts [/solr] ist aufgrund vorheriger Fehler fehlgeschlagen

Das Verzeichnis solr/home existiert, warum beschwert sich Solr dann darüber?

Answer 1

Ok, hier ist das Problem! Es stellt sich heraus, dass einige Distributionen von Tomcat keinen Verweis auf Xalan haben, von dem die Ausnahme bezüglich XPathFactory stammt. Dieser Fehler kann irreführend sein, weil er den Fehler als ein Problem mit der nicht gesetzten solr/home-Eigenschaft protokolliert. Die Wahrheit ist, dass sie gesetzt wurde. In 9 von 10 Fällen ist ein Problem beim Starten von Solr darauf zurückzuführen, dass das solr/home-Verzeichnis nicht gesetzt ist.

So habe ich es für mich behoben: Ich bin in das /usr/share/tomcat5/shared/lib-Verzeichnis gegangen und habe einen symbolischen Link zur Datei xalan-j2.jar erstellt, die sich im Verzeichnis /usr/share/java befand. Tomcat neu gestartet und Solr startete problemlos!

Weitere Tipps: Bearbeiten Sie die web.xml-Datei in der solr.war-Datei, die Sie entpacken, Ihre Änderung vornehmen und dann wieder verpacken. Legen Sie das Verzeichnis auf etwas wie /usr/share/solr fest. Auf diese Weise, wenn die Protokolle nicht anzeigen, dass es dieses Verzeichnis als solr/home verwendet, stimmt etwas nicht. Stellen Sie außerdem sicher, dass solr/home ungefähr so aussieht:

/usr/share/solr/
/usr/share/solr/bin
/usr/share/solr/bin/rsyncd-stop
/usr/share/solr/bin/abo
/usr/share/solr/bin/scripts-util
/usr/share/solr/bin/snappuller-disable
/usr/share/solr/bin/backupcleaner
/usr/share/solr/bin/snapcleaner
/usr/share/solr/bin/rsyncd-disable
/usr/share/solr/bin/snapinstaller
/usr/share/solr/bin/commit
/usr/share/solr/bin/snappuller-enable
/usr/share/solr/bin/snappuller
/usr/share/solr/bin/backup
/usr/share/solr/bin/rsyncd-start
/usr/share/solr/bin/abc
/usr/share/solr/bin/rsyncd-enable
/usr/share/solr/bin/optimize
/usr/share/solr/bin/snapshooter
/usr/share/solr/bin/readercycle
/usr/share/solr/conf
/usr/share/solr/conf/schema.xml
/usr/share/solr/conf/solrconfig.xml
/usr/share/solr/conf/synonyms.txt
/usr/share/solr/conf/xslt
/usr/share/solr/conf/xslt/example_atom.xsl
/usr/share/solr/conf/xslt/luke.xsl
/usr/share/solr/conf/xslt/example_rss.xsl
/usr/share/solr/conf/xslt/example.xsl
/usr/share/solr/conf/elevate.xml
/usr/share/solr/conf/scripts.conf
/usr/share/solr/conf/protwords.txt
/usr/share/solr/conf/spellings.txt
/usr/share/solr/conf/admin-extra.html
/usr/share/solr/conf/stopwords.txt
/usr/share/solr/README.txt

mit Benutzer:Gruppen-Berechtigungen tomcat:tomcat. Das Datenverzeichnis wird erstellt, wenn Solr ordnungsgemäß gestartet wird.

Hoffentlich spart das jemandem eine Menge Zeit.

Answer 2

Ich bin ziemlich sicher, dass 'solr/home property' nicht ein Verzeichnis namens 'solr/home' bedeutet, sondern eine Umgebungsvariable oder eine Systemeigenschaft ist, die den Pfad des Verzeichnisses enthält.
Eine schnelle Google-Suche ergab diese Seite, auf der die Eigenschaft als eine Java-Systemeigenschaft festgelegt ist: "-Dsolr.solr.home=/my/custom/solr/home/dir/".