[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cu-dev] [External] : Re: [jakartaee-platform-dev] Concurrency TCK without remote EJB, javax.rmi.RemoteException
|
- From: Ed Bratt <ed.bratt@xxxxxxxxxx>
- Date: Wed, 6 Jul 2022 10:10:58 -0700
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZB5YYZNxBTaVqyWKzYmkKoDuBQ+RGIRyRWVJsnPb24A=; b=d5yVhGLOKgMb9+TqFSxOdWCok99gvCD67BPlqFUgCfJnEqiYRBB6awYXv84tINS18/jh/EWNK2Ib4Th7vICweWCPYybDNWOwyQ3c4a8ddj+cr52kGLGRtn2rEBUeDhF+Cwo52Axe2i/VxJvH/182y5Zw+q1mD0ULKuZYeisxVdNqTeWXhKkw/Zi0wAXVTJmreFd5cj7Dpxv6/plXwAMm5YUDUx0BnEdx9DDLm7M0jI7aCtjXr2rbcpr/BBZ3TVdWUxwPlRjqCsyuo6Lyp3fzubNoAdnXd+KSD1psPYaA6B2l/FXzTpQSmIUK4nwtleUrzNYIdwQuO0lcTjuvR0HLyQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PxTz4J1WjwW6HpBQagv1eDgR9ySj/nJ3VOSQBvc2LcAbbwOq2QfBJLXFRVbqojOcxDb2YJlGEnOm7TQFmiM/V5BMb8nvrXuF+kmVXCXGdHducgcWyf44abgN/nDsZr1Z0pSILli/LR+JIVOiwyIEBks3Js5Vo6kYN1b6Mi6/cc2ZQByNQX33owqnSTU5KOaXD4auqEKh/4tGtI1LOB71KvjbSHjBgR4Q0sbhZwumqpzUrCGfgVaLA14zNTOBKRnGhf+8Wbq0hShOVMkdyFHVAHG/br17UyM396+IJ0WvMye2MK+7w4EkJl6yi0I6nw6H6zozZEVGi1D3MBPPZ65mDA==
- Delivered-to: cu-dev@xxxxxxxxxxx
- List-archive: <https://www.eclipse.org/mailman/private/cu-dev/>
- List-help: <mailto:cu-dev-request@eclipse.org?subject=help>
- List-subscribe: <https://www.eclipse.org/mailman/listinfo/cu-dev>, <mailto:cu-dev-request@eclipse.org?subject=subscribe>
- List-unsubscribe: <https://www.eclipse.org/mailman/options/cu-dev>, <mailto:cu-dev-request@eclipse.org?subject=unsubscribe>
- User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
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
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://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!MZDnu9L2hqo9wd91U64kundoxzdLvZTvUdJV7_SQH5nVSan8Abk9JYIeL75JepyzPiClsbiDuiczea0v$