On 03/04/2010 05:56 PM, Chris Hostetter wrote:
: The ability to read solr configuration files from the classpath instead of
: solr.solr.home directory.
Solr has always supported this.
When SolrResourceLoader.openResourceLoader is asked to open a resource it
first checks if it's an absolute path -- if it's not then it checks
relative the "conf" dir (under whatever the instanceDir is, ie: Solr Home
in a single core setup), then it checks relative the current working dir
and if it still can't find it it checks via the current ClassLoader.
that said: it's not something that a lot of people have ever taken
advantage of, so it wouldn't suprise me if some features in Solr are
buggy because they try to open files directly w/o utilizing
openResourceLoader -- in particular a quick test of the trunk example
using...
java -Djetty.class.path="./solr/conf" -Dsolr.solr.home=/tmp/new-solr-home -jar
start.jar
...seems to suggest that QueryElevationComponent isn't using openResource
to look for elevate.xml (i set solr.solr.home in that line so solr would
*NOT* attempt to look at "./solr" ... it does need some sort of Solr Home,
but in this case it was a completley empty directory)
-Hoss
I've been trying to think of ways to tackle this. I hate getConfigDir -
it lets anyone just get around the ResourceLoader basically.
It would be awesome to get rid of it somehow - it would make
ZooKeeperSolrResourceLoader so much easier to get working correctly
across the board.
The main thing I'm hung up on is how to update a file - some code I've
seen uses getConfigDir to update files eg you get the content of
solrconfig, then
you want to update it and reload the core. Most other things, I think
are doable without getConfigDir.
QueryElevationComponent is actually sort of simple to get around - we
just need to add an exists method that return true/false if the resource
exists.
QEC just uses getConfigDir to a do an exists on the elevate.xml - if its
not there, it looks in the data dir.
--
- Mark
http://www.lucidimagination.com
