Return-Path: Delivered-To: apmail-lucene-dev-archive@www.apache.org Received: (qmail 10801 invoked from network); 19 Oct 2010 16:06:54 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 19 Oct 2010 16:06:54 -0000 Received: (qmail 76262 invoked by uid 500); 19 Oct 2010 16:06:53 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 76100 invoked by uid 500); 19 Oct 2010 16:06:52 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 76093 invoked by uid 99); 19 Oct 2010 16:06:52 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Oct 2010 16:06:52 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of serera@gmail.com designates 74.125.82.176 as permitted sender) Received: from [74.125.82.176] (HELO mail-wy0-f176.google.com) (74.125.82.176) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Oct 2010 16:06:46 +0000 Received: by wyg36 with SMTP id 36so1449199wyg.35 for ; Tue, 19 Oct 2010 09:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=3qdE9vQTp9/5jSD4Xg8QS27X92Q5fk6sBets4J21hgo=; b=xPWR0IGt6EsqRIICz7x2qoh1a1A5Id0deGQDNGQIzUUZPpJESpV7Mxc8JuaPOBRudZ n9utJANNQG4KYieXjJ4WfzL0iWEiKLLREGy8/tqVzR57u09kmvJsyfcWds4rqW/tp6jH GvE1awHa1f/sMDxU4s1BEWdrhZgILjxs6iA2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=If/n3f1HHN/POOLPUz7PiPV+qcPoMuQ2kSUYef3z8psPsKVed4eQBXexHSqaWUsfhO +Bq/wcG/VuY0QIAsZvSjpyAsPlS+jFZuOmK9IGyfa/oqUiRjlsGM0SQGN8+X6O+8XJbA 4GlilmTVOC/z5DyRSwr4XrIXrZDvYHSmvGOTo= MIME-Version: 1.0 Received: by 10.227.138.132 with SMTP id a4mr16715wbu.171.1287504385678; Tue, 19 Oct 2010 09:06:25 -0700 (PDT) Received: by 10.216.178.146 with HTTP; Tue, 19 Oct 2010 09:06:25 -0700 (PDT) In-Reply-To: <005d01cb6fa6$aed9ba70$0c8d2f50$@thetaphi.de> References: <005d01cb6fa6$aed9ba70$0c8d2f50$@thetaphi.de> Date: Tue, 19 Oct 2010 18:06:25 +0200 Message-ID: Subject: Re: Analyzer forcing tokenStream and reusableTokenStream to be final From: Shai Erera To: dev@lucene.apache.org Content-Type: multipart/alternative; boundary=001636832f188e3f6d0492fa7904 X-Virus-Checked: Checked by ClamAV on apache.org --001636832f188e3f6d0492fa7904 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I guess you didn't read my email all the way through - I cannot disable assertions for Lucene stuff because I use Lucene's assertions to assert tha= t my indexing code works :). Shai On Tue, Oct 19, 2010 at 5:59 PM, Uwe Schindler wrote: > We simply added that to **test** the bundled analyzers for conformance. I= f > you don=92t like that, you can simply disable assertions for the > org.apache.lucene package. > > > > ----- > > Uwe Schindler > > H.-H.-Meier-Allee 63, D-28213 Bremen > > http://www.thetaphi.de > > eMail: uwe@thetaphi.de > > > > *From:* Shai Erera [mailto:serera@gmail.com] > *Sent:* Tuesday, October 19, 2010 5:53 PM > *To:* dev@lucene.apache.org > *Subject:* Re: Analyzer forcing tokenStream and reusableTokenStream to be > final > > > > I still don't understand how not declaring my tokenStream and > reusableTokenStream final can break anything. The methods are there (in m= y > analyzers), and if I risk overriding them somewhere else it's my problem. > > What am I missing? > > To add to your email - I too didn't encounter an analyzer that cannot be > reused, yet. > > Shai > > On Tue, Oct 19, 2010 at 5:45 PM, Robert Muir wrote: > > On Tue, Oct 19, 2010 at 11:21 AM, Robert Muir wrote: > > If someone doesn't override both (e.g. they just override > > tokenStream), then it wouldnt actually use their subclasses code. So > > then the reflection hack from LUCENE-1678 would force the analyzer to > > never re-use, but instead call tokenStream: but this is very bad for > > indexing performance! > > > > Here's a jira issue with an example of how the > tokenstream/reusableTokenStream confusion makes this a real problem in > practice: > > https://issues.apache.org/jira/browse/LUCENE-2279 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org > For additional commands, e-mail: dev-help@lucene.apache.org > > > --001636832f188e3f6d0492fa7904 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I guess you didn't read my email all the way through -= I cannot disable assertions for Lucene stuff because I use Lucene's as= sertions to assert that my indexing code works :).

Shai

On Tue, Oct 19, 2010 at 5:59 PM, Uwe Schindler <uwe@thetaphi.de> wrote:

W= e simply added that to *test* the bundled analyzers for conformance.= If you don=92t like that, you can simply disable assertions for the org.ap= ache.lucene package.

=A0

-----

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

http://ww= w.thetaphi.de

eMail: uwe@thetaphi.de

=A0

From: Shai Erera = [mailto:serera@gmail.= com]
Sent: Tuesday, October 19, 2010 5:53 PM
To: dev@lucene.apache.org
<= b>Subject: Re: Analyzer forcing tokenStream and reusableTokenStream to = be final

=A0

I still don'= ;t understand how not declaring my tokenStream and reusableTokenStream fina= l can break anything. The methods are there (in my analyzers), and if I ris= k overriding them somewhere else it's my problem.

What am I missing?

To add to your email - I too didn't encou= nter an analyzer that cannot be reused, yet.

Shai

On Tue, Oct 19, 2010 at 5:45 PM, Robert Muir <rcmuir@gmail.com> wrote:<= /p>

On Tue, Oct 19, = 2010 at 11:21 AM, Robert Muir <rcmuir@gmail.com> wrote:
> If someone doesn't= override both (e.g. they just override
> tokenStream), then it wouldnt actually use their subclasses code. So> then the reflection hack from LUCENE-1678 would force the analyzer t= o
> never re-use, but instead call tokenStream: but this is very bad = for
> indexing performance!
>

Here'= ;s a jira issue with an example of how the
tokenstream/reusableTokenStre= am confusion makes this a real problem in
practice:

https://= issues.apache.org/jira/browse/LUCENE-2279


-------= --------------------------------------------------------------
To unsubs= cribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

<= p class=3D"MsoNormal">=A0


--001636832f188e3f6d0492fa7904--