[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cu-dev] Collecting and tracking Concurrency 3.0 TCK scenarios and a question on EJB
|
On 11/5/21 4:03 PM, Nathan Rauh wrote:
Scott,
Thanks - I
added
items to the list for signature tests for all of the new classes
that we
added and the 3 existing classes to which we added new methods.
I believe the
porting work that is currently being done will preserve the
ability to
run with Servlet, EJB and JSP as it did in the platform repo.
Please note that some Platform TCK Concurrency TCK tests do
require vendor specific deployment descriptors for configuring for
the tests (e.g.
https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/concurrency/spec/ManagedThreadFactory/context/context_ejb.jar.sun-ejb-jar.xml).
Issue https://github.com/eclipse-ee4j/jaxrs-api/issues/1039 is a
Jakarta RESTful Web Service issue for dealing with vendor
deployment descriptors. We need a standard way to deal with those
across all TCKs that are derived from Platform TCK tests that
currently (or will) have (GlassFish) *sun*.xml deployment
descriptors.
From `find -iname
*sun*.xml` in (Platform TCK) jakartaee-tck/src/com/sun/ts/tests/concurrency:
"
./spec/ManagedThreadFactory/context/context_ejb.jar.sun-ejb-jar.xml
./spec/ManagedScheduledExecutorService/managed/forbiddenapi/forbiddenapiTest_ejb.jar.sun-ejb-jar.xml
./spec/ManagedScheduledExecutorService/security/SecurityTest_ejb.jar.sun-ejb-jar.xml
./spec/ManagedScheduledExecutorService/inheritedapi/inheritedapi_ejb.jar.sun-ejb-jar.xml
./spec/ManagedScheduledExecutorService/inheritedapi/counter_ejb.jar.sun-ejb-jar.xml
./spec/ContextService/contextPropagate/ContextPropagate_ejb.jar.sun-ejb-jar.xml
./spec/ManagedExecutorService/managed/forbiddenapi/forbiddenapiTest_ejb.jar.sun-ejb-jar.xml
./spec/ManagedExecutorService/security/SecurityTest_ejb.jar.sun-ejb-jar.xml
"
Scott
From:
"Scott
Marlow" <smarlow@xxxxxxxxxx>
To:
"cu
developer discussions" <cu-dev@xxxxxxxxxxx>, "Nathan Rauh"
<nathan.rauh@xxxxxxxxxx>
Date:
11/05/2021
01:27 PM
Subject:
[EXTERNAL]
Re: [cu-dev] Collecting and tracking Concurrency 3.0 TCK
scenarios and
a question on EJB
On 11/5/21 12:20 PM,
Nathan
Rauh wrote: I opened the following issue to collect and track
TCK tests
that need to be added for Concurrency 3.0, starting it out with
some obvious
ones based on items that have already gone in:
ZjQcmQRYFpfptBannerStart
This Message Is
From an External Sender
This
message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
On 11/5/21 12:20 PM, Nathan Rauh
wrote:
I opened the
following
issue to collect and track TCK tests that need to be added for
Concurrency
3.0, starting it out with some obvious ones based on items that
have already
gone in:
https://github.com/eclipse-ee4j/concurrency-api/issues/154
If anyone has a better way of doing this, please go ahead. I
decided
to open it because I'm wondering if all the necessary TCK work
will be
achievable within the 4Q timeframe for finalizing a 3.0 spec
release for
Jakarta EE 10.
Currently, the Platform TCK
validates
Concurrency on EJB, Servlet, JSP. If the new Concurrency SPEC
TCK
also test on EJB, Servlet, JSP, then the Platform TCK
Concurrency tests
will not be needed (e.g. could be removed). But if the
Concurrency
SPEC TCK doesn't test on EJB, Servlet, JSP, then the Platform
TCK Concurrency
tests will be needed.
The Concurrency SPEC TCK will also
need
to validate that the Concurrency SPEC API signatures are correct
for the
implementation being tested.
Also, please
feel
free to edit the list in the issue description to add scenarios
or just
reply to the issue or this email for those who don't have edit
permission,
and someone who does can get them added.
I'm also wondering about TCK testing of the resource definitions
deployment
descriptor entries. Does the Concurrency spec TCK need to cover
those
or are those done at another level? The schemas that are
currently
showing for Jakarta EE 10 https://jakarta.ee/xml/ns/jakartaee/#10don't
yet reflect the updates that we put in earlier this year.
The more of the Concurrency API that
we test, the better but you could also add more TCK tests for
the next
Concurrency minor/major release. Once, Concurrency 3.0 has been
released,
no more additional Concurrency 3.0 TCK tests may be added
(adding tests
would invalidate any implementations that have passed the final
Concurrency
3.0 TCK).
Also, a question on @Asynchronous and EJBs which came up during
an internal
review of the specification updates made thus far by the
organization that
I work under. It was brought up that EJBs that are CDI managed
beans
ought to be able to use the new @Asynchronous annotation as long
as they
aren't also annotated with the EJB @Asynchronous annotation.
This
would make for a more consistent statement on the support for
@Asynchronous
with CDI managed beans and would allow EJBs to start switching
over to
the new annotation. It would likely incur some complexity in
addressing
how our @Asynchronous interacts with other aspects of EJB.
Would
it be worth trying to change this in the 3.0 release?
IMO, sounds like a good discussion
for
ejb-dev@xxxxxxxxxxxjust to get more feedback from others.
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev