-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Chris,
On 6/14/17 10:17 AM, Chris Cheshire wrote: > On Tue, Jun 13, 2017 at 6:06 PM, Mark Thomas <ma...@apache.org> > wrote: > >> On 13/06/17 22:01, Mark Thomas wrote: >>> On 13/06/17 15:27, Chris Cheshire wrote: >> >> <snip/> >> >>>> I'm bewildered at why tomcat operates this way when it comes >>>> to Numbers >> and >>>> Strings. Why is it insistent on coercion when null and zero >>>> are >> absolutely >>>> not the same value. If this is because of autoboxing, then >>>> isn't that a bug? A long is not a Long, and when tag >>>> attributes must be objects and >> not >>>> atomic types, shouldn't they be treated accordingly? >>> >>> Tomcat behaves this way because the specification says it has >>> to. Plenty of folks disagree strongly with the specification >>> but Tomcat has to implement it. COERCE_TO_ZERO is a >>> specification breaking configuration option to workaround this >>> particular behaviour. >>> >>> I've been digging in to this some more and it appears that >>> COERCE_TO_ZERO has been given a wider scope in later versions >>> of Tomcat. The test case you present above behaves the way you >>> want with COERCE_TO_ZERO set to false in 8.0.x and above. I >>> need to dig into why that wider scope wasn't applied to 7.0.x. >> >> Mystery solved thanks to some svn archaeology and >> cross-referencing to the relevant specs. >> >> Tomcat 7 implements EL 2.2. EL 2.2 requires coercion of "" and >> null to 0 for numeric types (section 1.18.3). (As did earlier >> versions of the EL spec). >> >> Initially there weren't many complaints because the coercion >> rules weren't implemented correctly in one important case (i.e. >> they left these as null rather than coercing to zero). Then bug >> 43285 [1] got fixed and the complaints started. >> >> To address the complaints, Tomcat introduced the system property >> org.apache.el.parser.COERCE_TO_ZERO which restored the >> non-specification compliant behaviour for the one coercion case >> that was causing problems. To align with the EL 2.2. >> specification, the default was for coercion to zero to occur. >> >> The level of complaints about the coercion rules was such that a >> backwards compatible change was introduced in EL 3.0 to not >> coerce to zero. Given Java EE's normal approach that backwards >> compatibility concerns trump all others, it is a sign of the >> seriousness with which the issue was taken that an incompatible >> change was made. >> >> Tomcat 8, which implemented EL 3.0, switched to the new coercion >> rules. To help migration of 7.0.x applications, the role of >> COERCE_TO_ZERO was expanded to cover all instances of EL >> coercion. To align with EL 3.0, the default was changed not to >> coerce to zero. >> >> Which brings us to where we are today. >> >> The problem you are seeing is a spec compliant coercion that is >> not covered by the COERCE_TO_ZERO property in 7.0.x. >> >> There are several possible solutions: >> >> 1. Upgrade to 8.x (8.5.x recommended in preference to 8.0.x) I >> appreciate that an RPM is not available for Tomcat 8 but 8.0.x >> has had stable releases for three years and 8.5.x for 1 year. >> >> 2. Use one of the workarounds. All pretty ugly. >> >> 3. Lobby for the extension of scope for COERCE_TO_ZERO in 7.0.x >> to be equivalent to the scope in 8.0.x. At this stage in the >> 7.0.x that is unlikely to happen. The risk of breakage for other >> users is too great. >> >> 4. Lobby for an additional configuration option for 7.0.x that >> extends the of scope for COERCE_TO_ZERO in 7.0.x to be equivalent >> to the scope in 8.0.x. This should be doable with care (there was >> some refactoring involved in the scope change that would need >> careful back-porting). This is also dependent on the CentOS >> distribution picking up the change to 7.0.x. I don't know how >> likely that is. Given the current package is based on a version >> over a year old I suspect that the changes of this being quick >> are very low. >> >> None of those options look ideal. I'd probably go with 1 but my >> familiarity with Tomcat is such that I usually prefer to work >> with an ASF distribution rather than a downstream one anyway. >> YMMV. >> >> Mark >> >> >> [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=43285 >> >> >> > Mark, > > Thanks for the investigation into this. > > You are right in that (1) is the best option. Finding time to > translate the ASF distribution into one with appropriate run > scripts and configs, along with a mechanism for in-place updating > is tough. Having RPMs for that saves me a lot of time which is why > I stuck with 7.x for so long. In the meantime I'll figure out the > cleanest ugly workaround I can. I definitely won't lobby for any > non-security fixes in a product that is 2+ generations old and is > probably approaching EOL in the not too distant future. Coty Sutherland is the package maintainer for RedHat's Tomcat package. Perhaps he could be persuaded to create a tomcat85 package. Try posting a new question to the list about a Tomcat 8.5 package for RHEL/CentOS and see if you can get his attention. Even if it's not an "official RPM" maybe he can help build one. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllBgXkACgkQHPApP6U8 pFh/kQ/+OMAiqr8UV7qRw5FazoOxvLM3f7sVpJz6QMEMWiwgmy1jwI0zFuyE3ZSg lVCFQo2EIoEiHDxxvaDPicfeROrB30W6hn3b3T0RxFICIBNxdMJKrvN5ahoW5IE0 UWPHB06eiwVI0KlTrnm3XKsGY1RyT9yaEd9JQqJo5JDqCQSpSTNROgBRZUxsMZa2 2URKzhS6h8brv2TMTiywZf71zrcKGBGEuALqLJo+jPii1Cf5TrCwtHPM8EVG6dvF 5wzCwEPUK3Z1jZKVyWh0IZbSVU751DHxRNMSUR5qBDEmOzEXthuZ2AeHSDeN5hPe KOwSvgEHiV3nrKrEwgSManbfKuobKsdMrPSXCy1W199qBCiMcdP/VR/X4rpiD0cw ylA+VGzicqHZC/BA1y1MFvatSbEuq6hQ3HmyMajyZDdvd/y29W6kB9POcMuwS5BM cgQdQLUshkyk0XqE+p4xgBPLVi3LUYhX2RIbWZ2QnubQ0l4STUGEqlN2dj+sUmU1 mQ23y4ugXepXBBLBtujXuVmDhweWwww4Fe/iLzVlUNoTOLw1SxQA2re0MCZwB8Th 9JtX2o4YpNLX5PssOrIgrRAkp4q1KlCv9W4avidCd9GXexWtq5zxXevIhs/2hl4y RLFiqw9zAy3MnEIMDR6zFb0GIfznEAoPC108OoYfz/77VCpTNXY= =h6mP -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
