[ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602745#action_12602745 ]
Grant Ingersoll commented on SOLR-572: -------------------------------------- {quote} Grant - The exception is happening because the SpellCheckComponent always passes Solr's own IndexReader when calling the AbstractLuceneSpellChecker#getSuggestions method even when the underlying spell checker is a FileBasedSpellChecker. In that case, since a non-null IndexReader is passed onto Lucene, it tries to create a term on the null field name. That is when the NullPointerException comes up. {quote} Yep, I think I fixed this piece. See also LUCENE-1299 {quote} I think a possible solution can be to add another abstract method with the same signature as Lucene's SpellChecker to the AbstractLuceneSpellChecker and let each sub-class get suggestions on it's own. That way FileBasedSpellChecker will pass the correct IndexReader or a null IndexReader into Lucene appropriately. The AbstractLuceneSpellChecker#getSuggestion will just call the underlying suggest method, get the String[] back and process as it does right now. {quote} Not sure I follow the solution (I understand the problem) Which signature are you suggesting? > Spell Checker as a Search Component > ----------------------------------- > > Key: SOLR-572 > URL: https://issues.apache.org/jira/browse/SOLR-572 > Project: Solr > Issue Type: New Feature > Components: spellchecker > Affects Versions: 1.3 > Reporter: Shalin Shekhar Mangar > Assignee: Grant Ingersoll > Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch > > > Expose the Lucene contrib SpellChecker as a Search Component. Provide the > following features: > * Allow creating a spell index on a given field and make it possible to have > multiple spell indices -- one for each field > * Give suggestions on a per-field basis > * Given a multi-word query, give only one consistent suggestion > * Process the query with the same analyzer specified for the source field and > process each token separately > * Allow the user to specify minimum length for a token (optional) > Consistency criteria for a multi-word query can consist of the following: > * Preserve the correct words in the original query as it is > * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.