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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
|