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.
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?
|
