Hey Guys,
Ok, I found this:
Troubleshooting Errors
It's possible that you get an error related to the following:
SEVERE: Exception starting filter SolrRequestFilter
java.lang.NoClassDefFoundError: Could not initialize class
org.apache.solr.core.SolrConfig
at
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:76)
.........
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.x
path.XPathFactoryConfigurationException: No XPathFctory implementation
found for the object model: http://java.sun.com/jaxp/xpath/dom
at javax.xml.xpath.XPathFactory.newInstance(Unknown Source)
This is due to your tomcat instance not having the xalan jar file in
the classpath. It took me some digging to find this, and thought it
might be useful for others. The location varies from distribution to
distribution, but I essentially just added (via a symlink) the jar
file to the shared/lib directory under the tomcat directory.
I am a java n00b. How can I set this up?
On Tue, Aug 18, 2009 at 10:16 PM, Chris
Hostetter<hossman_luc...@fucit.org> wrote:
>
> : -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
>
>
