On 07/10/2011, at 3:01 PM, Adam Murdoch wrote:
> On 07/10/2011, at 3:31 AM, Luke Daley wrote:
>
>> Hi,
>>
>> We now handle passing the clients stdin to the build daemon. This means we
>> have to do some swapping around of System.in. I can see that at some point
>> someone is going to want to do their own System.in swapping and this is
>> going to break our strategy.
>>
>> A case might be the use of some library that a user wants to integrate that
>> insists on reading from stdin and they want to pipe their own data (say from
>> a file) to this utility. The first thing they will reach for is
>> System.setIn().
>>
>> What we could do is provide a project method that takes an InputStream and a
>> Closure that we make work with our strategy. e.g.
>>
>> withInput(new FileInputStream(file("input-for-library")) {
>> new SomeLibrary().readStdin()
>> }
>
> Why not this:
>
> def original = System.in
> System.in = new FileInputStream("...")
> try {
> new SomeLibrary().readStdin()
> } finally {
> System.in = original
> }
>
>>
>> It's an edge case to be sure, but it seems like we should make it work now
>> while adding stdin support to the daemon.
>
> I think we should wait for a use case for this, particularly given that this
> is completely doable with some regular code like the above.
You're completely right. For some reason I was thinking that the connection
would be broken when the streams get swapped, but that won't happen.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
