On 9/6/2015 5:28 AM, Mark Fenbers wrote: > Yes, indeed. Moving core.properties up to the parent directory did the > trick. I also created a lib subdir and copied the postgres jar file and > the Solr import handlers into it -- according to the advice from Kevin > Lee responding to my "Config error mystery" post. This brought me back > to my original problem, which is shown in the log data below (java stack > trace). Perhaps is it an issue with multiple versions of the same jar > as you suggested in your response to "Config error mystery", but the log > (below) does not seem to indicate that it has found a duplicate jar. > Though Solr is running, I am not able to create an index from my > database data. > > What do you make of the information in the log file?
It looks like you have jars in the solrhome/lib directory, which is good. You probably don't need the dataimporthandler jar for -extras if you just want to load from a database. It does appear that you also have <lib> directives in your solrconfig.xml, which are loading after the dataimport jars load. Loading jars from multiple locations complicates the classloader, and has been known to cause a huge number of problems. I don't know if it is why you are having a class cast exception, but it would be my first guess. Since you are using the solrhome/lib directory, you should put ALL jars that you need there, remove all jars from any instanceDir/lib directory, and also remove all <lib> configuration elements from your solrconfig.xml. It looks like the jars that are loading are for Solr 5.3.0. Do you have any jars from another Solr or Lucene version in a directory that might somehow be on the classpath -- loaded into the system java directories via operating system packages or something? There *might* be a problem with jars loading twice. That appears to be causing other problems, described in this issue: https://issues.apache.org/jira/browse/SOLR-6188 If loading the dataimport jar twice IS causing this problem, then you could probably fix it by removing the jars from the solrhome/lib directory and loading them with <lib> elements in solrconfig.xml instead -- this is the opposite of the advice I gave you earlier in this message. I do not like to load jars that way, because each core ends up loading the jars into its own classloader, so for me they would get loaded multiple times ... but it might be a viable workaround, especially if you are not going to have a large number of cores. Thanks, Shawn
