You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Erick Erickson <er...@gmail.com> on 2013/08/23 02:34:10 UTC

Of resource loaders, CacheHeaderTest and being puzzled.

I'm working on SOLR-4817 on trunk. The idea there is that if there is no
path to solr.xml, we should fail. That part is easy to do.

Where I'm having trouble is that this causes CacheHeaderTest to fail
miserably. I've fixed other test failures by setting up a Jetty instance by
creating a temporary directory like in other tests and populating it with a
minimal set of config files.

But CacheHeaderTest doesn't succeed if I do that. The glaring difference is
this call:
createJetty("solr/", null, null);

If I create a temp dir that populates a directory (myHome) with solr.xml,
collection1/conf/good stuff and call createJetty(myHome.getAbsolutePath(),
null, null) then the test fails in one of several flavors.

I'm having real trouble figuring out where the hell the configs are read
from when the solrHome of "solr/" comes from, and why it would behave
differently than a full configuration with an absolute path.

Any pointers appreciated. Otherwise I'll just try it again in the morning.

I know this is incoherent, but I'm at my wits end....

Erick

Re: Of resource loaders, CacheHeaderTest and being puzzled.

Posted by Erick Erickson <er...@gmail.com>.
OK, figured out how to make this all work I think.

The take-away here for anyone else is that any behavior that depends on
initializing a test from the test-files directory will probably fail Real
Soon Now, especially in Solr5.x. The pattern is that by starting a Jetty
with a home dir of just "solr/", you wind up getting the default solr.xml
from ConfigSolrXmlOld. But that will no longer work in Solr5, we're
deprecating that functionality. You have to create a directory and copy all
the relevant files in it.

To help, there's a static method SolrTestCaseJ4.copyTestSolrHome that will
copy solr.xml to the root, and all the  necessary files into the
"collection specified"/conf. Currently this includes things like
solrconfig.xml, schema.xml, and support files for schema, currency.xml,
old_synonyms.txt and some others.

This turned out to be necessary, or at least quick, because there are some
interactions between that solrconfig.xml and stuff being tested for in some
cases. There are about 30 tests that fail, I'm not all the way through
fixing them but this is a recurring pattern.

There _should_ be a better way to do this without having to copy all those
files, but I'm leaving that for later.

There's also SolrTestCaseJ4.copyMinConf that takes the absolutely minimal
solrconfig.xml, schema.xml and solrconfig.snippet.randomindexingconfig.xml
files that you can use if you don't need much in the way of configuration
and want to minimize the files copied around.

I expect this to change somewhat as time passes, but it's "progress not
perfection"...

FWIW,
Erick



On Thu, Aug 22, 2013 at 8:34 PM, Erick Erickson <er...@gmail.com>wrote:

> I'm working on SOLR-4817 on trunk. The idea there is that if there is no
> path to solr.xml, we should fail. That part is easy to do.
>
> Where I'm having trouble is that this causes CacheHeaderTest to fail
> miserably. I've fixed other test failures by setting up a Jetty instance by
> creating a temporary directory like in other tests and populating it with a
> minimal set of config files.
>
> But CacheHeaderTest doesn't succeed if I do that. The glaring difference
> is this call:
> createJetty("solr/", null, null);
>
> If I create a temp dir that populates a directory (myHome) with solr.xml,
> collection1/conf/good stuff and call createJetty(myHome.getAbsolutePath(),
> null, null) then the test fails in one of several flavors.
>
> I'm having real trouble figuring out where the hell the configs are read
> from when the solrHome of "solr/" comes from, and why it would behave
> differently than a full configuration with an absolute path.
>
> Any pointers appreciated. Otherwise I'll just try it again in the morning.
>
> I know this is incoherent, but I'm at my wits end....
>
> Erick
>