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

Robert Muir commented on LUCENE-2374:
-------------------------------------

What are your thoughts here Uwe?

Should we fix for 3.1 or leave till 3.2?

It does seem good if we could possibly fix for 3.1 due to the fact toString() 
was the only
real introspection we had before?

But at the same time, Solr's analysis.jsp etc doesn't introspect attributes 
outside of the
original 6 in Token anyway, so maybe we could delay?




> Add introspection 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
>
>
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to