Re: IndexFileNames

Doug Cutting wrote: [EMAIL PROTECTED] wrote: --- lucene/java/trunk/src/java/org/apache/lucene/store/FSDirectory.java (original) +++ lucene/java/trunk/src/java/org/apache/lucene/store/FSDirectory.java Mon Jun 6 10:52:12 2005 @@ -52,8 +52,8 @@ if (name.endsWith("."+IndexReader.FILE

RE: Error Initializing an FSDirctory - disableLuceneLocks is null (FollowUp)

The error we get is NoClassDefFoundError at org.apache.lucene.index.IndexReader.open(IndexReader.java:95); It's breaking because the method that gets the disableLuceneLocks is returning null, but here's the weird thing. The product has been running 7x24 for the last 6 months without any problem.

Re: svn-commit: 168449 FSDirectory

Bernhard Messer wrote: Therefore i would like to propose two changes: 1) we should store the extension in a hash and not in String[] to have a faster lookup Do you mean to use something like: String lastDot = name.lastIndexOf('.'); if (lastDot >= 0) { String nameExt = name.substring(lastDot

IndexFileNames

[EMAIL PROTECTED] wrote: --- lucene/java/trunk/src/java/org/apache/lucene/store/FSDirectory.java (original) +++ lucene/java/trunk/src/java/org/apache/lucene/store/FSDirectory.java Mon Jun 6 10:52:12 2005 @@ -52,8 +52,8 @@ if (name.endsWith("."+IndexReader.FILENAME_EXTENSIONS[i]))

Re: svn-commit: 168449 FSDirectory

Hi Daniel, i just had a look at the new implementation that FSDirectory deletes lucene related files only. I like the patch, but i think we left some room for optimization. In the current implementation, it's necessary to run thru all known Lucene extensions (13 for the moment), for each call

Re: svn commit: r180010 - in /lucene/java/trunk/src: java/org/apache/lucene/index/IndexReader.java java/org/apache/lucene/index/SegmentInfos.java test/org/apache/lucene/index/TestIndexReader.java

Daniel, i would suggest to remove the deprecated flags from methods "getCurrentVersion()" and "lastModified()". Even if "lastModified()" returns a value which is operating system dependend, we should leave it up to the developer to use it or not. If we do not provide such a functionality, peo

DO NOT REPLY [Bug 35241] New: - MultiSearcher fails on WildCardQuery

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: Error Initializing an FSDirctory - disableLuceneLocks is null (FollowUp)

Craig, what kind of error did you get when initializing FSDirectory ? The fact that Boolean.getBoolean("disableLuceneLocks") returns false or that the system property "disableLuceneLocks" is null is not an error. It will be null, as long as you do not specify the system parameter with -Ddis

RE: Error Initializing an FSDirctory - disableLuceneLocks is null (FollowUp)

We've been getting an error when trying to initialize an FSDirectory. It's on line 48 of the FSDirectory source file. The system property disableLuceneLocks is null. Now we could set this manually, but it was working up until about a week ago when we moved our Lucene Wrapper class to a new packa

Error Initializing an FSDirctory - disableLuceneLocks is null

We've been getting an error when trying to initialize an FSDirectory. It's on line 48 of the FSDirectory source file. The system property disableLuceneLocks is null. Now we could set this manually, but it was working up until about a week ago when we moved our Lucene Wrapper class to a new pac

Re: patch: adding IndexReader.isCurrent()

Method isCurrrent() is a useful addition and I'm glad fix with timestamp use for initial version is finally commited. However, although version is not meaningful, I believe it should stay in API... The software I'm working on is using pair "version, document_id" as a fast reference to lucene docum