On 3/5/12 1:27 PM, Mark Thomas wrote:
> On 28/02/2012 19:19, Shing Wai Chan wrote:
>> I have enclosed the candidate Servlet 3.1 Early draft review with change
>> bars and the associated javadoc.
>> The source code can be found at
>> https://svn.java.net/svn/glassfish~svn/trunk/api/javaee-api/javax.servlet .
>> For a list of changes, please look at the status chapter.
>> Please give us feedback by Mar 6 (next Tue).
>>
>> Shing Wai Chan and Rajiv Mordani
> General
>
> 1. I really don't like that the Javadoc is no longer part of the
> specification documentation. Given that there is important detail that
> is only present in the Javadoc I think that it should be included so
> that all the necessary information is available in a single document. A
> PDF is also a lot easier to search (e.g. for a method name) than a PDF
> plus a bunch of HTML files. It might be more work for the EG lead, but
> it would be a big benefit to the users of the specification.
>
> 2. The list of EG members needs to be updated as does, I suspect, the
> acknowledgements.
>
>
> HTTP Upgrade
>
> 1. I don't see why ProtocolHandler#outputReady() is required. Data is
> written to the OutputStream of the WebConnection which the container
> then writes to the client.
This is used to notify the ProtocolHandler that it can start to write
the data.
>
> 2. I don't think WebConnection needs to be aware that the protocol may
> support 'half closes'. Let the ProtocolHandler implementation handle
> that if it wants to.
The half-close feature was discussed during Oct 2011 in the expert group.
I have also discussed this internally.
If there is no objection, then I will join the half close support in the
EDR.
>
> 3. The javadoc for ProtocolHandler#init() needs to be clarified that it
> is called once the HTTP Upgrade process has been completed and the
> upgraded connection is ready to start using the new protocol. It
> currently reads as if it is called when the HTTP Upgrade process starts.
I have just updated the javadoc.
>
> 4. It looks very much like a Blocking IO style is being used. That
> strikes me as rather too restrictive.
See (1).
Shing Wai Chan
>
>
> Async IO
>
> 1. No timeout support.
>
> 2. Why is it illegal to call read() if isReady() returns false? If the
> application wants to block waiting for data, let it.
>
> 3. Are multiple ReadListeners permitted for a single ServletRequest? If
> not, setReadListener would be a better method name.
>
> 4. Why do we need ServletRequest#getServletReader()? Especially since
> there is no way to control the buffer size.
>
> 5. When is onWritePossible() meant to be called? It could be called
> almost continually based on the current description.
>
> Mark