[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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
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?