: -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

Reply via email to