TextFromStandardInputStream seems not to work well with JLine

[victornoel]

trafficstars

Hi,

I am using JLine (version 2.6) and it seems it doesn't interact well with TextFromStandardInputStream.

Basically, the jline.console.ConsoleReader provides a method called readLine() that reads a line and when it returns null, it means the stream was ended (InputStreamReader.read() returns -1 if I understood well).

The thing is when using TextFromStandardInputStream, once what had to be read from System.in was read, it seems that instead of blocking, InputStreamReader.read() returns -1…

I'm not totally sure the cause is not coming from JLine, but when I tried to implement my own TextFromStandardInputStream by simply replacing System.in with a PipedInputStream to which I write, it worked as desired...

[stefanbirkner]

I have a look at this.

[victornoel]

Hi, it almost works well, but I still have problems with some use case where it seems that instead of blocking, System.in returns -1 (in a java Reader)…

I would expect that the reader blocks until the test using the rule is ended…

[victornoel]

Maybe I'm not using TextFromStandardInputStream as it is meant…

I realised that calling provideLines multiple times would replace the previous lines provided if they hadn't been read yet… Why isn't TextFromStandardInputStream simply something that emulates the System.in by blocking when there is nothing to read, and provideLines would append text at the end of the stream. Maybe then we could add a method to close the stream (aka eof or ctrl-d)…

[stefanbirkner]

I try to find a better solution by using PipedInputStream.

[stefanbirkner]

TextFromStandardInputStream isn't blocking because it is designed for automated tests that run in a single thread. If TextFromStandardInputStream blocks then the test itself blocks.

I could imagine how to implement blocking behaviour for a test where the code that reads runs in a different thread than the test code. But I never encountered such a test.

Could you provide more details about the use case that still has problems with TextFromStandardInputStream.

[victornoel]

We exactly do that: we run the tested code inside its own thread. It enables us to test interaction with it through System.{in,out,err} but also to test proper termination of the code (because, basically, we are testing an interactive CLI) when the right data is sent to it.

See for example: http://fisheye.ow2.org/browse/Petals/petals/client-tools/petals-cli/petals-cli/src/test/java/org/ow2/petals/cli/MainTest.java?r=38790#to261

I think maybe TextFromStandardInputStream is not meant to be something to test that… maybe it would make sense to introduce something different that would block and actually act like System.in?

[victornoel]

This is what I wrote to achieve that functionality: http://fisheye.ow2.org/browse/Petals/petals/client-tools/petals-cli/petals-cli-base-junit/src/main/java/org/ow2/petals/cli/base/junit/rules/ConsoleInput.java?r=38790&r=38790