Jakarta EE 10 standalone TCK support for JDK 21 runs. #1219

gurunrao · 2024-01-31T03:10:08Z

Support JDK21 runs with security manager disabled for SPEC which do not have new release during Jakarta EE 11.
Service release TCK's are:

Connector

Messaging

Transactions

SOAP

XML webservices

Tags has 40 failures[date/timezone problem]- https://ci.eclipse.org/jakartaee-tck/job/guru/job/jakartaee-tck-build-run/job/jdk21-run/39/#showFailuresLink

lukasj

LGTM

scottmarlow · 2024-02-21T22:39:58Z

Pasting one of the Tags failures for easier viewing:

java.text.ParseException: Unparseable date: "Nov 21, 2000, 3:45:02 AM"

scottmarlow

Seems like the failing tags tests should be challenged for both this pull request and https://issues.redhat.com/browse/WFLY-18900 as well (see https://issues.redhat.com/secure/attachment/13112138/jstlfailures.txt).

gurunrao · 2024-02-27T07:10:07Z

Tags tests are failing with JDK21 and Glassfish 8 [ https://ci.eclipse.org/jakartaee-tck/job/guru/job/jakartaee-tck-build-run/job/jdk21-run/39/testReport/], similar failures having java.text.ParseException: Unparseable date: "Nov 21, 2000, 3:45:02 AM message was seen with JDK11.
@brideck and @volosied had suggested fixes for similar failures with JDK11+, any suggestion for JDK21?

bstansberry · 2024-03-07T23:27:51Z

In case it helps, the problem is the breaking space before 'AM/PM'. Apparently the CLDR used in SE 21 wants a non-breaking space there.

I have no idea what to do with this information. :)

import java.text.DateFormat;
import java.text.ParseException;

class Scratch {
    public static void main(String[] args) {
        test("Nov 21, 2000, 3:45:02 AM");
        System.out.println();
        test("Nov 21, 2000, 3:45:02\u202FAM");
    }

    private static void test(String input) {
        System.out.println("Testing '" + input + "'");
        try {
            DateFormat.getDateTimeInstance().parse(input);
            System.out.println("OK");
        } catch (ParseException e) {
            int offset = e.getErrorOffset();
            System.out.println("Parse failures at " + input.substring(0, offset));
            System.out.println("Code point for problem char '" + input.charAt(offset) +"' is " + input.codePointAt(offset));
            e.printStackTrace(System.out);
        }
    }
}

Outputs:

Testing 'Nov 21, 2000, 3:45:02 AM'
Parse failures at Nov 21, 2000, 3:45:02
Code point for problem char ' ' is 32
java.text.ParseException: Unparseable date: "Nov 21, 2000, 3:45:02 AM"
	at java.base/java.text.DateFormat.parse(DateFormat.java:399)
	at Scratch.test(scratch.java:14)
	at Scratch.main(scratch.java:6)

Testing 'Nov 21, 2000, 3:45:02 AM'
OK

The answer on https://stackoverflow.com/questions/77225936/java-21-problem-with-dateformat-getdatetimeinstance-formatnew-date gives some context into what likely lead to this string no longer being ok in SE 21.

gurunrao · 2024-03-08T05:16:53Z

Seems like the failing tags tests should be challenged for both this pull request and https://issues.redhat.com/browse/WFLY-18900 as well (see https://issues.redhat.com/secure/attachment/13112138/jstlfailures.txt).

@scottmarlow: Glassfish 8 is under development, Please raise challenge for https://issues.redhat.com/browse/WFLY-18900 failures.

scottmarlow · 2024-03-08T14:42:49Z

Seems like the failing tags tests should be challenged for both this pull request and https://issues.redhat.com/browse/WFLY-18900 as well (see https://issues.redhat.com/secure/attachment/13112138/jstlfailures.txt).

@scottmarlow: Glassfish 8 is under development, Please raise challenge for https://issues.redhat.com/browse/WFLY-18900 failures.

@gurunrao This might need a TCK challenge, not sure yet.

I would like to see what happens if we update https://github.com/jakartaee/platform-tck/blob/10.0.x/src/web/jstl/compat/onedotzero/positiveFormatLocalizationContextI18NTest.jsp#L32 to use value="Nov 21, 2000, 3:45:02\u202FAM"/> which I did locally but I'm not sure of the magic secret to rebuild the jsp prior to running the jstl/compat folder. I tried:

if [[ "$testFolder" == testFolder=jstl* ]]; then
cd $TS_HOME/src/com/sun/ts/tests/$testFolder
ant compile package build.all compile

cd $TS_HOME/src/web

ant compile build package

fi

Assume that testFolder=jstl/compat/onedotzero

But it seems that even after running the above positiveFormatLocalizationContextI18NTest.jsp didn't get rebuilt. Do you remember which ant command we should use to rebuild the https://github.com/jakartaee/platform-tck/blob/10.0.x/src/web/jstl/compat/onedotzero/positiveFormatLocalizationContextI18NTest.jsp + the dist/** archives for onedotzero?

scottmarlow · 2024-03-08T14:52:24Z

@scottmarlow: Glassfish 8 is under development, Please raise challenge for https://issues.redhat.com/browse/WFLY-18900 failures.

@gurunrao This might need a TCK challenge, not sure yet.

I would like to see what happens if we update https://github.com/jakartaee/platform-tck/blob/10.0.x/src/web/jstl/compat/onedotzero/positiveFormatLocalizationContextI18NTest.jsp#L32 to use value="Nov 21, 2000, 3:45:02\u202FAM"/> which I did locally but I'm not sure of the magic secret to rebuild the jsp prior to running the jstl/compat folder. I tried:

if [[ "$testFolder" == testFolder=jstl* ]]; then
cd $TS_HOME/src/com/sun/ts/tests/$testFolder
ant compile package build.all compile

cd $TS_HOME/src/web

ant compile build package

fi

Assume that testFolder=jstl/compat/onedotzero

But it seems that even after running the above positiveFormatLocalizationContextI18NTest.jsp didn't get rebuilt. Do you remember which ant command we should use to rebuild the https://github.com/jakartaee/platform-tck/blob/10.0.x/src/web/jstl/compat/onedotzero/positiveFormatLocalizationContextI18NTest.jsp + the dist/** archives for onedotzero?

I might just start a 10.0.x test branch with changes to the failing jsp sources to use \u202F instead of regular space before AM/PM and build a test platform tck. If someone has the right ant commands to use, I'll try that. We probably need the right ant commands to be run from a particular TCK distribution source folder.

volosied · 2024-03-08T14:54:47Z

Hello, I recall working on this space problem in Faces in our Open Liberty tests (see OpenLiberty/open-liberty#24009). In the issue I wrote: Java 20 Updated to CLDR 42 <https://cldr.unicode.org/index/downloads/cldr-42> which includes the following change: - Large-scale normalization of different kinds of spaces (see Migration) - https://unicode-org.atlassian.net/browse/CLDR-14032

…

____ My solution is not very elegant -- I checked for a different character based on which Java level was used: "\u202F" for Java 20 and above and "\u0020" for anything below. Something similar may be needed in the TCK unless there's another way? Hope it helps, Volodymyr

On Fri, Mar 8, 2024 at 9:43 AM Scott Marlow ***@***.***> wrote: Seems like the failing tags tests should be challenged for both this pull request and https://issues.redhat.com/browse/WFLY-18900 as well (see https://issues.redhat.com/secure/attachment/13112138/jstlfailures.txt). @scottmarlow <https://github.com/scottmarlow>: Glassfish 8 is under development, Please raise challenge for https://issues.redhat.com/browse/WFLY-18900 failures. @gurunrao <https://github.com/gurunrao> This might need a TCK challenge, not sure yet. I would like to see what happens if we update https://github.com/jakartaee/platform-tck/blob/10.0.x/src/web/jstl/compat/onedotzero/positiveFormatLocalizationContextI18NTest.jsp#L32 to use value="Nov 21, 2000, 3:45:02\u202FAM"/> which I did locally but I'm not sure of the magic secret to rebuild the jsp prior to running the jstl/compat folder. I tried: if [[ "$testFolder" == testFolder=jstl* ]]; then cd $TS_HOME/src/com/sun/ts/tests/$testFolder ant compile package build.all compile cd $TS_HOME/src/web ant compile build package fi Assume that testFolder=jstl/compat/onedotzero But it seems that even after running the above positiveFormatLocalizationContextI18NTest.jsp didn't get rebuilt. Do you remember which ant command we should use to rebuild the https://github.com/jakartaee/platform-tck/blob/10.0.x/src/web/jstl/compat/onedotzero/positiveFormatLocalizationContextI18NTest.jsp + the dist/** archives for onedotzero? — Reply to this email directly, view it on GitHub <#1219 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNIZZRBICZZPMSKDLRCH43YXHE77AVCNFSM6AAAAABCSJ76NCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBVHAYTKNRWGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

scottmarlow · 2024-03-08T15:01:55Z

Hello, I recall working on this space problem in Faces in our Open Liberty tests (see OpenLiberty/open-liberty#24009). In the issue I wrote: Java 20 Updated to CLDR 42 https://cldr.unicode.org/index/downloads/cldr-42 which includes the following change: - Large-scale normalization of different kinds of spaces (see Migration) - https://unicode-org.atlassian.net/browse/CLDR-14032

Pasting from ^ issue:

This means that a new space is used when formatting times. Specifically between the minutes and AM/PM markers. Java 19 and earlier used a regular space (U+0020) while Java 20 now uses a narrow no break space (U+00A0). This causes our tests to fail as they don't match the exact expectations.

Does Java 11 treat the narrow no break space (U+00A0) the same as (U+0020) so that the test could be changed to use (U+00A0)?

scottmarlow · 2024-03-08T15:22:25Z

Hello, I recall working on this space problem in Faces in our Open Liberty tests (see OpenLiberty/open-liberty#24009). In the issue I wrote: Java 20 Updated to CLDR 42 https://cldr.unicode.org/index/downloads/cldr-42 which includes the following change: - Large-scale normalization of different kinds of spaces (see Migration) - https://unicode-org.atlassian.net/browse/CLDR-14032

Pasting from ^ issue:

This means that a new space is used when formatting times. Specifically between the minutes and AM/PM markers. Java 19 and earlier used a regular space (U+0020) while Java 20 now uses a narrow no break space (U+00A0). This causes our tests to fail as they don't match the exact expectations.

Does Java 11 treat the narrow no break space (U+00A0) the same as (U+0020) so that the test could be changed to use (U+00A0)?

From my local testing, \u202F does not work with Java 11 that same as a (U+0020). I think the EE 10 tests with this problem should be challenged and possibly excluded for EE 10.

scottmarlow · 2024-03-11T13:05:26Z

From my local testing, \u202F does not work with Java 11 that same as a (U+0020). I think the EE 10 tests with this problem should be challenged and possibly excluded for EE 10.

I think the tests are problematic for Jakarta EE 11 as well due to the Java changes. Clearly applications will need to be updated that hit this problem on Java 19+.

scottmarlow · 2024-03-12T13:01:22Z

Seems like the failing tags tests should be challenged for both this pull request and https://issues.redhat.com/browse/WFLY-18900 as well (see https://issues.redhat.com/secure/attachment/13112138/jstlfailures.txt).

@scottmarlow: Glassfish 8 is under development, Please raise challenge for https://issues.redhat.com/browse/WFLY-18900 failures.

👍 , I'll create a TCK challenge for Tags 3.0

scottmarlow · 2024-03-12T14:15:01Z

@gurunrao jakartaee/tags#255 is the TCK challenge issue.

gurunrao · 2024-03-26T11:18:18Z

@gurunrao jakartaee/tags#255 is the TCK challenge issue.

@scottmarlow: Based on challenge jakartaee/tags#255, will add following tests to JSTL exclude list:

com/sun/ts/tests/jstl/compat/onedotzero/JSTLClient.java#positiveFormatLocalizationContextI18NTest
com/sun/ts/tests/jstl/compat/onedotzero/JSTLClient.java#positiveSetTimezoneValueTest
com/sun/ts/tests/jstl/compat/onedotzero/JSTLClient.java#positiveTimezoneValueTest
com/sun/ts/tests/jstl/spec/fmt/format/fmtdate/JSTLClient.java#positiveFDDateStyleTest
com/sun/ts/tests/jstl/spec/fmt/format/fmtdate/JSTLClient.java#positiveFDFallbackLocaleTest
com/sun/ts/tests/jstl/spec/fmt/format/fmtdate/JSTLClient.java#positiveFDLocalizationContextTest
com/sun/ts/tests/jstl/spec/fmt/format/fmtdate/JSTLClient.java#positiveFDTimeStyleTest
com/sun/ts/tests/jstl/spec/fmt/format/fmtdate/JSTLClient.java#positiveFDTimeZoneNullEmptyTest
com/sun/ts/tests/jstl/spec/fmt/format/fmtdate/JSTLClient.java#positiveFDTimeZonePrecedenceTest
com/sun/ts/tests/jstl/spec/fmt/format/fmtdate/JSTLClient.java#positiveFDTimeZoneTest
com/sun/ts/tests/jstl/spec/fmt/format/fmtdate/JSTLClient.java#positiveFDTypeTest
com/sun/ts/tests/jstl/spec/fmt/format/localecontext/JSTLClient.java#positiveFormatLocalizationContextBrowserLocaleTest
com/sun/ts/tests/jstl/spec/fmt/format/localecontext/JSTLClient.java#positiveFormatLocalizationContextBundleTest
com/sun/ts/tests/jstl/spec/fmt/format/localecontext/JSTLClient.java#positiveFormatLocalizationContextI18NTest
com/sun/ts/tests/jstl/spec/fmt/format/localecontext/JSTLClient.java#positiveFormatLocalizationContextLocaleTest
com/sun/ts/tests/jstl/spec/fmt/format/parsedate/JSTLClient.java#positivePDBodyValueTest
com/sun/ts/tests/jstl/spec/fmt/format/parsedate/JSTLClient.java#positivePDDateStyleTest
com/sun/ts/tests/jstl/spec/fmt/format/parsedate/JSTLClient.java#positivePDFallbackLocaleTest
com/sun/ts/tests/jstl/spec/fmt/format/parsedate/JSTLClient.java#positivePDLocalizationContextTest
com/sun/ts/tests/jstl/spec/fmt/format/parsedate/JSTLClient.java#positivePDParseLocaleTest
com/sun/ts/tests/jstl/spec/fmt/format/parsedate/JSTLClient.java#positivePDTimeStyleTest
com/sun/ts/tests/jstl/spec/fmt/format/parsedate/JSTLClient.java#positivePDTimeZoneNullEmptyTest
com/sun/ts/tests/jstl/spec/fmt/format/parsedate/JSTLClient.java#positivePDTimeZonePrecedenceTest
com/sun/ts/tests/jstl/spec/fmt/format/parsedate/JSTLClient.java#positivePDTimeZoneTest
com/sun/ts/tests/jstl/spec/fmt/format/parsedate/JSTLClient.java#positivePDTypeTest
com/sun/ts/tests/jstl/spec/fmt/format/settimezone/JSTLClient.java#positiveSetTimezoneValueNullEmptyTest
com/sun/ts/tests/jstl/spec/fmt/format/settimezone/JSTLClient.java#positiveSetTimezoneValueTest
com/sun/ts/tests/jstl/spec/fmt/format/timezone/JSTLClient.java#positiveTimezoneValueNullEmptyTest
com/sun/ts/tests/jstl/spec/fmt/format/timezone/JSTLClient.java#positiveTimezoneValueTest

For challenge jakartaee/tags#256 following tests have been excluded:

com/sun/ts/tests/jstl/spec/core/urlresource/importtag/JSTLClient.java#negativeImportRequestDispatcherServletExceptionTest
com/sun/ts/tests/jstl/spec/core/urlresource/importtag/JSTLClient.java#negativeImportRequestDispatcherRTIOExceptionTest
com/sun/ts/tests/jstl/spec/fmt/format/fmtnum/JSTLClient.java#negativeFNUnableToParseValueTest
com/sun/ts/tests/jstl/spec/fmt/format/parsedate/JSTLClient.java#negativePDUnableToParseValueTest
com/sun/ts/tests/jstl/spec/fmt/format/parsenum/JSTLClient.java#negativePNUnableToParseValueTest
com/sun/ts/tests/jstl/spec/sql/param/JSTLClient.java#negativeParamQueryBodyContentTest
com/sun/ts/tests/jstl/spec/sql/param/JSTLClient.java#negativeParamQuerySQLAttributeTest
com/sun/ts/tests/jstl/spec/sql/query/JSTLClient.java#negativeQueryBodyContentTest
com/sun/ts/tests/jstl/spec/sql/query/JSTLClient.java#negativeQuerySQLAttributeTest
com/sun/ts/tests/jstl/spec/sql/update/JSTLClient.java#negativeUpdateBodyContentTest
com/sun/ts/tests/jstl/spec/sql/update/JSTLClient.java#negativeUpdateSQLAttributeTest2

lukasj · 2024-03-28T18:28:50Z

XML webservices

I believe this is OK as of TCK 4.0.1 published quite recently

SOAP

Can this one be completed, please? XML WS depends on this...

gurunrao · 2024-03-29T05:27:03Z

XML webservices

I believe this is OK as of TCK 4.0.1 published quite recently

SOAP

Can this one be completed, please? XML WS depends on this...

jakartaee/tags#255 challenge will be accepted today as per comment - jakartaee/tags#255 (comment), I will be able to proceed with test.

gurunrao · 2024-03-29T09:40:45Z

GF 8 + JDK21 runs - https://ci.eclipse.org/jakartaee-tck/job/guru/job/jakartaee-tck-build-run/job/jdk21-run/46/

gurunrao · 2024-04-03T09:41:22Z

@scottmarlow - Please review.

scottmarlow · 2024-04-03T13:03:32Z

install/jstl/bin/ts.jtx

@@ -16,4 +16,46 @@

 #
 # $Id$
-#
+# https://github.com/jakartaee/tags/issues/255


Updated:
jakartaee/tags#255 (comment) discusses a possible code change to address the issue for EE 10+. I'm not yet sure if the suggested code change to change the test based on which Java version is used, will help but it sounds like a worthwhile idea to try.

The only issue that I see is that the Platform TCK team doesn't have enough time to do everything that we are being asked to do. We should respond on the jakartaee/tags#255 issue that we do not have time to make a test change but see if someone else wants to. Otherwise we will merge this change and the other EE 10 changes that are needed for Java 21 support.

Forget what I said about EE 11 as this pr is for the 10.0.x branch. :-)

Updated: jakartaee/tags#255 (comment) discusses a possible code change to address the issue for EE 10+. I'm not yet sure if the suggested code change to change the test based on which Java version is used, will help but it sounds like a worthwhile idea to try.

The only issue that I see is that the Platform TCK team doesn't have enough time to do everything that we are being asked to do. We should respond on the jakartaee/tags#255 issue that we do not have time to make a test change but see if someone else wants to. Otherwise we will merge this change and the other EE 10 changes that are needed for Java 21 support.

Forget what I said about EE 11 as this pr is for the 10.0.x branch. :-)

Thanks Scott for the comments, As you rightly said the changes are applicable for complete release of Specification. The PR is for service release, where test changes are not possible. Please let me know, if further changes are need in the PR or PR can be merged.

Quoting from https://jakarta.ee/committees/specification/tckprocess:

A consensus that a test produces invalid results will result in the exclusion of that test from certification requirements, and an immediate update and release of an official distribution of the TCK including the new exclude list. The associated challenge issue MUST be closed with an accepted label to indicate it has been resolved.

The specification project may approve (user) workarounds for an accepted TCK challenge (as an alternative to excluding TCK tests).

As another alternative to excluding a challenged test, it may be possible to adjust the test validation logic to “expand” the validation check. E.g. if a test expects a value “A1” for a specific variable “x”, but a challenge is raised arguing that the specification language actually allows for either values “A1” and “A2” (but no other values) to be valid values for “x”, then it could be a valid course of action to modify the challenged test to allow either “A1” OR “A2” for “x”.

Since this line of thinking might be applied to cases that aren’t quite as straightforward as this example, care should be taken when using this approach. A particular danger is that an implementation that has already demonstrated compliance before the challenge was raised might actually not pass the new, modified test.

To limit the confusion and additional work such a scenario would cause, if there is already at least one certified compatible implementation before the challenge, the new, modified TCK should be run against at least one such implementation (and ideally all of them) before the changes are published, released, and finalized.

If such a change were released, and it was later found to cause a previously-certified implementation to fail the new, modified test, then excluding the test would likely be the only option, and this would require yet another, additional service release.

More specifically, the text it may be possible to adjust the test validation logic to “expand” the validation check mentions a specific use case that doesn't involve new releases of Java breaking compatibility but that is what broke the jstl tests. To "expand" the (TCK) validation check we have to support both Java 11/17 (as before) but also "expand" the check to also work on Java 21. To do that, I think there will be some separate files for the different Java versions and some test changes to use different expressions in the jstl tests.

@gurunrao feel free to respond on the related EE 10 TCK challenge issue jakartaee/tags#255 (comment)

lukasj · 2024-04-24T18:19:49Z

@scottmarlow would it make sense to merge this as is and resolve pending issue/tags tck through a different PR to unblock 4-5 different TCKs unrelated to the issue being observed?

scottmarlow · 2024-04-24T18:47:56Z

@scottmarlow would it make sense to merge this as is and resolve pending issue/tags tck through a different PR to unblock 4-5 different TCKs unrelated to the issue being observed?

I think that we are prepared to merge the Tags change as both jakartaee/tags#255 + jakartaee/tags#256 are accepted.

We probably should separate the changes for the other specs unless they already have TCK challenges (I don't see a challenge issue under https://github.com/jakartaee/connectors/issues)?

Connector
Messaging
Transactions
SOAP
XML webservices

scottmarlow · 2024-04-24T18:50:28Z

@scottmarlow would it make sense to merge this as is and resolve pending issue/tags tck through a different PR to unblock 4-5 different TCKs unrelated to the issue being observed?

I think that we are prepared to merge the Tags change as both jakartaee/tags#255 + jakartaee/tags#256 are accepted.

We probably should separate the changes for the other specs unless they already have TCK challenges (I don't see a challenge issue under https://github.com/jakartaee/connectors/issues)?

Actually, this pull request only is changing how we run the TCKs for the other specs which do not require a TCK challenge, so yes, we can merge this and I will after reading through the change once more.

* Connector

* Messaging

* Transactions

* SOAP

* XML webservices

scottmarlow · 2024-04-24T18:55:41Z

release/tools/connector.xml

@@ -22,7 +22,7 @@
    <import file="../../bin/xml/ts.common.props.xml"/>

    <property name="deliverable.version" value="2.1"/>
-    <property name="deliverable.tck.version" value="2.1.0"/>
+    <property name="deliverable.tck.version" value="2.1.1"/>


Hmm, guess we are looking to release new service releases with the GlassFish TCK script changes.

In order to release new TCK service releases we do need to follow the TCK process so we might want to separate the JSTL change since that is ready to merge but it would be nice to only have to release the platform tck once.

From the TCK process:

Process for releasing a point revision of a TCK

The process for releasing a point revision of a TCK entails filing an issue in the jakartaee/specifications repository with the following details:

Link to the TCK release to be published.

Updated TCK links in the specification’s _index.md file.

A high-level description of what tests were excluded from the TCK and why.

scottmarlow · 2024-04-24T19:05:15Z

@scottmarlow would it make sense to merge this as is and resolve pending issue/tags tck through a different PR to unblock 4-5 different TCKs unrelated to the issue being observed?

@lukasj as (just) mentioned above we need accepted TCK challenges for the other issues as well.

@gurunrao I think we need to increment the platform tck version for the jstl test excludes.

scottmarlow · 2024-04-24T19:06:53Z

Actually, we only need to release the platform TCK with the jstl changes. I'll fork this change and create a separate pr for just the jstl changes.

scottmarlow · 2024-04-24T19:51:56Z

#1290 contains the JSTL test excludes and the version updates to prepare for releasing the jstl + platform tck with challenged jstl tests excluded.

@gurunrao could you please remind me which javatest.jar is included with this change? In terms of where it came from?

Thanks!

gurunrao · 2024-04-25T06:50:11Z

#1290 contains the JSTL test excludes and the version updates to prepare for releasing the jstl + platform tck with challenged jstl tests excluded.

@gurunrao could you please remind me which javatest.jar is included with this change? In terms of where it came from?

Thanks!

Thanks for the review @scottmarlow : The javatest jar has been built from master branch using github repository https://github.com/openjdk/jtharness.git. The javatest jar was built for PR #1163 and same javatest.jar has been used for current PR. javatest library built has option to bypass security manager and complete the test run.

Signed-off-by: Gurunandan Rao <gurunandan.rao@oracle.com>

…ersion to support JDK21[without security manager] Signed-off-by: Gurunandan Rao <gurunandan.rao@oracle.com>

Signed-off-by: Gurunandan Rao <gurunandan.rao@oracle.com>

edburns · 2024-05-07T15:42:11Z

Move the JSTL changes in this PR to another PR.
This will enable this PR to be merged.

scottmarlow · 2024-05-07T15:42:35Z

We should do this soon!

gurunrao · 2024-05-08T16:57:37Z

Move the JSTL changes in this PR to another PR.

This will enable this PR to be merged.

@scottmarlow @edburns - I have removed the JSTL changes from the PR.

scottmarlow · 2024-05-08T17:42:09Z

release/tools/jta.xml

@@ -22,7 +22,7 @@
    <import file="../../bin/xml/ts.common.props.xml"/>

    <property name="deliverable.version" value="2.0"/>
-    <property name="deliverable.tck.version" value="2.0.2"/>
+    <property name="deliverable.tck.version" value="2.0.3"/>


I missed this before but looks like https://www.eclipse.org/downloads/download.php?file=/jakartaee/transactions/2.0/jakarta-transactions-tck-2.0.1.zip was the last Transactions TCK to be promoted. So I think we can just stick with the release/tools/jta.xml deliverable.tck.version = 2.0.2 value.

Everything else looks good.

I have reverted the version increment for JTA, also
found JTA 2.0.2 TCK bundle service release at - https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee10/promoted/eftl/

Signed-off-by: Gurunandan Rao <gurunandan.rao@oracle.com>

scottmarlow · 2024-05-09T12:31:49Z

Thanks @gurunrao!

gurunrao requested a review from scottmarlow February 14, 2024 07:05

gurunrao changed the title ~~support JDK 21 runs~~ Jakarta EE 10 standalone TCK support for JDK 21 runs. Feb 14, 2024

lukasj approved these changes Feb 21, 2024

View reviewed changes

scottmarlow approved these changes Feb 21, 2024

View reviewed changes

scottmarlow requested changes Feb 21, 2024

View reviewed changes

gurunrao mentioned this pull request Mar 12, 2024

support JDK21 and security manager disabled. #1163

Closed

scottmarlow mentioned this pull request Mar 12, 2024

Tags 3.0 TCK Challenge against tests that include space character before AM/PM jakartaee/tags#255

Closed

gurunrao force-pushed the jdk21-run branch from 0648be2 to 40f69a4 Compare March 29, 2024 05:21

gurunrao requested a review from scottmarlow March 29, 2024 05:23

gurunrao force-pushed the jdk21-run branch from 40f69a4 to d160a1e Compare March 29, 2024 07:07

scottmarlow reviewed Apr 3, 2024

View reviewed changes

scottmarlow mentioned this pull request Apr 24, 2024

Tags 3.0 TCK Challenge for test ExceptionCheckTag.java depending on removed Pages 4.0 JspException.getRootCause() method... jakartaee/tags#256

Closed

scottmarlow reviewed Apr 24, 2024

View reviewed changes

scottmarlow mentioned this pull request Apr 24, 2024

Address JSTL TCK Challenge tags/issues/255 + tags/issues/256 #1290

Closed

gurunrao added 5 commits April 25, 2024 16:49

JDK21 runs of standalone TCKs.

1ccf576

Signed-off-by: Gurunandan Rao <gurunandan.rao@oracle.com>

disable security manager.

a831383

Signed-off-by: Gurunandan Rao <gurunandan.rao@oracle.com>

update connector,jaxws.jstl,jta,saaj standalone tck service release v…

2a937fa

…ersion to support JDK21[without security manager] Signed-off-by: Gurunandan Rao <gurunandan.rao@oracle.com>

jakartaee/tags#255, jakartaee/tags#256 challenge exclusions.

7d0e173

Signed-off-by: Gurunandan Rao <gurunandan.rao@oracle.com>

update jaxws tck release version to 4.0.2

f5dd09b

Signed-off-by: Gurunandan Rao <gurunandan.rao@oracle.com>

gurunrao force-pushed the jdk21-run branch from d681c6c to f5dd09b Compare April 25, 2024 11:20

This was referenced May 1, 2024

Jakarta XML WS 4.0.2 (SR) jakartaee/specifications#710

Merged

Jakarta SOAP with Attachments 3.0.2 (SR) jakartaee/specifications#707

Merged

gurunrao force-pushed the jdk21-run branch 3 times, most recently from 7f74e4c to 4e4dba8 Compare May 8, 2024 16:55

scottmarlow reviewed May 8, 2024

View reviewed changes

revert jstl tck changes.

4f088d3

Signed-off-by: Gurunandan Rao <gurunandan.rao@oracle.com>

gurunrao force-pushed the jdk21-run branch from 4e4dba8 to 4f088d3 Compare May 9, 2024 04:39

scottmarlow approved these changes May 9, 2024

View reviewed changes

scottmarlow merged commit 54974d5 into jakartaee:10.0.x May 9, 2024
1 check passed

gurunrao deleted the jdk21-run branch September 26, 2024 21:23

Jakarta EE 10 standalone TCK support for JDK 21 runs. #1219

Jakarta EE 10 standalone TCK support for JDK 21 runs. #1219

Conversation

gurunrao commented Jan 31, 2024 • edited Loading

lukasj left a comment

Choose a reason for hiding this comment

scottmarlow commented Feb 21, 2024

scottmarlow left a comment • edited Loading

Choose a reason for hiding this comment

gurunrao commented Feb 27, 2024

bstansberry commented Mar 7, 2024 • edited Loading

gurunrao commented Mar 8, 2024

scottmarlow commented Mar 8, 2024

cd $TS_HOME/src/web

ant compile build package

scottmarlow commented Mar 8, 2024

cd $TS_HOME/src/web

ant compile build package

volosied commented Mar 8, 2024 via email

scottmarlow commented Mar 8, 2024

scottmarlow commented Mar 8, 2024

scottmarlow commented Mar 11, 2024

scottmarlow commented Mar 12, 2024

scottmarlow commented Mar 12, 2024

gurunrao commented Mar 26, 2024 • edited Loading

lukasj commented Mar 28, 2024

gurunrao commented Mar 29, 2024

gurunrao commented Mar 29, 2024

gurunrao commented Apr 3, 2024

scottmarlow Apr 3, 2024 • edited Loading

Choose a reason for hiding this comment

gurunrao Apr 4, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lukasj commented Apr 24, 2024

scottmarlow commented Apr 24, 2024

scottmarlow commented Apr 24, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

scottmarlow commented Apr 24, 2024

scottmarlow commented Apr 24, 2024

scottmarlow commented Apr 24, 2024

gurunrao commented Apr 25, 2024 • edited Loading

edburns commented May 7, 2024

scottmarlow commented May 7, 2024

gurunrao commented May 8, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

scottmarlow commented May 9, 2024

gurunrao commented Jan 31, 2024 •

edited

Loading

scottmarlow left a comment •

edited

Loading

bstansberry commented Mar 7, 2024 •

edited

Loading

gurunrao commented Mar 26, 2024 •

edited

Loading

scottmarlow Apr 3, 2024 •

edited

Loading

gurunrao Apr 4, 2024 •

edited

Loading

gurunrao commented Apr 25, 2024 •

edited

Loading