Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Message-ID: <9442703.377411281995176464.JavaMail.jira@thor>
Date: Mon, 16 Aug 2010 17:46:16 -0400 (EDT)
From: "Yonik Seeley (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Subject: [jira] Commented: (SOLR-2051) analysis.jsp is incorrect for
 protWords etc
In-Reply-To: <13937528.370151281981627820.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/SOLR-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12899109#action_12899109 ] 

Yonik Seeley commented on SOLR-2051:
------------------------------------

Ah, yeah, good catch!

bq. i wonder if we can use tee/sinks to do this cleaner?

Insert a tap after each filter?  Yeah, might be safer by more closely emulating how the analysis actually works.
For example, if someone develops some whacky filters that rely on thread locals to pass info or something.

Since it looks like you've fixed it already, I'd just commit that though.

> analysis.jsp is incorrect for protWords etc
> -------------------------------------------
>
>                 Key: SOLR-2051
>                 URL: https://issues.apache.org/jira/browse/SOLR-2051
>             Project: Solr
>          Issue Type: Bug
>          Components: web gui
>    Affects Versions: 3.1, 4.0
>            Reporter: Robert Muir
>         Attachments: SOLR-2051.patch, SOLR-2051.patch
>
>
> Analysis.jsp gives the incorrect results if you use "protwords.txt" or "stemdict.txt" or the like.
> This is because this is now implemented with KeywordAttribute (so you can easily override any stemmer etc).
> For example, if your schema had "foobars" in protwords.txt, analysis.jsp would show it being stemmed to "foobar", even though this doesnt actually happen.
> The problem is that this jsp is downconverting the entire tokenstream to Token in between processing, so it silently discards KeywordAttribute and you get the wrong result.
> Note: this issue isnt about *displaying* other attributes such as KeywordAttribute (which would be a new feature). Its about not throwing them away so that the analysis actually represents what happens.

-- 
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