Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of sebbaz@gmail.com designates
 209.85.160.171 as permitted sender)
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:content-transfer-encoding;
        b=Vxioj24f52bLhXvIzz2c8rkzzx6Fsxb689sw3N31cnZaUCFliXuryDQvpHc0VsmcZA
         h/nhUfTHXjzmsmlNVcviwknhQYNAEOaB3wUAW1RhDUv/ZjYmLWR5+V9N5ioSupE1kyzx
         yvVFoi88ZlEldpfpClKcaUg4Q/LReA/mjt04U=
MIME-Version: 1.0
In-Reply-To: <AANLkTimUFQawtATU3160yH9fuwBV5Y5TuoD9njNn4bU4@mail.gmail.com>
References: <AANLkTi=WzW_6LAEic=dvOiRq3oUDTEXRK3TsBPBQtpKV@mail.gmail.com>
	<AANLkTingtgY0H71MZnA8jwTEFajkQycahJo5UDHMJ6_c@mail.gmail.com>
	<AANLkTik51JCFNKd--JUOHhsZwvkpVzk_qw-uABtaq9eo@mail.gmail.com>
	<AANLkTimUFQawtATU3160yH9fuwBV5Y5TuoD9njNn4bU4@mail.gmail.com>
Date: Thu, 30 Sep 2010 12:01:51 +0100
Message-ID: <AANLkTin-rf=7A_dYUB6wr9LjbvkUa3TuLBUaLWmqidPA@mail.gmail.com>
Subject: Re: [IO] Tailer API
From: sebb <sebbaz@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 30 September 2010 06:39, Julien Aym=E9 <julien.ayme@gmail.com> wrote:
> 2010/9/30 sebb <sebbaz@gmail.com>:
>> On 30 September 2010 02:58, Niall Pemberton <niall.pemberton@gmail.com> =
wrote:
>>> On Thu, Sep 30, 2010 at 2:46 AM, sebb <sebbaz@gmail.com> wrote:
>>>> Just wondering if the Tailer API could be simplified by performing the
>>>> thread start within the class?
>>>> Is it ever going to be useful to have direct access to tailer thread?
>>>> I suspect not, as the Listener should provide sufficient access.
>>>>
>>>> It's not safe to start a thread in the constructor (unless the ctor is
>>>> final), but one could use static factory methods instead.
>>>>
>>>> So instead of:
>>>>
>>>> =A0TailerListener listener =3D ...
>>>> =A0Tailer tailer =3D new Tailer(file, listener, delay);
>>>> =A0Thread thread =3D new Thread(tailer);
>>>> =A0thread.start();
>>>> =A0...
>>>> =A0tailer.stop()
>>>>
>>>> one would do something like:
>>>>
>>>> =A0TailerListener listener =3D ...
>>>> =A0Tailer tailer =3D Tailer.createTailer(file, listener, delay);
>>>> =A0...
>>>> =A0tailer.stop()
>>>>
>>>> This simplifies the API, and allows the class to force the thread to
>>>> be a daemon thread. It also stops the caller from messing with the
>>>> thread.
>>>>
>>>> WDYT?
>>>
>>> There are five different Thread constructors that take a Runnable and
>>> a bunch of other methods that someone might want to use. I don't have
>>> a problem providing a convenience static method - but it only saves
>>> two lines of code - as long as they can construct one manually with or
>>> without a Thread if they want to.
>>
>> But what is the use case for having access to the created thread?
>> Seems to me it would be a lot safer if the thread were private to the cl=
ass.
>
> The use case is that someone may want to use an Executor instead of a
> dedicated Thread to run background tasks such as Tailer, at least I
> do. I have no problem with providing a convenient static method, as
> Niall suggested, but I would like to keep the Tailer as a Runnable
> with no embedded thread if possible.

OK.

So how about allowing the user to pass in an Executor when creating
the instance?
Would that be sufficient?

> HTH,
> Julien
>
>>
>> It would still be possible to use the code without a thread by
>> exposing the method that loops over the file, and using the
>> constructor instead.
>> For example with the current code one could do something like:
>>
>> TailerListener listener =3D ...
>> Tailer tailer =3D new Tailer(file, listener, delay);
>> tailer.run()
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org