commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel F. Savarese" <...@savarese.org>
Subject Re: [net] Re: problem with RCommandClient
Date Wed, 30 Oct 2002 15:53:49 GMT

> > 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>


Mime
View raw message