30 standalone tags (jstl) failures #631
Comments
|
I'll try looking for a server.log in https://ci.eclipse.org/jakartaee-tck/job/9.1/job/eftl-standalonetck-build-run-910/8/artifact/tags-tck-results.tar.gz to see if the |
|
From server.log I see: |
|
Is that a test case issue then? |
|
Brian had previously mentioned in ml discussion (sub "Jakarta EE 9.1 testing with Java SE 11 - JSTL Bucket" ) that
If adding -Djava.locale.providers=COMPAT is fine then shall we try that. |
@alwin-joseph Good point, I think that we should add -Djava.locale.providers=COMPAT for JDK11 to run in JDK 8 compatibility mode. |
|
Note that the workaround was mentioned on https://www.eclipse.org/lists/jakartaee-tck-dev/msg01139.html @pnicolucci do you agree that we should use the -Djava.locale.providers=COMPAT workaround so that JSTL tests running on JDK 11 will see JDK 8 behavior? Please reference |
|
To me it's fine, but would like to hear from @pnicolucci of course. |
|
Since I originally mentioned it, I agree that the COMPAT workaround is a good path of least resistance, but I'm also going to be taking a look over the next day or so at how hard it would be to handle two sets of goldenfiles for these tests -- one for Java 8, the other for 9+. |
|
I don't have a problem setting the system property if the path of least resistance is what is being looked for here. I do agree with Brian that if multiple golden files can be added and used across the various executions then it would make sense to go that route rather than setting a system property to revert to the old behavior. |
|
So long as the property setting |
|
I've been looking more closely at our results and I think that only 14 of the 29 failures could be fixed with goldenfile updates. The other 15 fail (in Open Liberty and Glassfish) with some variation of the exception reported above:
Looking around, the consensus seems to be that using the COMPAT value is the way to get this to work. Otherwise, in this particular case I think there would need to be an update to apache.taglibs to handle the new (as of Java 9) Locales and/or migrate from using java.text to java.time for its parsing. I can confirm that using the COMPAT property does resolve all 29 failures in Open Liberty, so one would presume it would for Glassfish as well. |
|
Yes, probably this needs to be added for the Platform TCK test jobs as well as the the stand alone TCK test runs. Once we drop JDK8, we can refresh the tests to use the new formats. Thanks for checking for us. |
|
@scottmarlow - shall we consult tags dev, on usage of COMPAT workaround to get JSTL test passed with jdk11 |
|
I'm not quite clear on the scenario when the If the tags implementation/specification had to move away from the https://jakarta.ee/specifications/tags/2.0/jakarta-tags-spec-2.0.pdf If the cases that are failing are areas where the spec document specifies |
|
My assumption here is that the dates failing are unchanged from the jdk8 runs where they work. If the issue at its core is that dates that worked with JDK8 now don't work in JDK 11 due to |
|
Looking at some of the ParseException cases more closely, I think it is indeed just a matter of how the JSPs in the tests are written. ex.
For the above to pass with the default Java 11 options, we'd instead need a JSP using a parseDate value that looks like |
|
You really only want 1 flavor of the test will you are supporting both JDK versions. You can have your compatibility rules for now require: -Djava.locale.providers=COMPAT while you are supporting JDK 8.
I don’t think there is enough of a benefit to filter the tests based on the JDK releases given the compatibility switch is there.
Once you stop supporting JDK 8, then that would be the time to make the update to the tests.
On Mar 15, 2021, at 12:11 PM, Brian Decker ***@***.***> wrote:
Looking at some of the ParseException cases more closely, I think it's just a matter of how the JSPs in the tests are written.
ex.
<!-- The date to be parsed can be provided as body content to the
action. -->
<fmt:parseDate type="both" var="e2">
Nov 21, 2000 3:45:02 AM
</fmt:parseDate>
<fmt:formatDate value="${e2}" type="both" timeZone="EST"/>
For the above to pass with the default Java 11 options, we'd instead need a JSP using a parseDate value that looks like Nov 21, 2000, 3:45:02 AM instead. Which means we would need two versions of a lot of these JSPs (to support 8 and 11) and therefore two versions of the applications, then the TCK would have to sort out which one to deploy. I'm not sure how feasible that feels.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#631 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQPFO27BAUBESLMNB3UHHLTDYWR3ANCNFSM4YM6RF5Q>.
My best,
Lance
--
Lance Andersen
USTA EMA President and CEO
PTR Professional 5A
USPTA Elite Professional
TIA Global Cardio Tennis-Master Trainer
USRSA
Mobile: 978 857-0446
luckydogtennis.com -- luckydogtennis.com/TennisBlog -- cardiotennis.com
|
|
For the post-9.1 future, here's a branch (https://github.com/brideck/jakartaee-tck/tree/UpdateJSTLJava11Locale) containing the changes needed to get these tests to pass with Java 11's default locales and Open Liberty. They should also work for GF. |
|
@brideck if you have time it could be helpful to create a pr with label = |
|
PR for future: #664 |
|
JSTL tests are passing with COMPAT option. WIP changes can be seen here - https://github.com/gurunrao/jakartaee-tck/commit/951e93c6ece0b4410f78e85a58434a5cb4b47295
|
|
PR for COMPAT option - #670 |
|
Passing now! Only the jaxws tests failed (could be a compilation issue I am guessing). |
Describe the bug
30 standalone Tags (JSTL) TCK tests are failing when run in JDK11.
Errors like:
To Reproduce
Run https://ci.eclipse.org/glassfish/view/TCK/job/run_tags_tck_against_staged_build/
Expected behavior
100% pass, 0% errors
The text was updated successfully, but these errors were encountered: