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