james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard O. Hammer" <ROHam...@EarthLink.net>
Subject Re: new InputStream class for mail data
Date Wed, 16 Jul 2003 18:03:26 GMT
Noel J. Bergman wrote:
> FilteredInputStream is the right thing to extend.

Thank you again, Noel, for calling my attention to FilterInputStream. 
  I had not previously understood what purpose FilterInputStream 
serves in the API.  But your suggestion, coming after this programming 
exercise in which I've had to understand the consequences of calling 
read(byte[]) when my class does not override that method, has helped 
me understand a need for FilterInputStream.

 > ... SMTPInputStream
> implements read() based upon the real stream, which is the one
> non-constructor method that is correct in the code.  The rest are wrong.
> For example:
> 
>     public void close() throws IOException{
>         super.close();
>     }
> 
> explicitly illustrates a problem that is implicit with all of the inherited
> methods.  The code invokes the inherited implementation, often a NO-OP.  It
> ought to be delegating to the real stream.

In the particular case with SMTPDataInputStream, the class which I 
submit for your consideration, the underlying stream (the "real 
stream" as I understand your usage) is the BufferedInputStream which 
will later be read again by the envelope-command-line Reader.  So, 
unless I am mistaken, we do not want to be closing the underlying 
stream in this case.

 > ... FilteredInputStream provides the
> core wrapper for delegation, allowing you to override just those methods
> that implement your unique behavior.

As I describe in the comment at the end of class SMTPDataInputStream, 
this implementation relies upon the behavior of the two InputStream 
methods read(byte[]) and read(byte[], int, int) which work by making 
repeated calls to the read() method in this descendant 
SMTPDataInputStream.  In this case that behavior is needed, in order 
to use the functionality which I have added only in the read() method.

The read(byte[]) and read(byte[], int, int) methods of 
BufferedInputStream, which evidently would be employed if I extended 
FilterInputStream, do not behave this way, according to my tests. 
They appear to read directly from somewhere deeper, and thus would not 
express the functionality added in the one read() method.

But FilterInputStream does look like a class I will want to use 
another time, in a similar task.

Rich


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message