[
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
