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

Uwe Schindler updated LUCENE-2374:
----------------------------------

    Attachment: shot2.png
                shot1.png
                LUCENE-2374-3x.patch

New patch with analysis.jsp fixed (also SOLR-2315):
- highlighting works again
- only attributes are shown that exist at the step of analysis
- attribute names changed a little bit, because it uses the ones from 
reflection api
- Attribute class name shown in mouse hover
- start/endOffset now in two different lines (no chance to do it other without 
another special case)
- payloads are no longer printed as text, because it used default platform 
encoding (new String(byte[]))!

I also added some example screenshots!

> 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, shot1.png, 
> shot2.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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to