Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cu-dev] Component spec review deadline and when to create 3.1 RC1 and staging of final
After further investigation it does seem that we assume the JDK version of the Client and the JDK version of the Container are the same.
So it is conceivable that if you were to run this test from a Java 17 client, while your server is running on Java 21 you would fail the signature test.
If this is the case we could fix the signature test to make the decision of which signature file to test against until runtime inside the container.

I just ran the signature test using a locally built snapshot against Open Liberty using Java 21 and had no failures.

On Tue, Mar 19, 2024 at 11:07 AM Kyle Aure <kylejaure@xxxxxxxxx> wrote:
Hello Ondro,

Thanks for the update.
The class that you pointed to ConcurrencySignatureTestRunner.java is part of an arquillian test which gets deployed to a container.
When we deploy the application to the container we find the appropriate signature file and rename it to a generic file called `jakarta.enterprise.concurrent.sig`.

I wonder if the real issue here isn't just one of inadequate ignoring of JDK classes.
Let me do some more testing on my side to see if I can replicate any issues.

Thank you,
Kyle Jon Aure

On Tue, Mar 19, 2024 at 10:17 AM Ondro Mihályi via cu-dev <cu-dev@xxxxxxxxxxx> wrote:
Hi Nathan, Kyle,

I collaborated with Petr and we executed the TCK against Concurro together. Petr ran it on his computer, so he has the details, but I remember that there was a flaw in the Sig test, which expects a hardcoded signature file name but this file no longer exists because it was split into Java 17 and Java 21 versions. It was I think this test: https://github.com/jakartaee/concurrency/blob/de38984633ad91bd699a736bb51293f98d9f661c/tck/src/main/java/ee/jakarta/tck/concurrent/common/signature/ConcurrencySignatureTestRunner.java#L43, which expects a file called "jakarta.enterprise.concurrent.sig" but there are now files jakarta.enterprise.concurrent.sig_17 and jakarta.enterprise.concurrent.sig_21: https://github.com/jakartaee/concurrency/tree/main/tck/src/main/resources/ee/jakarta/tck/concurrent/common/signature

The test should adapt to the version of Java in the runtime and choose the correct signature file.

Ondro

On Tue, Mar 19, 2024 at 3:13 PM Nathan Rauh via cu-dev <cu-dev@xxxxxxxxxxx> wrote:

Petr and anyone else who is experiencing issues with the Concurrency 3.1 signature tests, please see Kyle’s request below regarding providing the details.  Please get this information to him as soon as possible.  Now that Kyle is back, he might be able to fix the issue you are seeing if you can provide the necessary information to reproduce it.  If it is not addressed in time, we will need to decide between holding up RC1 and staging a copy of final, which will cause us to miss the component specification deadline for Jakarta EE 11, vs moving forward to meet the deadline.

 

From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> on behalf of Kyle Aure via cu-dev <cu-dev@xxxxxxxxxxx>
Date: Monday, March 18, 2024 at 9:29 AM
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: Kyle Aure <kylejaure@xxxxxxxxx>
Subject: [EXTERNAL] Re: [cu-dev] Component spec review deadline and when to create 3.1 RC1 and staging of final

Hello All, Sorry I was out last week and am just now getting caught up on this. Petr, what failure are you getting from the signature test for concurrency? Is it that the signature test is not correctly finding the concurrency API on your classpath?

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

 

ZjQcmQRYFpfptBannerEnd

Hello All,

 

Sorry I was out last week and am just now getting caught up on this. 

 

Petr, what failure are you getting from the signature test for concurrency?

Is it that the signature test is not correctly finding the concurrency API on your classpath? Or is it failing due to insufficient ignoring of JDK classes?

 

If you could open an issue with more details I will be happy to address it prior to the RC1 release.

 

Thank you,

Kyle Jon Aure

 

On Thu, Mar 14, 2024 at 3:54 PM Scott Marlow via cu-dev <cu-dev@xxxxxxxxxxx> wrote:

 

On 3/14/24 16:37, Scott Stark via cu-dev wrote:

For CDI and Validation we setup a maven project just to set the classpath for the type of signature dependencies we want to validate. For example, just the dependent CDI API jars:

 

For the jars that Weld depends on:

 

I did not look into how the SigTestDriver class actually does the testing. Is this using the netbeans sigtest code or the jakarta tck tools fork, or something else?

It was using netbeans sigtest before but looks like Faces 4.1 is using jakarta tck tools fork as per https://github.com/jakartaee/faces/blob/4.1/tck/faces-signaturetest/pom.xml#L55

 

 

On Thu, Mar 14, 2024 at 2:31 PM James Perkins <jperkins@xxxxxxxxxx> wrote:

It's possible, but we'd need to change how the class path is resolved. It shouldn't really resolve from Maven Projects class path, the class path should be required to be provided and point to server dependencies. Another idea might be to provide an abstract Arquillian test which can check that a deployments class path is setup correctly.

 

On Thu, Mar 14, 2024 at 12:40 PM Scott Stark <starksm64@xxxxxxxxx> wrote:

Can this just be rolled into a run mode of the tck tools sigtest maven plugin?

 

 

On Thu, Mar 14, 2024 at 12:32 PM James Perkins via cu-dev <cu-dev@xxxxxxxxxxx> wrote:

 

 

On Thu, Mar 14, 2024 at 11:02 AM Arjan Tijms via cu-dev <cu-dev@xxxxxxxxxxx> wrote:

Hi,

 

The signature maintainers did some amazing work after the fork :) 

 

 

That would make it even easier to reuse the signature creating and testing between projects.

 

I don't want to distract from the main point of this conversation too much, but I just want to add a +1 to that. I know other projects would benefit from that as well.

 

 

Kind regards,

Arjan Tijms

 

On Thu, 14 Mar 2024 at 18:21, Scott Marlow <smarlow@xxxxxxxxxx> wrote:

I think that we also need to update "excludeJdkClasses" tck/src/main/java/ee/jakarta/tck/concurrent/common/signature/SigTestDriver.java to include the same classes added by the https://github.com/jakartaee/concurrency/pull/393 change which I think will help us pass Concurrency 3.1 Signature Tests on Java 21.

We also need to update the Signature test tooling to better ignore the Java SE classes so that we don't have to spend time on changes like ^ in the future.

On 3/14/24 12:21, Arjan Tijms via cu-dev wrote:

Hi, 

 

Regarding the Signature tests, I recently did them for the upcoming Faces 4.1 TCK.

 

A signature can be generated from a given API jar using this: https://github.com/jakartaee/faces/tree/4.1/tck/faces-signaturegen

 

And then another jar can be tested against it with this: https://github.com/jakartaee/faces/tree/4.1/tck/faces-signaturetest

 

It should be relatively easy to copy that over to the Concurrency TCK and adjust the package and API names where needed.

 

Kind regards,

Arjan Tijms

 

 

 

 

 

On Thu, 14 Mar 2024 at 14:47, Nathan Rauh via cu-dev <cu-dev@xxxxxxxxxxx> wrote:

Petr,

That’s great to hear. It sounds like you are very close to having it all passing! Are you also covering Java 17, or only 21?  We will need to have passing TCK results from compatible implementations on both Java SE levels given the decision that was made at the platform level about requiring Java 17.  If not, it is an option to have different compatible implementations per Java SE level when we submit for component spec release review.

 

Regarding the signature tests, I assume we would not be allowed to not have them at all.  I’ll let Kyle comment on the signature tests because he has been more involved in them. He is out for a day or two but it is back next week.

 

From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> on behalf of Petr Aubrecht via cu-dev <cu-dev@xxxxxxxxxxx>
Date: Thursday, March 14, 2024 at 8:35 AM
To: cu-dev@xxxxxxxxxxx <cu-dev@xxxxxxxxxxx>
Cc: Petr Aubrecht <aubrecht@xxxxxxxxxxxx>
Subject: [EXTERNAL] Re: [cu-dev] Component spec review deadline and when to create 3.1 RC1 and staging of final

Hello Nathan, Concurro is heading towards implementation of 3. 1. We started to execute the TCK in Payara, currently with result: Tests run: 242, Failures: 5, Errors: 4, Skipped: 24 With Ondro, we did the Flow support today (PR in Concurro). 

Hello Nathan,

Concurro is heading towards implementation of 3.1. We started to execute the TCK in Payara, currently with result:

Tests run: 242, Failures: 5, Errors: 4, Skipped: 24

With Ondro, we did the Flow support today (PR in Concurro). Some fixes were done in TCK itself, there is definitely one more error in testSignature.

The work will continue, so I think that Concurro+Payara can serve as the compatible implementation on Java 21. It will at least test the TCK. I also plan to add the required parts to Glassfish.

 

Regarding SignatureTests -- are we going to work on it? I am convinced, that we discussed its removal, but there were some changes, so it looks like we are going to adapt it to Java 21?

Petr

 

 

On 3/11/24 9:45 PM, Nathan Rauh via cu-dev wrote:

As a Jakarta EE 11 specification in wave 6, Jakarta Concurrency 3.1’s deadline for component specification release review is April 27, 2024.  It might sound like is it still a ways off, but it requires our specification to publish fully passing TCK results on Java 21 and 17 from a compatible implementation alpha, beta, or GA release with publicly available download, after having pushed a candidate final copy of the specification to staging that can be published upon successful review.

 

We need to come up with plans for what our compatible implementation is expected to be and line it up with these dates.

 

In order for Open Liberty to be a compatible implementation for certification of Jakarta Concurrency 3.1, our release process would require a 3.1 RC1 to be created by March 20th, after which the API, specification requirements (and preferably TCK) must not change.  This would allow for the creation of a downloadable beta release that will become available in time to officially pass the TCK and post results by the component specification deadline.

 

Are there any other implementations that could be candidates to use for certification of 3.1?

I noticed there has been a lot of work in the Concurro implementation.  Someone who is working on it would need to let us know how it lines up with the wave 6 component spec release review deadline.

 

_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev

_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev



_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev

_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev


 

--

James R. Perkins

JBoss by Red Hat

_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev


 

--

James R. Perkins

JBoss by Red Hat



_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev

_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev

_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev

Back to the top