On 29/10/2014 19:05, Rémy Maucherat wrote:
> 2014-10-29 20:00 GMT+01:00 Mark Thomas <ma...@apache.org>:
>
>> OK. That makes sense.
>>
>> My initial reading of the spec was that the ISE was required as soon as
>> complete() was called. After all, that is what the Javadoc says.
>>
>> However... the Javadoc for complete() says:
>> <quote>
>> If this method is called before the container-initiated dispatch that
>> called startAsync has returned to the container, then the call will not
>> take effect (and any invocations of AsyncListener.onComplete(AsyncEvent)
>> will be delayed) until after the container-initiated dispatch has
>> returned to the container.
>> </quote>
>>
>> It is certainly possible to read the Javadoc for complete() as meaning
>> that the ISE should not be thrown until after onComplete() finishes
>> although that isn't how I have been reading it.
>>
>> I withdraw my veto (again) and I don't see the need for those
>> STRICT_SERVLET_COMPLIANCE checks either.
>>
>> I'll take a look at the failing unit tests and see what I can do to get
>> them to pass.
>>
> Yes, the javadoc is kinda wrong since it should mention the associated
> event. Use of the strict flag could remain until the testsuite passes IMO.
OK. Lets leave it in place until the issues with the tests are fixed.
The started flag being true for the MUST_COMPLETE state is causing
problems too. It breaks code like this:
if (request.isAsyncStarted()) {
request.getAsyncContext().complete();
}
While you could make the "effects of complete have to be delayed..."
argument, I don't think it holds in this case as the ability to test if
complete() needs to be called is more important.
What do you think about reverting that particular change?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
