[ https://issues.apache.org/jira/browse/LUCENE-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759575#action_12759575 ]
Robert Muir commented on LUCENE-1926: ------------------------------------- Uwe, what you are saying is true (its really a bug in my filter and I agree you should cancel this as won't fix, any javadoc clarification might prevent someone else from doing this). One side note I worry about a bit now, is the possibility of similar bugs might exist or crop up somewhere like shingle... but the tests might pass and they appear to be working > Back compat break with old next() consumer API > ---------------------------------------------- > > Key: LUCENE-1926 > URL: https://issues.apache.org/jira/browse/LUCENE-1926 > Project: Lucene - Java > Issue Type: Bug > Components: Analysis > Affects Versions: 2.9 > Reporter: Robert Muir > Attachments: CaptureStateTestcase.java > > > There is a bug that causes tokenstreams to return different results, > depending upon whether they are consumed with the incrementToken() api or the > next() api. > I found this because the Solr analysis tool in the admin page uses the next() > api, and i was seeing strange results. > I've created a test case to show the problem. when calling captureState(), > the current state is erased, but only when consuming with the next() api. > If I consume with incrementToken(), things work. > {code} > State tempState = captureState(); // after we capture state here, things get > strange. > String right = termAtt.term(); // when using old consumer API, this value is > wrong!!!! > {code} -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org