lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Applet search
Date Thu, 08 Aug 2002 12:58:49 GMT
Thanks, Jakob.

Yes, I did spot that one -- the final solution seemed to be to copy the
index files to a RAMDirectory so that the lock file could safely be written.

There was also a thread about "Read only filesystem" which created a new
FSDirectory class that doesn't write lock files.

Neither seem to be a particularly direct solution. (Eg the read-only file
system only needs to differ from FSDirectory in a couple of places, but
because FSDirectory is declared final, the only way to do so is by copying
large chunks of code.)

For the moment, I've just hacked my version of the Lucene source and
commented out the two lines which create and delete the lock file. That
works fine, but it means I've become a "Lucene developer", not a "Lucene
user", and I'll have to keep redoing the same hack for each release of
Lucene. I'd like to find a more elegant solution!


Educational Software, LTS

-----Original Message-----
From: Skansen [] 
Sent: 07 August 2002 18:08
To: Lucene Users List
Subject: Re: Applet search

Have you looked at the thread: lucene in applet ?

It was back in nowember 2001.

----- Original Message ----- 
From: <>
To: <>
Sent: Tuesday, August 06, 2002 12:57 PM
Subject: Applet search

> I've been investigating using Lucene to search html pages on CD-ROM, 
> using an applet as the search interface. It isn't as easy as I'd 
> hoped...
> One problem is that lock files are written while searching to prevent 
> concurrent updates of the index -- clearly that doesn't work too well 
> on read-only media! But I notice there are current changes which will 
> make the use of lock files configurable.
> Another problem is security restrictions on applets. Unfortunately one 
> of these is not being able to read system properties and the new 
> mechanism for turning off lock files uses a system property, so that 
> ain't going to work well in my case...
> So I've been looking at plans B, C, D, ... These would mean writing 
> some new classes to specialise the existing Lucene classes to my 
> particular case (eg a version of IndexReader that doesn't use a lock). 
> But I'm not making much progress here since I can't extend classes 
> because they are final or because they have package access.
> Writing an application to do the same job was straightforward and 
> gives a good product, so I feel I should persevere. But I do feel that 
> everything I try goes across the grain of existing code.
> Anyone got any thoughts? I would have thought that the scenario (html 
> on CD-ROM + applet search) was a natural one for Lucene.  I've 
> searched the archives and found several people trying to do it, but 
> not much in the way of solutions.
> Jon
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail: 
> <>

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message