On 17/01/2014 02:30, Rob Sanders wrote: > Would it be worth waiting to have the RHEL6/FIPS stuff looked at - at least > to the point of deciding if the issue should involve fixes to both TC and TCN > or be limited to TCN only? I posted Monday and earlier today about it. > I believe the minimal patch to resolve the issue would involve TCN only > however.
My working assumption is that the minimal patch will be the solution for at least 6.0.x so I am going to go ahead with my plans for tagging 6.0.x. Mark > > -Rob > > On Jan 16, 2014, at 6:54 PM, Mark Thomas wrote: > >> It has been a while since the last 6.0.x release so I plan to tag 6.0.38 >> tomorrow (if all goes well). There are a couple of simple patches in the >> status file that I'd like to include in the tag. Votes welcome. >> >> In preparation for the tag, I have been running the Servlet and JSP >> TCKs. There are some failures but I think it is OK to ignore them. >> Before creating the tag, I wanted to see what others thought. >> >> I have traced the root causes to the following: >> >> 1. My inability to ever configure my environment correctly to get the >> API signature checks to pass. I recall I always had this issue when >> running the TCK for Tomcat 6 and earlier. I have manually checked the >> API and I am happy it is specification compliant. >> >> 2. If tldValidation is enabled, ServletContext.getInitParameterNames() >> returns a non-empty enumeration even though the application has not set >> any init parameters. I think this is OK. >> >> 3. If tldValidation is enabled, some the the JSP tests that use invalid >> TLDs fail. I think this is OK. >> >> 4. If a security manager is enabled, >> ServletContext.getInitParameterNames() returns a non-empty enumeration >> even though the application has not set any init parameters. I think >> this is OK. >> >> As an aside, I am going to update the config for running the TCKs for >> Tomcat 6 to disable tldValidation. This will address 2 & 3 above. >> >> Mark >> >> PS Don't forget the status file :) >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
