: -Dsolr.solr.home='/some/path' : : Should I be putting that somewhere? Or is that already taken care of : when I edited the web.xml file in my solr.war file?
No ... you do not need to set that system property if you already have it working because of modifications to the web.xml ... according to the log you posted earlier, Solr is seeing your solr home dir set correctly... Aug 17, 2009 11:16:15 PM org.apache.solr.core.SolrResourceLoader locateInstanceDir INFO: Using JNDI solr.home: /usr/share/solr Aug 17, 2009 11:16:15 PM org.apache.solr.core.CoreContainer$Initializer initialize INFO: looking for solr.xml: /usr/share/solr/solr.xml Aug 17, 2009 11:16:15 PM org.apache.solr.core.SolrResourceLoader <init> INFO: Solr home set to '/usr/share/solr/' ...that's were you want it to point, correct? (don't be confused by the later message of "Check solr/home property" ... that's just a hint because 9 times out of 10 an error initializing solr comes from solr needing to *guess* about the solr home dir) The crux of your error is being able to load an XPathFactory, the fact that it can't load an XPath factory prevents the your classloader from even being able to load the SolrConfig class -- note this also in the log you posted earlier... java.lang.NoClassDefFoundError: Could not initialize class org.apache.solr.core.SolrConfig ...the root of the problem is here... Caused by: java.lang.RuntimeException: XPathFactory#newInstance() failed to create an XPathFactory for the default object model: http://java.sun.com/jaxp/xpath/dom with the XPathFactoryConfigurationException: javax.xml.xpath.XPathFactoryConfigurationException: No XPathFctory implementation found for the object model: http://java.sun.com/jaxp/xpath/dom at javax.xml.xpath.XPathFactory.newInstance(Unknown Source) at org.apache.solr.core.Config.<clinit>(Config.java:41) XPathFactory.newInstance() is used to construct an instance of an XPathFactory where the concrete type is unknown by the caller (in this case: solr) There is an alternte form (XPathFactory.newInstance(String uri)) which allows callers to specify *which* model they want, and it can throw an exception if the model isn't available in the current JVM using reflection, but if you read the javadocs for hte method being called... http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/xpath/XPathFactory.html#newInstance() Get a new XPathFactory instance using the default object model, DEFAULT_OBJECT_MODEL_URI, the W3C DOM. This method is functionally equivalent to: newInstance(DEFAULT_OBJECT_MODEL_URI) Since the implementation for the W3C DOM is always available, this method will never fail. ...except that in your case, it is in fact clearly failing. which suggests that your hosting provider has given you a crapy JVM. I have no good suggestions for debugging this, other then this google link... http://www.google.com/search?q=+No+XPathFctory+implementation+found+for+the+object+model%3A+http%3A%2F%2Fjava.sun.com%2Fjaxp%2Fxpath%2Fdom The good new is, there isn't anything solr specific about this problem. Any servlet container giving you that error when you load solr, should cause the exact same error with a servlet as simple as this... public class TestServlet extends javax.servlet.http.HttpServlet { public static Object X = javax.xml.xpath.XPathFactory.newInstance(); public void doGet (javax.servlet.http.HttpServletRequest req, javax.servlet.http.HttpServletResponse res) { // NOOP } } ...which should provide you with a nice short bug report for your hosting provider. One last important note (because it may burn you once you get the XPath problem resolved). you mentioned this before... : > Here is my solr home file list with permissions: : > : > -bash-3.2$ ll /usr/share/solr/* : > -rw-r--r-- 1 tomcat tomcat 2150 Aug 17 22:51 /usr/share/solr/README.txt : > : > /usr/share/solr/bin: ... that all looks fine, but the information is incomplete. you didn't include the permisions for the directories themselves (/usr/share/solr, /usr/share/solr/conf, and /usr/share/solr/bin) they need to be readable by tomcat (they probably are) but most importantly /usr/share/solr needs to be writable by tomcat so that solr can create the data directory for you. -Hoss