Re: [cu-dev] unchanged JNDI in CompletableFuture.thenAcceptAsync() creat

[Scott Marlow <smarlow@xxxxxxxxxx>]

    On 5/4/22 2:56 PM, Nathan Rauh wrote:

Petr,

It looks like a mistake in the test case where it is accidentally testing the ‘unchanged’ setting as though it were ‘cleared’.  The `unchanged` setting leaves the context type alone, so whatever the context was on the thread before it must remain.  The mistake went unnoticed on Open Liberty because the state of the thread happens to already match the test assertion.  This one should definitely be challenged for the mistaken assertion.

    FYI, if anyone on this mailing list wants to see some examples of
    existing TCK challenges,
    https://github.com/eclipse-ee4j/jakartaee-tck/projects/2 has a few
    listed.  Basically the person challenging the test would create an
    issue with label `challenge` in
    https://github.com/jakartaee/concurrency/issue to initiate it.  More
    guidance is in
    https://jakarta.ee/committees/specification/tckprocess.

Scott

 

 

From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> on behalf of Petr Aubrecht <aubrecht@xxxxxxxxxxxx>
Reply-To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Date: Wednesday, May 4, 2022 at 1:35 PM
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] [cu-dev] unchanged JNDI in CompletableFuture.thenAcceptAsync() created from ManageExecutorService

 

Hello, I'm looking at test ManagedExecutorDefinitionTests/ManagedExecutorDefinitionServlet.testCompletedFuture, using "java:module/concurrent/ExecutorB" ManagedExecutorService, which is configured to use this context: ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hello,

 

I'm looking at test ManagedExecutorDefinitionTests/ManagedExecutorDefinitionServlet.testCompletedFuture, using "java:module/concurrent/ExecutorB" ManagedExecutorService, which is configured to use this context:

@ContextServiceDefinition(name = "java:module/concurrent/ContextB",

                          cleared = TRANSACTION,

                          unchanged = { APPLICATION, IntContext.NAME },

                          propagated = ALL_REMAINING)

E.g. the implementation must keep APPLICATION (JNDI search) unchanged during the thenAcceptAsync() call.

This test expects, that the thread's context doesn't recognize java:module JNDI lookup. As I understand, Open Liberty starts threads with "empty contexts", so JNDI calls fail and TCK test succeeds.

This is not the case of Payara/Glassfish, which shares the context of launching thread, so the JNDI call succeed. I fear, that changing the behavior of thread in MES may break compatibility with existing application.

 

I would like to ask, if there is described the requirement of failing JNDI search for java:module if using ContextServiceDefinition.unchanged(APPLICATION). I haven't found any. APPLICATION javadoc only describes behavior for cleared.

 

Thank you,

Petr

 

_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev