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-Provider eingerichtet. Sie haben dort Plesk installiert (Version 9.2.1) und einer der Nachteile dieses dedizierten Servers ist, dass sie keine Unterstützung für diese Softwarekomponente garantieren, wenn ich irgendetwas AUSSERHALB des Kontrollpanels mache (z.B. SSH verwenden) für eine Aufgabe. 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 das Problem: Nach der Installation der neuesten Version von solr (1.3.0) habe ich ein Warnsymbol in Plesk bekommen und es hat mir einen vagen Fehler angezeigt, wie "Der tatsächliche Status der Anwendung entspricht nicht dem Status, der aus der Datenbank abgerufen wurde."

Hier ist der Protokolleintrag:

17 Aug, 2009 23:16:15 org.apache.solr.servlet.SolrDispatchFilter init
INFO: SolrDispatchFilter.init()
17 Aug, 2009 23:16:15 org.apache.solr.core.SolrResourceLoader locateInstanceDir
INFO: Verwendung von JNDI solr.home: /usr/share/solr
17 Aug, 2009 23:16:15 org.apache.solr.core.CoreContainer$Initializer initialize
INFO: Suche nach solr.xml: /usr/share/solr/solr.xml
17 Aug, 2009 23:16:15 org.apache.solr.core.SolrResourceLoader 
INFO: Solr-Startverzeichnis auf '/usr/share/solr/' festgelegt
17 Aug, 2009 23:16:15 org.apache.solr.core.SolrResourceLoader createClassLoader
INFO: Weiterverwendung des übergeordneten Classloaders
17 Aug, 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: Fehlgeschlagenes Erstellen einer XPathFactory für das Standardobjektmodell: http://java.sun.com/jaxp/xpath/dom mit der XPathFactory-Konfigurationsausnahme: javax.xml.xpath.XPathFactoryConfigurationException: Keine XPathFactory-Implementierung für das Objektmodell: http://java.sun.com/jaxp/xpath/dom gefunden
       bei javax.xml.xpath.XPathFactory.newInstance(Unbekannter Quelle)
       bei org.apache.solr.core.Config.(Config.java:41)
       ... 20 weitere
17 Aug, 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 Aug, 2009 23:16:15 org.apache.catalina.core.StandardContext start
SEVERE: Fehler filterStart
17 Aug, 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 solr/home-Eigenschaft DARSTELLT, DIE NICHT EINGESTELLT IST. Die Wahrheit ist, dass es eingestellt war. In 9 von 10 Fällen liegt ein Problem beim Starten von Solr daran, dass das solr/home-Verzeichnis nicht festgelegt 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 xalan-j2.jar-Datei erstellt, die sich im Verzeichnis /usr/share/java befand. Tomcat neu gestartet und Solr startete sofort!

Weitere Tipps: Bearbeiten Sie die web.xml-Datei im solr.war Archiv, das Sie entpacken, Ihre Änderungen vornehmen und dann wieder einpacken. Legen Sie das Verzeichnis auf etwas wie /usr/share/solr fest. Auf diese Weise, wenn die Logs nicht anzeigen, dass es dieses Verzeichnis als solr/home verwendet, gibt es ein Problem. 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:Gruppe-Berechtigungen als tomcat:tomcat. Das Datenverzeichnis wird erstellt, wenn Solr ordnungsgemäß gestartet wurde.

Hoffentlich wird das jemandem eine Menge Zeit sparen.

Answer 2

Ich bin ziemlich sicher, dass 'solr/home-Eigenschaft' kein Verzeichnis namens 'solr/home' bedeutet, sondern eine Umgebungsvariable oder eine Systemeigenschaft, die den Pfad des Verzeichnisses enthält.
Eine schnelle Google-Suche ergab diese Seite, wo die Eigenschaft als java Systemeigenschaft gesetzt ist: "-Dsolr.solr.home=/mein/angepasstes/solr/home/verzeichnis/".