Bill Barker wrote:
2. Add a block/no-block parameter to InputFilter.doRead and OutputFilter.doWrite InputFilter -> public int doRead(ByteChunk chunk, Request unused, boolean block) throws IOException; OutputFilter -> public int doWrite(ByteChunk chunk, Response unused, boolean block) throws IOException; Servlet 3.0 will most likely expose non blocking read/write through the servlet API, this will get us there ahead of time Haven't thought of how we expose this API yet though, but more will follow
I agree with Remy here.  We should do it when we know that Servlet 3.0 
requires it.  Until then, the transport layer should be opaque to the 
Servlet container.  That is how Coyote is currently designed (i.e. if 
somebody had an itch to resurect the JNI Channel for Windows (IIS/Httpd) for 
AJP/1.3, would this even be meaningful?).
I'd like to clarify that I am working on non blocking functionality (to 
implement my withdrawn API proposal), but I meant I don't see any 
business at this point exposing the possibility of partial writes in any 
API, since it would mean some higher level code would have to deal with 
this additional complexity, maybe up to the servlet layer. I believe 
partial writes can be handled well enough without this strategy.
4. Startup -> server.xml warnings
If one enters an invalid element or attribute that is simply ignored today, at least output an info or warn message letting the
  admin know if its misconfiguration.

You can get the attributes now by setting debug logging on 
o.a.t.u.IntrospectionUtils.  It wouldn't be hard to do in general (e.g. make 
IntrospectionUtils.setAttribute return boolean instead of void, and warn in 
Digester.startElement if no rules are configured, but make the later 
configurable so that the TC shutdown digester doesn't produce a ton of 
warnings).  However, it means that our fork of Digester increasingly moves 
away from c-d.
This would be a great strategy (and there's no reason not to include it 
in the current 6.0.x branch if it's simple). I'll play with it and see 
what it does.
Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to