[
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
|
Thanks for all of the comments from everyone. Progress continues to be
made on coding up the identified TCK scenarios, in parallel to the effort
by Kyle to get the Concurrency bucket ported over. With regard to the
signature tests, it seems like it might be easier to just match the
coverage rather than porting over all of the infrastructure behind it. If
I understand correctly, these are just stepping through the list of
classes from the spec and checking that all of the method/constructor
signatures are an exact match, with no more and no less than the spec
defines.
From: "Scott Marlow" <smarlow@xxxxxxxxxx>
To: "Nathan Rauh" <nathan.rauh@xxxxxxxxxx>
Cc: "cu developer discussions" <cu-dev@xxxxxxxxxxx>
Date: 11/05/2021 03:24 PM
Subject: [EXTERNAL] 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.
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
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@eclipse.orgjust 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
