[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] : Re: Concurrency TCK without remote EJB, javax.rmi.RemoteException
|
The Jakarta EE
9.1 Platform TCK
jakartaeetck/dist/com/sun/ts/tests/concurrency folder
contains 21 EARs as shown in
https://gist.github.com/scottmarlow/7dd9b62089a17da246b1bf8cf0a59eef.
This means that when Web Profile implementations ran the
Concurrency tests for Jakarta EE 9.1 , there were at least 21
tests that could not be run since they were packaged as EARs
(which were not run in Web Profile).
I count that there are 9
tests tagged as @Test(groups = JAKARTAEE_FULL) in https://github.com/jakartaee/concurrency/pull/250
which sounds like an improvement over EE 9.1. These 9 (tagged
as JAKARTAEE_FULL) tests can
only run in Full Platform mode due to Web Profile
implementations not being required support EAR deployment.
It is hard to make a conclusion
just based on the above numbers (with regard to comparing EE
9.1 Platform TCK Concurrency TCK tests to EE 10 Standalone
Concurrency TCK tests) but from a quick look at the pull
request, I see no problems introduced.
Scott
On 7/7/22 1:13 PM, Tracy Burroughs
wrote:
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
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
--
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
- References:
- [jakartaee-platform-dev] Concurrency TCK without remote EJB, javax.rmi.RemoteException
- Re: [jakartaee-platform-dev] Concurrency TCK without remote EJB, javax.rmi.RemoteException
- From: Steve Millidge (Payara)
- Re: [jakartaee-platform-dev] Concurrency TCK without remote EJB, javax.rmi.RemoteException
- Re: [jakartaee-platform-dev] Concurrency TCK without remote EJB, javax.rmi.RemoteException
- From: Steve Millidge (Payara)
- Re: [jakartaee-platform-dev] Concurrency TCK without remote EJB, javax.rmi.RemoteException
- Re: [jakartaee-platform-dev] Concurrency TCK without remote EJB, javax.rmi.RemoteException
- From: Steve Millidge (Payara)
- Re: [jakartaee-platform-dev] Concurrency TCK without remote EJB, javax.rmi.RemoteException
- Re: [jakartaee-platform-dev] [External] : Re: Concurrency TCK without remote EJB, javax.rmi.RemoteException
- Re: [jakartaee-platform-dev] [External] : Re: Concurrency TCK without remote EJB, javax.rmi.RemoteException
- Re: [jakartaee-platform-dev] [External] : Re: Concurrency TCK without remote EJB, javax.rmi.RemoteException
- Re: [jakartaee-platform-dev] : Re: Concurrency TCK without remote EJB, javax.rmi.RemoteException
