I can submit a patch to add the IndexReader.reopen() method. BUT, I think the requested change to SegmentReader is still valid, for the reasons cited in the previous email.
There is already support for replacing the SegmentReader impl at runtime with System properties, but without the SegmentReader changes I think it is next to impossible to have any worthwhile subclass - except for "maybe" method logging, so either the runtime replacement code should be removed, or the changes made. Currently there just isn't a way for the subclass to know ANYTHING, since all of the initialization methods called by the static factory method are private. -----Original Message----- From: Doug Cutting [mailto:[EMAIL PROTECTED] Sent: Monday, May 01, 2006 6:03 PM To: java-dev@lucene.apache.org Subject: Re: SegmentReader changes? Robert Engels wrote: > Correct - changing SegmentReader would be best, but in the past, getting > proposed patches included has been slower than expected. I'm sorry if the process has been frustrating to you in the past. I hope your experiences are better in the future. > So, by making the > SegmentReader more easily subclassed (which should hopefully get approved > quicker), I can still have a "build" of Lucene that does not require > patching any files. (just including classes in the appropriate package to > access package level vars/methods). Aren't we discussing a change to IndexReader, adding a new method? This is not a contrib module, but a change to the core. So proposing it as a patch file that changes existing classes is the normal course. I don't think we ought to be in the pracice of making changes in order to support easier access to non-public APIs. Doug --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
