Sure! shall I fix it on 2.4.1 as well? If so, how soon can we tag a 2.4.2?
If not before 2.9, then it doesn't matter, at least to me, if it will be
fixed on trunk only.

On Thu, Aug 13, 2009 at 3:20 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> Let's just allow null?  Can you open an issue?
>
> Mike
>
> On Thu, Aug 13, 2009 at 6:18 AM, Shai Erera<ser...@gmail.com> wrote:
> > Hi
> >
> > I have an Analyzer which is given a Config object and when tokenStream or
> > reusableTokenStream is called, it generates a TokenStream based on the
> > Config settings. I also have a setConfig method on that Analyzer.
> setConfig
> > calls setPreviousTokenStream(null) so that next time reusableTokenStream
> is
> > called, it will generate a new one, based on the new Config.
> >
> > Before CloseableThreadLocal, this worked just fine. But now it fails on
> > CTL's assert that the object held by the WeakReference is not null, w/ a
> > comment "this cannot be null because we set it ...".
> >
> > I don't have access to tokenStreams member since it's private, therefore
> I
> > can't just tokenStream = new CloseableThreadLocal(). Why doesn't
> > CloseableThreadLocal allow for null objects? ThreadLocal allows it. Also,
> I
> > think CTL is not consistent, since when I call set(null) it allows the
> call,
> > but get() throws an exception.
> >
> > I can overcome this by setting a new object which its tokenizer and
> > tokensteam members are null, and check those instead of the object
> returned
> > from get(). But I don't think CTL should forbid null, or at least make
> sure
> > a null cannot be set.
> >
> > What do you think?
> >
> > Shai
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-dev-h...@lucene.apache.org
>
>

Reply via email to