[ 
https://issues.apache.org/jira/browse/LUCENE-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benson Margulies updated LUCENE-5202:
-------------------------------------

    Description: 
This is a bit hard to explain except by looking at the test case. I've coded a 
filter that uses LookaheadTokenFilter. The incrementToken method peeks some 
tokens. Then, it seems, nextToken in the Lookahead class calls peekToken 
itself, which seems to me to consume a token so that it's not seen when the 
derived class sets out to process the next set of tokens.

In passing, this test case can be used to demonstrate that it does not work to 
try to use the afterPosition method to set up attributes of the token that 
we're 'after'. Probably that was never intended. However, I'm hoping for some 
feedback as to whether the rest of the structure here is as intended for 
subclasses of LookaheadTokenFilter.

  was:
I will attach a patch including a unit test that demonstrates this.

In addition, there will be a test case in which the token book-keeping seems to 
go wrong.


    
> LookaheadTokenFilter consumes an extra token in nextToken
> ---------------------------------------------------------
>
>                 Key: LUCENE-5202
>                 URL: https://issues.apache.org/jira/browse/LUCENE-5202
>             Project: Lucene - Core
>          Issue Type: Bug
>    Affects Versions: 4.3.1
>            Reporter: Benson Margulies
>         Attachments: LUCENE-5202.patch
>
>
> This is a bit hard to explain except by looking at the test case. I've coded 
> a filter that uses LookaheadTokenFilter. The incrementToken method peeks some 
> tokens. Then, it seems, nextToken in the Lookahead class calls peekToken 
> itself, which seems to me to consume a token so that it's not seen when the 
> derived class sets out to process the next set of tokens.
> In passing, this test case can be used to demonstrate that it does not work 
> to try to use the afterPosition method to set up attributes of the token that 
> we're 'after'. Probably that was never intended. However, I'm hoping for some 
> feedback as to whether the rest of the structure here is as intended for 
> subclasses of LookaheadTokenFilter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to