On 22/03/2010 16:49, Filip Hanik - Dev Lists wrote: > my implementation makes an assumption that the app calls complete(), but > it seems as the TCK expects the container to call complete for the app. > This is specifically in the dispatchZeroArgTest. The spec defines is as > the container will call complete() if the servlet doesn't support async. > However, in the dispatchZeroArgTest, it dispatches to itself, a servlet > that does support async, so I'm not sure our stuff is wrong here.
I think it was. There are a couple of issues that I can see, not helped by the spec language. <quote> The complete method can be invoked by the container if the request is dispatched to a servlet that does not support async processing, or the target servlet called by AsyncContext.dispatch does not do a subsequent call to startAsync. In this case, it is the container's responsibility to call complete() as soon as that servlet's service method is exited. </quote> The spec language here has all sorts of issues: - The "can be" is not consistent with the later "it is the container's responsibility" - "The complete method can be invoked if 'X' or 'Y'. In this case...". Does "this case" mean X, Y or both? In the case of ambiguity we normally go with what the TCK tests for so we need to call complete() in both cases. The second issue I noticed is that: "For all the 3 variations of the dispatch methods defined above, calls to the methods returns immediately after passing the request and response objects to a container managed thread, on which the dispatch operation will be performed." At the moment, doDispatchInternal does not pass the request & repsonse to a container managed thread. That seems to be causing TCK failures. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
