Re: [cu-dev] Concurrency 3.0 TCK tests to review

["Nathan Rauh" <nathan.rauh@xxxxxxxxxx>]

At this point, all
of the identified TCK scenarios have been coded up (it's still fine to
come up with more if anyone thinks of more) to run in servlets, except
for the MaxConcurrency and Lock scenarios because those features haven't
yet been added to Concurrency 3.0. Tests are running locally against a
development copy of Open Liberty with some modifications.  Although
not the compatible implementation, it's at least a step in the right direction.
 We still need to get test scenarios running in EJBs/JSPs, as well
as finish getting the existing TCK ported over from platform and get these
new tests merged into it.

In the interest
of making progress on this while other efforts continue in parallel, and
because there was a lot to write up for tests given how much was added
in Concurrency 3.0, I'd welcome code reviews of what we have so far for
new tests and the approach used for signature tests,
https://github.com/eclipse-ee4j/concurrency-api/pull/156/commits





From:
       Nathan
Rauh/Rochester/IBM
To:
       "Scott
Marlow" <smarlow@xxxxxxxxxx>
Cc:
       "cu
developer discussions" <cu-dev@xxxxxxxxxxx>
Date:
       11/16/2021
09:35 AM
Subject:
       Re:
[EXTERNAL] 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/1039is 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