[ https://issues.apache.org/jira/browse/LUCENE-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759606#action_12759606 ]
Robert Muir commented on LUCENE-1926: ------------------------------------- bq. It should simply call clearAttributes() before each incrementToken(). my thoughts too, this causes my test to fail with incrementToken, exposing the bug. I will update your patch with this one-liner once i let ant test finish, just to make sure it doesnt break the build and there arent any similar bugs somewhere in 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, LUCENE-1926.patch > > > 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