On 02/08/2011 01:40, Christopher Schultz wrote: > On 8/1/2011 2:58 PM, Mark Thomas wrote: >> On 01/08/2011 19:32, Christopher Schultz wrote: >>> On 8/1/2011 12:05 PM, Mark Thomas wrote: >>>> On 01/08/2011 16:45, Christopher Schultz wrote: >>>>> On 7/26/2011 1:30 PM, Mark Thomas wrote: >>>>>> The Servlet EG is starting to discuss changes to the >>>>>> Servlet API for 3.1. It would be useful if the option >>>>>> existed to implement some of these changes in Tomcat trunk. >>>>>> The benefits of this are: - we can see how feasible the API >>>>>> changes are to implement - users can try out the new APIs >>>>>> (assuming we do a Tomcat 8 alpha release) >>>>> >>>>> How much of this stuff could reasonably be built-into Tomcat >>>>> 7 without breaking anything? >>>> >>>> None. The TCK will fail as soon as any changes are made to the >>>> API. >>> >>> Ooh, so until the TCK is updated to tolerate Servlet 3.1, we will >>> be unable to run TCK tests against trunk. That seems ... >>> non-ideal. >> >> We won't get the TCK until after the spec has gone final. As an EG >> member I should have access to it before then but I am new to this >> so we'll have to wait and see. > > I guess what I meant was that we wouldn't even be able to run > Servlet 3.0 TCK against our TC8 trunk because it would always fail. > That means not being able to test the trunk against anything but our > own unit tests for quite a while, which is unfortunate.
No. > So, the TCK will bomb if we implement extra methods in, say, > HttpServletRequest? Since containers are supposed to adjust behavior > depending upon the version string used in the deployment descriptor, > I had hoped that the TCK would be sensitive to that kind of thing. No, the TCK will not "bomb" but neither will it pass. Tomcat 7 must pass the Servlet 3.0 TCK so we can't change the Servlet API. Tomcat 8 doesn't have to pass the Servlet 3.0 TCK so it does not matter if there are some "expected failures" when running it against trunk / Tomcat 8. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
