: Yes, i've tried that. Building and running Solr with the supplied jar
: works ok, the problem raises when i copy the latest lucene jar. It has
: to be with the created lucene .jar, but i don't know why...
looking back at your stack trace, my gut instinct is that there is
something wrong with your java setup, such that the native code libraries
used to impliment the system classes (specificly the regex functionality)
aren't linked properly (or some other crazy DLL/so mumbojumbo) and you
only get the problem with the lockless commits version because thats when
it started using pattern matching on file names.
...except that as far as i can tell the old version would used pattern
matching too, just not as much. .. hmm, acctually, i take that bcak: the
code to call String.matches to determine what files are part of the
index was there, but i don't acctual see it getting used -- at least not
in the code from your stack trace (opening an index)
thinking about it a bit: before lockless commits there really was only one
purpose for the IndexFileNameFilter, removing all "index" files from a
directory when asked to create a new index ... code that Solr never would
have executed (i don't believe) ... so maybe that is the problem?
Manuel: forget about Solr for a minute, when you compile the Lucnee trunk,
can you run the (Lucene) tests successfully ?
more importantly: does the commandline Lucene demo work for you? can you
run...
java org.apache.lucene.demo.IndexFiles [somepath]
...if i'm write, that will fail if you run it more then once in the same
directory (so that an "index" directory with stuff in it has already been
created when you run it a a second time) ... it should even fail with the
lucene 2.0 release.
(hell: if i'm right, a 1 line hello world class you write that just calls
System.out.println("string".matches("\\d")) would fail the same way)
-Hoss
