[ https://issues.apache.org/jira/browse/LUCENE-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Uwe Schindler updated LUCENE-2374: ---------------------------------- Attachment: LUCENE-2374-3x.patch Final patch for 3.x: - Added some tests for reflection API - Added test for sophisticated backwards layer I will commit this tomorrow and forward-port to trunk. Contrib/queryparsers attributes are not yet compatible with reflection, as the toString() there has wrong format (throws UOE). I will open a separate issue to fix that, this is not a serious problem at the moment, as attribute reflection is not needed there. > 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, 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org