• Post Reply Bookmark Topic Watch Topic
  • New Topic

standard in failing after replacing

 
Kurro Zaki
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everybody

I'm sorry do ask this but my current problem is a very wierd one. And I'm completly confused.
I'm writing a piece of software that replaces the standard in, out and error with a custom one.
First the original ones are stored and then replaced.
The problem i'm facing is in the inputstream. The replacing inputstream has a read method that
first tries to get a ID. Then it read from the stream associated with that stream. If no ID is found
the replacing inputstream reads from the original inputstream.

But if I use this new inputstream it block on the read call from the original standard in.
If I however directly read from the standard in everything works fine.

here is the code:


I used my debugger and i'm absolutly sure the call to ProcessHerder.getProcessID(Thread.currentThread()); returns null
 
Greg Charles
Sheriff
Posts: 3010
12
Firefox Browser IntelliJ IDE Java Mac Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I can't say that I like your approach very much. Why do you need to replace standard in? You could easily read from a custom stream in certain conditions, and standard in in other conditions, without going to the extreme of replacing standard in.

I'm not really sure why it's failing, but I have a theory. Since you replaced what standard in is, all input from the console will now go into your new stream, so there's no way for the old System.in, now main.StandardIn, to get any data. Therefore it blocks on a read that can never complete.
 
Kurro Zaki
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I really need to replace the standard in because in an other part of my program classes are being loaded at runtime. These classes could just be any standard pure java application. These use System.in because they don't know that they are loaded by my application.
The standard in is however replaced by my system that associats a unique ID and a few streams with each loaded application. My little piece of code then redirects the read operation to the correct stream.
These things work correctly with System.out and System.err but System.in is troublesome.
 
Ulf Dittmer
Rancher
Posts: 42970
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The "readLine" method depends on the JVM's default line ending; has the process (or class) that generates this input the same idea of what a proper line ending is?
 
Kurro Zaki
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The problem is not in the readline method. Even reading one byte is impossible.
What actually happen is:

1: System.in is stored in main.standardIn
2: System.in is replaced by my inputstream
3: A bufferedReader is constructed using System.in (At this moment this is my inputstream, Not the standard one)
4: ReadLine() is calles
5: internally ReadLine() calls fillBuffer()
6: fillBuffer calls the read method of MY inputstream
7: My inputstream doens't find an ID, so it reads from main.standardIn (wich was the original System.in)
8: The read method of main.standardIn block for ever

I have absolutly no clue why this happens because this works for System.out and System.err but System.in blocks

I also know that main.standardIn still works after System.in has been replace because if I construct the BufferedReader directly from
main.standardIn everything works fine.
Just adding the extra method in between seems to cause trouble. But why?
 
Kurro Zaki
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok guys I found the answer somewhere else. Thanks for your help here to.

It appear that I just had to change extends InputStream to extends BufferedInputStream.

the answer
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!