Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [External] : Re: Concurrency TCK without remote EJB, javax.rmi.RemoteException

I believe this case isn't covered in our process documentation (at least that I am aware of). In the Java EE days, a Fix would only be allowed by introduction of an alternate test. The rationale being that, some vendor might have passed the TCK using the original test. By following the 'alternate' path, if a vendor had passed the original test (even if they had not submitted results yet), they could continue doing so without impact to their previous work. New (as well as existing) vendors could select from the original and alternates at their discretion.

If I recall, we decided to simply forego the discussion and inclusion of the process describing alternate tests until a later date since that wasn't needed, when the process was originally codified under the JESP. Now might be a good time to consider adding that to the process text.

The key requirement, in my opinion being that we do not know where other vendors are in their certification process and we do not want to invalidate work done using a previously released artifact. Even if it's just an 'implementation detail' I don't know that we can be sure that such a change would not impose rework on a vendor product.

From what I have read on this, I would recommend this be added as an alternate test. The original and alternate tests should be resolved in a later feature release of the TCK/Specification.

I will discuss the issue of alternate tests with the Specification Committee separately.

Scott, if alternate was necessary, do you know how you would go about that? (I'd think a property in the TCK config/setup would be easiest but I'm not the one writing the code.)

-- Ed

On 7/6/2022 9:37 AM, Scott Stark wrote:
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

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!MZDnu9L2hqo9wd91U64kundoxzdLvZTvUdJV7_SQH5nVSan8Abk9JYIeL75JepyzPiClsbiDuiczea0v$

Back to the top