For the reflection way, I use a configuration file that specifies the initial state and then use a no-argument constructor. Since I don't think that is very generalizable, I thought maybe you could do a copy() and then a reset() method (similar to the JSP tag release() method). The copy() method would create a new memory object. Then reset would put itself back into a clean state. Many of the filters have read-only information (such as the Stop filter), so reset wouldn't have to do anything. Other's may require more, such as preserving the initialization state (which will take up extra memory). I don't know if this is a generalizable process or if it is worth the effort. The reflection way works well for me b/c I am already using a configuration file, so a few more properties aren't a big deal. One of the things that is nice about Lucene is it doesn't require a configuration file.
Not sure if this is enough to go, so let me know. -Grant >>> [EMAIL PROTECTED] 06/15/04 05:04AM >>> > The jist of it is it isn't thread safe yet. Although I don't > think it is too much of a leap to make it thread-safe. I just > haven't had time to do so. It can be done through reflection > or perhaps by requiring a "deep" copy/reset of filter states. I had a quick look and found that using reflection would be complicated as some TokenFilters need extra objects at construction time like a charset[](RussianStemFilter) or a HashSet of stopWords (StopFilter). Do you see a simple way around this? What were your thoughts for the "deep" copy/reset you mention? Regards, RBP --------------------------------------------------------------------- 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]
