Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cu-dev] [jakartaee-platform-dev] Concurrency TCK without remote EJB, javax.rmi.RemoteException
We discussed the current situation in today's platform TCK call with the proposed TCK PR that both removes all usage of jakarta.ejb.Remote and EARs and how that is problematic because it introduces failures in the full platform run. It was pointed out that perhaps simply excluding tests that won't run on the web profile could work. I had thought this could potentially exclude all tests, so I just looked at adding a test group to any test using an EAR deployment, and turned all remote ejb interfaces into simple interfaces. This does allow the tck to run and pass on GlassFish full platform and web profile:

Full platform:
===============================================
jakarta-concurrency
Total tests run: 149, Passes: 149, Failures: 0, Skips: 0
===============================================

[INFO] Tests run: 149, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 288.889 s - in TestSuite
[INFO] 
[INFO] Results:
[INFO] 
[INFO] Tests run: 149, Failures: 0, Errors: 0, Skipped: 0
[INFO] 
[INFO] 

Web profile with eefull group excluded:
===============================================
jakarta-concurrency
Total tests run: 100, Passes: 100, Failures: 0, Skips: 0
===============================================

[INFO] Tests run: 100, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 211.601 s - in TestSuite
[INFO] 
[INFO] Results:
[INFO] 
[INFO] Tests run: 100, Failures: 0, Errors: 0, Skipped: 0


While a non-trivial number of tests are excluded, it is not even the majority of tests, so perhaps that is an acceptable alternative for EE10. There is a PR for review on this set of changes to the concurrency TCK here:

https://github.com/jakartaee/concurrency/pull/250

On Jun 29, 2022 at 11:59:53 AM, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

Thanks Scott.

 

Personally I think you should be able to fix tests, where the test is buggy, as long as the post-conditions aren’t tightened. At the end of the day if someone is affected by a change and they fail a TCK service release which they previously passed they can ultimately raise another challenge on the service release and get the test excluded.

 

Steve

 

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Scott Stark
Sent: 29 June 2022 17:52
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Concurrency TCK without remote EJB, javax.rmi.RemoteException

 

Ok, we discussed this during the spec committee call and it is not so clear, so I'll use this PR as a test case for what is allowed. It is being raised to the spec committee via email.

 

On Jun 29, 2022 at 5:26:07 AM, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

OK I’m not that familiar with the TCK challenge process and service releases. I thought we could only exclude or workaround challenged tests in a service release. I didn’t realise we could fix them.

 

If we can that’s great.

 

Steve

 

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Scott Stark
Sent: 29 June 2022 03:00
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Concurrency TCK without remote EJB, javax.rmi.RemoteException

 

Nothing in these changes violates the definition of a service release to address a tck challenge in the tck process as far as I see. They are not new tests and the existing remote interface usage is an implementation detail of the test. The only time a minor release is mentioned in the tck process is for the case of adding new tests.

 

 

On Jun 28, 2022 at 1:00:45 PM, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

Wouldn’t incorporating a change of that magnitude into TCK require a new concurrency TCK minor release and ballot?

 

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Scott Stark
Sent: 28 June 2022 18:43
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: [jakartaee-platform-dev] Concurrency TCK without remote EJB, javax.rmi.RemoteException

 

I have create a fork of the concurrency project and update the tck to only use local EJBs and even removed use of javax.rmi.RemoteException:

 

I have build the current glassfish repo and run the appserver/tests/tck/concurrency project against a build of this version of the concurrency TCK. It is showing no errors when run with SE 17. The PR for this update is here:

 

I'm not sure how to test this against a web profile configuration of glassfish. Can that be done from the appserver/tests/tck/concurrency project?

 

 

 

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

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

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

Back to the top