[jira] Issue Comment Edited: (LUCENE-2374) Add reflection API to AttributeSource/AttributeImpl

["Uwe Schindler (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LUCENE-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983781#action_12983781 ] 

Uwe Schindler edited comment on LUCENE-2374 at 1/19/11 11:35 AM:
-----------------------------------------------------------------

First preview of trunk patch:

- Removed useless equals() and hashCode() from internal attributes
- Removed backwards layer from previous patch / contrib-qp needs no special handling anymore

Solr:

- Removed deprecated AnalysisRequestHandler instead of fixing it - still test need to be cleaned up
- (Field|Document)AnalysisRequestHandler now works primarily on BytesRef, especially for highlighting
- Using BytesRef to wrap Payloads to easy print them as hex using BytesRef.toString()
- There is still one analysis test failing: as NumericTermAttribute does not support cloning, analysis does not work and test fails. I will now open another issue to fix this (make NumericTermAttribute decoupled from outer TokenStream).


      was (Author: thetaphi):
    First preview of trunk patch:
- Removed useless equals() and hashCode() from internal attributes
- Removed backwards layer from previous patch / contrib-qp needs no special handling anymore
Solr:
- Removed deprecated AnalysisRequestHandler instead of fixing it - still test need to be cleaned up
- (Field|Document)AnalysisRequestHandler now works primarily on BytesRef, especially for highlighting
- Using BytesRef to wrap Payloads to easy print them as hex using BytesRef.toString()
- There is still one analysis test failing: as NumericTermAttribute does not support cloning, analysis does not work and test fails. I will now open another issue to fix this (make NumericTermAttribute standalone).

  
> Add reflection API to AttributeSource/AttributeImpl
> ---------------------------------------------------
>
>                 Key: LUCENE-2374
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2374
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: contrib/analyzers
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>             Fix For: 3.1, 4.0
>
>         Attachments: LUCENE-2374-3x.patch, LUCENE-2374-3x.patch, LUCENE-2374-3x.patch, LUCENE-2374-3x.patch, LUCENE-2374-3x.patch, LUCENE-2374-3x.patch, LUCENE-2374.patch, shot1.png, shot2.png, shot3.png, shot4.png
>
>
> AttributeSource/TokenStream inspection in Solr needs to have some insight into the contents of AttributeImpls. As LUCENE-2302 has some problems with toString() [which is not structured and conflicts with CharSequence's definition for CharTermAttribute], I propose an simple API that get a default implementation in AttributeImpl (just like toString() current):
> - Iterator<Map.Entry<String,?>> AttributeImpl.contentsIterator() returns an iterator (for most attributes its a singleton) of a key-value pair, e.g. "term"->"foobar","startOffset"->Integer.valueOf(0),...
> - AttributeSource gets the same method, it just concat the iterators of each getAttributeImplsIterator() AttributeImpl
> No backwards problems occur, as the default toString() method will work like before (it just gets iterator and lists), but we simply remove the documentation for the format. (Char)TermAttribute gets a special impl fo toString() according to CharSequence and a corresponding iterator.
> I also want to remove the abstract hashCode() and equals() methods from AttributeImpl, as they are not needed and just create work for the implementor.

-- 
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org