You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Shai Erera <se...@gmail.com> on 2009/08/13 12:18:25 UTC
CloseableThreadLocal does not allow a null object?
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
Re: CloseableThreadLocal does not allow a null object?
Posted by Shai Erera <se...@gmail.com>.
ok patch is already submitted
On Thu, Aug 13, 2009 at 4:53 PM, Michael McCandless <
lucene@mikemccandless.com> wrote:
> I think just fix it for 2.9? I don't think we're planning on a 2.4.2
> release at this point...
>
> Mike
>
> On Thu, Aug 13, 2009 at 8:53 AM, Shai Erera<se...@gmail.com> wrote:
> > 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
> > <lu...@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<se...@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-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: java-dev-help@lucene.apache.org
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
Re: CloseableThreadLocal does not allow a null object?
Posted by Michael McCandless <lu...@mikemccandless.com>.
I think just fix it for 2.9? I don't think we're planning on a 2.4.2
release at this point...
Mike
On Thu, Aug 13, 2009 at 8:53 AM, Shai Erera<se...@gmail.com> wrote:
> 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
> <lu...@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<se...@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: CloseableThreadLocal does not allow a null object?
Posted by Shai Erera <se...@gmail.com>.
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 <
lucene@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<se...@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
Re: CloseableThreadLocal does not allow a null object?
Posted by Michael McCandless <lu...@mikemccandless.com>.
Let's just allow null? Can you open an issue?
Mike
On Thu, Aug 13, 2009 at 6:18 AM, Shai Erera<se...@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org