Hi Oleg,
here are a few comments, though they have little to do with NIO.
- the examples and at least some of the implementation classes
are missing the Apache copyright notice in the source files
- I still don't like the duplication of methods in IOSession
and HttpContext. The only reason I can see for not deriving
IOSession from HttpContext are the constants defined there.
Maybe we should separate declaration of the methods from
definition of the constants. Factor out the methods to a new
interface o.a.h.util.Attributable, derive both HttpContext
and IOSession from there?
- I will have to update build files so that the examples are
compiled and javadoced.
- The way you are using EntityTemplate in the examples,
I don't see the advantage over a StringEntity. For example:
EntityTemplate body = new EntityTemplate(new ContentProducer() {
public void writeTo(final OutputStream outstream)
throws IOException {
OutputStreamWriter writer =
new OutputStreamWriter(outstream, "UTF-8");
writer.write("<html><body><h1>");
writer.write("File ");
writer.write(file.getPath());
writer.write(" not found");
writer.write("</h1></body></html>");
writer.flush();
}
});
can be replaced by
StringEntity body =
new StringEntity("<html><body><h1>" +
"File "+file.getPath()+" not found" +
"</h1></body></html>",
"UTF-8");
which is just as readable and doesn't need an inner class.
The main problem I had with understanding your NIO activities
is now solved. I was always wondering how you were going to
expose the channels at the entities so applications can use
NIO features. From what I've seen now, you just don't.
Applications continue to use blocking streams, which are then
mapped to channels. Doesn't that mean that the context switches
you want to avoid are just moved from the general IO operations
to the NIO receiver/transmitter?
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
