commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Seguin" <seg...@motive.com>
Subject RE: [net] Re: problem with RCommandClient
Date Wed, 30 Oct 2002 16:02:04 GMT
well, it just seemed that by default RCommandClient did not work as one
would expect.  but I'm happy with the subclassing approach - it works
just fine.  and besides, just adding a subclass was a lot less work than
writing the entire thing would be, so thanks ;)

regards,
kevin.

> -----Original Message-----
> From: Daniel F. Savarese [mailto:dfs@savarese.org] 
> Sent: Wednesday, October 30, 2002 9:54 AM
> To: commons-dev@jakarta.apache.org
> Subject: Re: [net] Re: problem with RCommandClient
> 
> 
> 
> > > 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>
> 
> 

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