[ https://issues.apache.org/jira/browse/LUCENE-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759582#action_12759582 ]
Uwe Schindler commented on LUCENE-1926: --------------------------------------- bq. 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 Shingle was reviewed and changed by me, I think this one is OK. The problem you described could have been catched by backwards tests, but these are only running for core, not contrib. > 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