Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of rcmuir@gmail.com designates
 209.85.214.48 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=TvmvMTfYIHzaHET9+gLgHoK4ygFOa3NENvszOByw6Wk7Jvd+r26d7iz0abZ09Nh/ot
         tBWmoKAh0cOY8lHypkM8m7hvInRhDcpYD8sENrqgODqAEXrsCMhtcQF9wn6VUpDA+yzs
         +bc1JKNZfHkAxMPBkvnZXrHOTjdQ/6fcZA3o0=
MIME-Version: 1.0
In-Reply-To: <FC7FC020-EC8F-4FA2-940E-5299A7A60134@basistech.com>
References: <45634479-520B-4BA7-98CE-BE0486F98E58@basistech.com>
 <AANLkTin4HfrXGkxZhu4B7oR3Lg57nNALJfMFmuTzhyFp@mail.gmail.com>
 <FC7FC020-EC8F-4FA2-940E-5299A7A60134@basistech.com>
From: Robert Muir <rcmuir@gmail.com>
Date: Sat, 4 Dec 2010 18:22:09 -0500
Message-ID: <AANLkTikC7t27o0UCnnP_knUy1tq98qStcdkXkkKVgwLe@mail.gmail.com>
Subject: Re: PayloadAttribute behavior change between Lucene 2.9/3.0 and the
 trunk
To: java-user@lucene.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Dec 4, 2010 at 6:05 PM, Teruhiko Kurosaka <Kuro@basistech.com> wrot=
e:
> Thank you, Robert, substituting getAttribute with addAttribute worked!
>
> But I don't understand why. =C2=A0Could you help me to understand the mec=
hanics?
>
> In my setting,
> hasAttribute(PayloadAttribute.class) returns false.
>
> So I thought addAttribute(PayloadAttribute.class) would just
> create a new PayloadAttribute object. =C2=A0It would remedy the
> Exception, but it wouldn't do any good accessing the payload
> generated upstream.
>
> But the newly generated PayloadAttribute t is actually
> getting the payload that was generated upstream (by my Tokenizer).
> How is this possible?

Attributes are shared for the entire analysis chain.
It is best to think of getAttribute as "get a reference to an
already-added attribute".

And to think of addAttribute as "if the attribute already exists,
return a reference to it, otherwise add it to the chain and return a
reference to that".

In other words, in the entire Analyzer, there can only be one
PayloadAttribute. Because it is shared, it does not matter who calls
addAttribute.

So, its best to always use addAttribute in your constructor.

The simplest way to see why this is good: imagine if someone was to
use your TokenFilter with say a WhitespaceTokenizer that does not add
PayloadAttribute. Then your filter would not produce any error, the
PayloadAttribute would just be empty as you expect.

The reason your code worked with getAttribute in Lucene 2.9 is to
provide backwards-compatibility with the Token API:  the 6 attributes
from Token were always automatically added: TermAttribute,
OffsetAttribute, PositionIncrementAttribute, PayloadAttribute,
TypeAttribute, FlagsAttribute. You can see this by looking at
TokenStream.initTokenWrapper:
http://svn.apache.org/repos/asf/lucene/java/branches/lucene_2_9/src/java/or=
g/apache/lucene/analysis/TokenStream.java

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org