> > results in the socket getting closed. so the remote process never > > completes - it hangs waiting for an EOF - or it ends when I > close the > > stream, but I can't read its output because the socket gets closed. > > rock and a hard place, so to speak :)
You're not between a rock and a hard place because you can sublcass to specialize behavior, as you have already done :) > > I can "fix" this by subclassing RCommandClient and returning a an > > output stream proxy that actually does a Socket.shutdownOutput() > > rather than > > OutputStream.close() (see code below), but this seems like something > > that ought to work out of the box. I am just missing something? I do not believe shutdown calls should be added to RCommandClient or any other class (they would actually wind up inside of SocketClient) because it's not clear it is the desired default semantic---it is afterall the OutputStream returned by Socket.getOutputStream()---(although it can certainly be discussed and debated) and would also break JDK 1.2 and 1.1 compatibility. Until it is agreed that support for those versions is being abandoned, it would be unwise to put J2SE SDK 1.3+ specific code into the source. Right now, it is perfectly acceptable to subclass to achieve desired behavior. It is a class framework after all. daniel -- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
