Note that local EJBs are part of Web Profile, so if the concurrency tests are really intending to test with EJBs in general,
then excluding the tests is leaving a gap for something that should work in Web Profile.
On the other hand, if there are tests for both local and remote EJB, then it would be appropriate to exclude just the remote ones.
Tracy Burroughs
(tkb@xxxxxxxxxx)
WebSphere Application Server Development
IBM Rochester, Dept AAW, Bldg H315/050-2
2800 37th Street NW, Rochester MN 55901-4441
From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
On Behalf Of Emily Jiang via jakartaee-platform-dev
Sent: Thursday, July 7, 2022 9:35 AM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Emily Jiang <emijiang6@xxxxxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] [External] : Re: Concurrency TCK without remote EJB, javax.rmi.RemoteException
Personally I think before the Platform and Web Profile release, we should have more freedom on what to put on service release. After the platform and web profile
release, we should be very careful with the service releases. In this PR for concurrency,
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Personally I think before the Platform and Web Profile release, we should have more freedom on what to put on service release. After the platform and web profile release, we should be very careful with the service releases.
In this PR for concurrency, it looks like Scott just excluded the tests for Web Profile. My question is whether the tests excluded test any functions that should work in a web profile. With the deletion, do we have a hole in the specification
verification for the web profile (e.g. some functions untested)?
The only certification request for concurrency to date is Open Liberty, and Brian said this was done with the full platform version:
There has been no web profile implementation pass the tck. Given that state, a 3.0.1 release with the last PR that GlassFish passes with both platform and web profile could be used for any full profile that wishes to use it, and all web
profile implementations. If Open Liberty wants to keep certification of their full profile at 3.0.0, that is fine.
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:
===============================================
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] Tests run: 149, Failures: 0, Errors: 0, Skipped: 0
Web profile with eefull group excluded:
===============================================
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] 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
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
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.
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
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.
Wouldn’t incorporating a change of that magnitude into TCK require a new concurrency TCK minor release and ballot?
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
--
|
