Re: [cu-dev] Collecting and tracking Concurrency 3.0 TCK scenarios and a

[Reza Rahman <reza_rahman@xxxxxxxxx>]

Personally I would leave EJB be if it adds to more complexity. Hopefully most people wouldn’t mix and match anyway and also hopefully the EJB programming model could be deprecated at some point.

---

From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> on behalf of Nathan Rauh <nathan.rauh@xxxxxxxxxx>
Sent: Friday, November 5, 2021 12:20 PM
To: cu developer discussions
Subject: [cu-dev] Collecting and tracking Concurrency 3.0 TCK scenarios and a question on EJB

 

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.  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.

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?