I don't use tomcat, so I can't be particularly useful. The behavior you
describe does not happen with resin or jetty...
My guess is that tomcat is caching the error state. Since fixing the
problem is outside the webapp directory, it does not think it has
changed so it stays in a broken state.
if you "touch" the .war file, does it restart ok?
but i'm just guessing...
[EMAIL PROTECTED] wrote:
Hi,
I just started playing around with Solr 1.2. It has some nice improvements.
I noticed that errors in the schema.xml get reported in a verbose way now, but
the following steps cause a problem for me:
1. start with a correct schema.xml - Solr works fine
2. edit it in a way that is no longer correct (say, remove the </schema> closing
tag - Solr works fine
3. restart the webapp (through the Tomcat manager interface) - Solr complains
that the schema.xml does not parse, fine.
4. now restart again (without fixing the schema.xml!) - Solr won't even start up
5. fix the above problem (add the closing tag) and restart via Tomcat's manager
- the webapp cannot restart showing that there is a problem:
FAIL - Application at context path /furness could not be started
The following steps might seem artificial, but assume you don't manage to fix
all the typos in your schema.xml for the first attempt. It seems after restart
Solr gets stuck in some state and I cannot get it up and running by Tomcat's
manager, only by restarting Tomcat.
Am I missing something?
Thanks,
mirko
